ストリーミングメディアパート4
プロトコル
ビデオとオーディオのストリームは、ファイル サイズを小さくするために圧縮されます。 オーディオコーディング形式には、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 ノードとストリーミング宛先の間では、インターネット互換のユニキャスト配信が使用されます。
