[実際の質問は最後の段落にあります。物事が明確になった場合のために、仮定と思考プロセスを掲載しました]
これは、同じUSB 2.0バスで大量のWebカメラがストリーミングされているときに何が起こったのかを見たいときに始まりました。そこで、1つのUSB 2.0ハブを介して3つのUSB 2.0 Webカメラを意図的に接続し、480 Mbpsの最大スループットを確保しました（USB 2.0規格に準拠）。
そして、3つのWebカメラすべてを同時にストリーミングしました。驚いたことに、USB 2.0コントローラからのラグ、スタッター、「帯域幅超過」の悲鳴はありませんでした。
各Webカメラのフレームレート、解像度、ピクセルあたりのカラービット数を知っていたので驚きました。乗算によると：
1秒あたりのフレーム数*高さ*幅*ピクセルあたりのビット数
3つのWebカメラはUSB 2.0バスを飽和させていたはずですが、そうではありませんでした。
AForgeフレームワークを使用して個々のフレームをキャプチャしました。すべての個々のフレームは、サイズとピクセルあたりのビット数が計算に一致するビットマップとして与えられ、計算はUSB 2.0の便秘を予測しました。
最後に、USB 2.0の帯域幅の使用状況を観察し、1つのWebカメラが予想される帯域幅の消費を尊重している間、他のWebカメラはその2倍以上下回っていました。
実際の質問：
そのため、私の結論（確認または修正したいと考えています）は、WebカメラがUSB経由で必要なものを送信することです。巨大なビットマップ、JPEG、独自の形式、またはMPEG4ストリームの場合もあります。そのため、Webカメラはフレームを圧縮してからUSB接続で送信する場合としない場合があります。USBホスト側では、ウェブカメラのドライバーは、ウェブカメラがUSB経由で送信したものをすべて取得し、ビットマップを再構成します（実際の帯域幅に関係なく、常にビットマップを取得する理由です）。これはどのように間違っていましたか？私が正しい場合、異なるウェブカメラによってUSBを介して送信されるデータ形式のどこかに便利なデータベースがありますか？