2

最近、ウェブカメラでキャプチャされたライブ ビデオを udp 経由でストリーミングしようとしていました。私が取ったアプローチは、1フレームを読み取り、udp経由で送信し、受信側でデータを読み取って表示することでした。

これで、udp/tcp を介してデータを送信すると、トランスポート層の MTU に応じてランダムな方法で断片化が発生し、基盤となる IP プロトコルが配信されるフレームの数を保証しないことを理解しました。データ層の最小 MTU は 1500 バイトと言われています。

ただし、私の各フレームは 1MB ( ~1048576 バイト) です。したがって、1500 バイトでのデータの断片化を考慮すると、単一のフレームが断片化され、受信者は約 700 パケット (1048576/1500) を取得する可能性があります。ここで、受信機は、追加の処理を伴う 1 フレームだけのために、これらすべての 700 パケットのデータを蓄積する必要があります。これは正常なのか、1 フレームのデータだけで 700 パケット!!。フレーム レートを 24 fps に維持したい場合、これは受信側が 700*24 = 16800 パケット/秒を処​​理しなければならないことを意味し、これは実行可能ではないようです。

別のストリーミング Web サイトがどのように機能するかを知りたいのですが、それらは 1 秒あたり 16800 データ パケットを処理していません。RTSP などの他のストリーミング プロトコルを使用することもありますが、これらは UDP/TCP の上に構築されているため、これらのプロトコルもフラグメンテーションを処理する必要があります。最近のストリーミング Web サイトは 4k ビデオを配信でき、各フレーム サイズは 1MB をはるかに超えますが、MTU は依然として 1500 バイトです。データ圧縮も行っている必要がありますが、どの程度. 何らかの方法でフレーム サイズを 50% 縮小できたとしても (受信側で圧縮解除する必要があるため、追加の処理が必要になります)、低品質の 24fps ビデオの場合、毎秒最大 8000 データ パケットを処理する必要があります。彼らはそれをどのように処理し、これらの規模でデータの断片化をどのように管理しますか。

4

1 に答える 1

4

圧縮されていないデータがネットワーク経由で送信されることはほとんどありません。現在採用されているH.264 AVC、H.265 HEVC、H.266 VVC、VP8、VP9、AV1などのビデオ コーデックは、解像度、フレームレート、ターゲット ビットレート、忠実度要件、リアル時間の要件とストレージまたは配信ネットワークのキャパシティが挙げられます。

あなたが参照しているストリーミング Web サイトはすべて圧縮を使用して、ビデオを配信するだけでなく、avi、mp4、mkv ファイルなどのさまざまなコンテナーにコンテンツを保存します。

ストリーミング プロトコルの選択は、リアルタイム要件 (ミリ秒対秒)、インフラストラクチャ要件、スケーラビリティ要件、ソリューションの複雑さ、およびターゲット クライアント デバイスと機能 (コンピューター、タブレット、電話など) によっても異なります。たとえば、HTTP ベースのストリーミング プロトコルでは、十分にテストされ、理解されている HTTP インフラストラクチャとソフトウェアの再利用が可能であり、処理できる要求の数をスケーリングするのに役立つキャッシュなどの利点があります。

遅延を最大 150 ミリ秒未満に抑える必要があるビデオ通信 (WebRTC など) などの低遅延のユース ケースに使用されるリアルタイム ストリーミングは、通常、RTP /UDP を介して行われます。シグナリングについては、RTSP、SIP、および WebRTC を参照してください。他のプロトコル (非 IETF) には、Adobe によって開発されたが、数年にわたって衰退している RTMP が含まれます (AFAIR)。

あなたが述べているように、圧縮されたフレームでさえ、サイズが数千バイトになる可能性があります。RTP/UDP 経由でストリーミングする場合、より大きなエンコードされたフレームは、RTP ペイロード形式(フレームをフラグメント化する方法を指定するRFC6184、RFC7741、RFC7798など) を使用して複数のパケット/データグラムに分割されます。

HTTP ベースのアダプティブ ストリーミングの遅延要件はそれほど厳しくなく、ここでは HTTP がメッセージのフレーミングを管理します。プロトコルには、HTTP ライブ ストリーミング、MPEG DASHなどがあります。

何らかの方法でフレームサイズを 50% 縮小できたとしても (受信側で圧縮解除する必要があるため、追加の処理が必要になります)。

言及されているコーデックは、はるかに優れた圧縮率を達成し、追加の処理は無視でき、広く使用されているコーデックのエンコード/デコードは通常、ハードウェアによってサポートされています。お使いの携帯電話には、H.264 を非常に効率的にデコードするためのハードウェアが搭載されている可能性があります。

于 2020-10-17T13:42:34.973 に答える