ストリーミング メディア パート 6
プロトコル
ビデオ ストリームとオーディオ ストリームは、ファイル サイズを小さくするために圧縮されます。オーディオ コーディング形式には、MP3、Vorbis、AAC、Opus などがあります。ビデオ コーディング形式には、H.264、HEVC、VP8、VP9 などがあります。エンコードされたオーディオ ストリームとビデオ ストリームは、MP4、FLV、WebM、ASF、ISMA などのコンテナー ビットストリームにまとめられます。ビットストリームは、Adobe の RTMP や RTP などのトランスポート プロトコルを使用して、ストリーミング サーバーからストリーミング クライアント (インターネットに接続されたラップトップを持つコンピューター ユーザーなど) に配信されます。
2010 年代には、Apple の HLS、Microsoft の Smooth Streaming、Adobe の HDS などのテクノロジや、MPEG-DASH などの非独自形式が登場し、独自のトランスポート プロトコルを使用する代わりに、HTTP 経由のアダプティブ ビットレート ストリーミングが可能になりました。多くの場合、ストリーミング トランスポート プロトコルは、イベント会場からクラウド トランスコーディング サービスとコンテンツ配信ネットワークにビデオを送信するために使用され、その後、HTTP ベースのトランスポート プロトコルを使用して個々の家庭やユーザーにビデオを配信します。ストリーミング クライアント (エンド ユーザー) は、MMS や RTSP などの制御プロトコルを使用してストリーミング サーバーとやり取りする場合があります。
サーバーとユーザー間のやり取りの品質は、ストリーミング サービスのワークロードに基づいています。サービスにアクセスしようとするユーザーが増えると、サービス内のリソース制約によって品質が影響を受ける可能性があります。ストリーミング サーバーのクラスターを展開することは、ネットワーク全体に分散された地域サーバーがあり、すべてのメディア ファイルのコピーと地域サーバーの IP アドレスを含む単一の中央サーバーによって管理される、そのような方法の 1 つです。次に、この中央サーバーは、負荷分散およびスケジュール アルゴリズムを使用して、ユーザーを、ユーザーに対応できる近くの地域サーバーにリダイレクトします。このアプローチでは、中央サーバーは、必要に応じて FFMpeg ライブラリを使用して、ユーザーと地域サーバーの両方にストリーミング データを提供することもできます。そのため、中央サーバーには強力なデータ処理と膨大なストレージ機能が求められます。その代わりに、ストリーミング バックボーン ネットワークのワークロードがバランス調整され、軽減され、最適なストリーミング品質が実現します。
ストリーミング メディアをサポートするネットワーク プロトコルの設計には、多くの問題があります。ユーザー データグラム プロトコル (UDP) などのデータグラム プロトコルは、メディア ストリームを一連の小さなパケットとして送信します。これはシンプルで効率的ですが、プロトコル内に配信を保証するメカニズムはありません。受信側アプリケーションが、損失や破損を検出し、エラー訂正技術を使用してデータを回復する必要があります。データが失われると、ストリームがドロップアウトする可能性があります。リアルタイム ストリーミング プロトコル (RTSP)、リアルタイム トランスポート プロトコル (RTP)、およびリアルタイム トランスポート コントロール プロトコル (RTCP) は、ネットワーク経由でメディアをストリーミングするために特別に設計されました。RTSP はさまざまなトランスポート プロトコル上で実行されますが、後者の 2 つは UDP 上に構築されています。
HTTP アダプティブ ビットレート ストリーミングは、HTTP プログレッシブ ダウンロードに基づいていますが、前のアプローチとは対照的に、ここではファイルが非常に小さいため、RTSP と RTP を使用する場合と同様に、パケットのストリーミングと比較できます。伝送制御プロトコル (TCP) などの信頼性の高いプロトコルは、メディア ストリームの各ビットの正確な配信を保証します。ただし、ネットワーク上でデータ損失が発生すると、プロトコル ハンドラーが損失を検出し、失われたデータを再送信する間、メディア ストリームが停止します。クライアントは、表示用にデータをバッファリングすることで、この影響を最小限に抑えることができます。バッファリングによる遅延はビデオ オン デマンドのシナリオでは許容されますが、ビデオ会議などのインタラクティブ アプリケーションのユーザーは、バッファリングによる遅延が 200 ミリ秒を超えると、忠実度の低下を経験します。
ユニキャスト プロトコルは、サーバーから各受信者にメディア ストリームの個別のコピーを送信します。ユニキャストはほとんどのインターネット接続の標準ですが、多くのユーザーが同時に同じテレビ番組を視聴したい場合には、あまり拡張性がありません。マルチキャスト プロトコルは、多くの受信者がユニキャスト コンテンツ ストリームを個別に受信するときに発生する重複データ ストリームによって生じるサーバーおよびネットワークの負荷を軽減するために開発されました。これらのプロトコルは、ソースから受信者のグループに単一のストリームを送信します。ネットワーク インフラストラクチャとタイプによっては、マルチキャスト送信が実行可能かどうかが異なります。マルチキャストの潜在的な欠点の 1 つは、ビデオ オン デマンド機能が失われることです。ラジオやテレビの素材を継続的にストリーミングすると、通常、受信者が再生を制御できなくなります。ただし、この問題は、キャッシュ サーバー、デジタル セットトップ ボックス、バッファ付きメディア プレーヤーなどの要素によって軽減できます。
IP マルチキャストは、コンピューター ネットワーク上の受信者のグループに単一のメディア ストリームを送信する手段を提供します。接続管理プロトコル (通常はインターネット グループ管理プロトコル) は、LAN 上の受信者のグループへのマルチキャスト ストリームの配信を管理するために使用されます。 IP マルチキャストを展開する際の課題の 1 つは、LAN 間のルーターとファイアウォールがマルチキャスト グループ宛てのパケットの通過を許可する必要があることです。コンテンツを提供している組織がサーバーと受信者間のネットワーク (教育機関、政府機関、企業のイントラネットなど) を管理している場合、プロトコル独立マルチキャストなどのルーティング プロトコルを使用して、ストリーム コンテンツを複数のローカル エリア ネットワーク セグメントに配信できます。
ピアツーピア (P2P) プロトコルは、事前に記録されたストリームがコンピューター間で送信されるようにします。これにより、サーバーとそのネットワーク接続がボトルネックになることを回避できます。ただし、技術、パフォーマンス、セキュリティ、品質、およびビジネス上の問題が発生します。
コンテンツ配信ネットワーク (CDN) は、中間サーバーを使用して負荷を分散します。CDN ノードとストリーミングの宛先の間では、インターネット互換のユニキャスト配信が使用されます。