ストリーミング プロトコル: 知っておくべきこと

この記事は、当社パートナーの Wowza Media Systems の記事 Streaming Protocols: Everything You Need to Know (Update) の翻訳記事です。

オンライン ビデオ配信に関して議論する際に、RTMP、HLS、MPEG-DASH、および WebRTC は、ポイント A から B にコンテンツを取得するために使用されるストリーミング プロトコルを指します。様々なプロトコルが、様々な種類のブロードキャストで役割を果たすため、あるプロトコルが別のプロトコルより優れているとは必ずしも言えません。

すべてのプロトコル技術を区別することは、ビデオ ストリーミングのスペースに参画するすべての人々にとっては困難なことです。 各プロトコルが互換性、遅延、セキュリティ（これらの項目は追継続的に追加されています）の点でわずかに異なるという事実を考慮すると、本当に複雑になります。

この記事では、プロトコルとは何か、2022 年に最も一般的な 10 種類のビデオ ストリーミング プロトコル、そして、ユース ケースに適したテクノロジを選択する際の考慮事項について、詳しく説明します。

プロトコルとは

プロトコルとは、ある通信システムから別の通信システムにデータを転送する方法を制御する一連の規約です。 これらは、あるプロトコル スタックを形成するためにもうひとつのプロトコルの上に多重に重ねて形成されます。 このようにして、各層のプロトコルは、特定の機能に集中し、プロトコル間で互いに協調することができます。 最下層は基盤として機能し、その上の各層は（訳注: 各層に含まれる様々な機能が追加されることで）複雑になっていきます。

インターネット プロトコルを意味する IP および IP アドレスについて、聞いたことがあるでしょう。 このプロトコルは、インターネットを使用するデバイスが通信する方法を構造化します。 インターネット プロトコルは、ネットワーク層に位置し、通常、トランスポート層で Transmission Control Protocol (TCP) を重ねて形成され、同様に、アプリケーション層では Hypertext Transfer Protocol (HTTP) を重ねて形成されます。

上記の図のように、物理層、データ リンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層、および、アプリケーション層を含む 7 つの層 (レイヤー) は、国際標準化機構 (ISO) のオープン システム相互接続モデル によって定義されました。

ストリーミング プロトコルとは

ライブ ストリームやビデオ オンデマンドの視聴をするたびに、ビデオ ストリーミング プロトコルを使用してインターネット経由でデータが配信されます。 このビデオ ストリーミングのデータ通信は、アプリケーション層、プレゼンテーション層、および、セッション層で実行されています。

オンライン ビデオ配信では、専用のストリーミング プロトコルと HTTP ベースのプロトコルの両方が使用されています。 Real-Time Messaging Protocol (RTMP) や Real-Time Streaming Protocol (RTSP) のストリーミング プロトコルは、専用のストリーミング サーバーを使用してビデオを配信します。

一方、HTTP ベースのプロトコルは、通常の Web サーバーを使って、視聴体験を最適化しながら、素早くスケーリングして配信します。

最後に、Apple の Low-Latency HLS (低遅延 HLS) などの新しい HTTP ベースの技術は、大規模な低遅延 (レイテンシー) ストリーミングをサポートすることで、両方のオプションの最良の部分を提供しようとしています。

訳注: 一般的に、専用のストリーミングプロトコルは配信の遅延を削減しながらビデオ配信ができますが、その代わりに、大規模配信のためのスケーリングが難しくなります。一方で、HTTPベースの技術は、大規模配信のスケーリングが容易です。

UDP vs. TCP: 簡単な背景

訳注: 本記事では、ビデオストリーミング プロトコルの比較の前に、プロトコルの性質の違いの理解のために UDP と TCP について触れます。

ユーザー データグラム プロトコル (UDP) と伝送制御プロトコル (TCP) はどちらもインターネット プロトコル群のコアとなるコンポーネントであり、トランスポート層に位置します。 ストリーミングに使用されるプロトコルは、これらのプロトコル層の上にあります。 UDP と TCP は品質と速度の点で性質が異なるため、詳しく調べる価値があります。

上図は https://microchipdeveloper.com/tcpip:tcp-vs-udp より転用

UDP と TCP の主な違いは、データを転送するときに TCP が 3 方向のハンドシェイクを必要とするという事実が大きなポイントです。(通信の) イニシエーター (クライアント) がアクセプター (サーバー) に接続の開始を要求し、アクセプターが応答し、イニシエーターが応答を確認して、両端間の (TCP) セッションを維持します。このため、TCP は非常に信頼性が高く、パケットの損失やパケットの順序付けの問題を解決できます。一方、UDP はハンドシェイクを必要とせずに開始します。帯域幅の制約に関係なくデータを転送するため、より高速で通信ができますが、通信の信頼性のリスクが高くなります。 UDP は再送信、パケットの順序付け、またはエラー チェックをサポートしていないため、ネットワークの不具合等により、途中でデータが破損する可能性があります。

Secure Reliable Transport (SRT) などのプロトコルは UDP を使用し、HTTP ライブ ストリーミング (HLS) などのプロトコルは TCP を使用します。

ビデオ ストリーミングの最も一般的なプロトコル

ビデオ ストリーミング プロトコルの比較を行います。 一般的な 10 種類のビデオ ストリーミング プロトコルは以下の通りです。

• リアルタイム メッセージング プロトコル (RTMP)
• リアルタイム ストリーミング プロトコル (RTSP)
• APple HTTP ライブ ストリーミング (HLS)
• 低遅延 HTTP ライブ ストリーミング (Low-Latency HLS)
• HTTP 動的アダプティブストリーミング (MPEG-DASH)
• MPEG-DASH 向けの低遅延 CMAF
• Microsoft スムース ストリーミング (Smooth Streaming)
• Adobe HTTP ダイナミック ストリーミング (HDS)
• SRT (セキュア リライアブル トランスポート)
• WebRTC (Web リアルタイム通信)

従来のビデオ ストリーミング プロトコル

RTSP や RTMP などの従来のストリーミング プロトコルは、低遅延のストリーミングをサポートしています。 ただし、ほとんどのエンドポイント (ブラウザー、モバイル デバイス、コンピューター、テレビなど) では、これらのプロトコルをネイティブにサポートしていません。 現在、これらのストリーミング プロトコルは、IP カメラ または エンコーダーと専用メディア サーバーの間でビデオを転送するのに最適となっています。

上記の図ように、RTMP はケーブル放送とほぼ同じ遅延でビデオを配信することができます — わずか 5 秒強です。 RTSP/RTP は約 2 秒の遅延と、さらに高速です。どちらのプロトコルも、ローカルでのダウンロードやキャッシュを必要とせずに、消防ホース アプローチを使用して (注釈参照) データを送信することで、このような速度を実現しています。しかし、RTMP と RTSP をサポートする映像再生プレーヤーはほとんどないため、大規模な視聴体験の実現には最適ではありません。多くの放送局は、RTMP などのステートフル プロトコルを使用して、ライブ ストリームをメディア サーバーに転送することを選択しています。そこから、マルチデバイスへの配信のための HTTP ベースの技術を使ってトランスコードします。

訳注: 消防ホースのアプローチとは、一度サーバーにデータ取得のリクエストを送信すると、その後、サーバーで受信または生成されたデータが可能な限り素早くレスポンスとして永続的に流れてくることを指します

Adobe RTMP

Adobe は、ビデオ ストリーミングの黎明期に RTMP 仕様を設計しました。 このプロトコルでは、専用のストリーミング サーバーと Adobe Flash Player の間でオーディオ データとビデオ データを転送できます。 このプロトコルは、信頼性が高く効率的で、ライブ ストリーミングに最適でした。 しかし、オープン スタンダードとアダプティブ ビットレート ストリーミングの技術によって、最終的に RTMP は追い抜かれてしまいました。 この記事 は、Adobe が Flash の廃止 (正式に 2020 年に終了しました) を発表された際に書かれました。

Adobe Flash のサポート終了日は過ぎましたが、「映像の入力に RTMP を利用すること」は終わっていません。 RTMP エンコーダーは、専用プロトコルがラストマイルの配信 (訳注: エンドユーザー向けの配信) で支持されなくなったにもかかわらず、依然として多くのコンテンツ プロデューサーにとって頼りになる存在です。

実際、Wowza の 2021 年のビデオ ストリーミング レイテンシー レポート では、コンテンツ ディストリビューターの 76% 以上が、映像の入力に RTMP を使用していると回答しています。

RTSP/RTP

RTMP と同様に、RTSP/RTP は映像の入力に使用される昔ながらの技術です。 RTSP と RTP は、しばしば同じ意味で使用されます。ただし、違いを明確にするため詳細を記載すると、RTSP は 再生や一時停止などの機能を介してメディアサーバーにコマンドをエンドユーザーが送信できるようにするプレゼンテーション層プロトコルであり、RTP はデータを転送するために使用されるトランスポート層のプロトコルです。

Android および iOS デバイスには、すぐに使用できる RTSP 互換のプレーヤーがないため、再生に使用されることはほとんどありません。とはいえ、RTSP は多くの監視カメラや閉回路テレビ (CCTV) のアーキテクチャで標準とされたままです。 なぜでしょうか？ 理由は簡単です。 まだ、色々な IP カメラでは RTSP がサポートされているからです。

訳注: CCTVとは、閉回路テレビを意味し、特定の建物や施設内での利用される有線のテレビです。防犯カメラのモニターとして使われることが多い。

アダプティブ (適応型) HTTP ベースのストリーミング プロトコル

HTTP 経由で展開されたビデオストリームは、技術的には「ストリーム」ではありません。 むしろ、通常の Web サーバー経由で送信されるプログレッシブ ダウンロードです。 アダプティブ ビットレート ストリーミングを使用する HTTP ベースのプロトコルは、接続されたネットワーク、ソフトウェア、または、デバイスに関係なく、可能な限り最高のビデオ品質と視聴者体験を提供します。 最も一般的な HTTP ベースのプロトコルには、MPEG-DASH や Apple HLS などがあります。

訳注: プログレッシブ ダウンロードとは、音声や映像をダウンロードしながら同時に再生することを指します。[こちらの記事](https://www.liveinstantly.jp/resources/blog/video-streaming-introduction/ も参照ください。

Apple HLS

Apple のデバイスは、インターネットに接続されたデバイスの世界で主要なプレーヤーであるため、Apple の HLS プロトコルが、デジタル ビデオの世界を支配していることになります。 (Apple HLS プロトコルの重要な点の) 1 つには、このプロトコルは、視聴者体験の鍵となるアダプティブ ビットレート ストリーミングをサポートしていることです。 さらに重要なことは、HLS 経由で配信されたストリームが大部分のデバイスで再生でき、それによって多数の視聴者が確実にアクセスできるようになることです。

HLS のサポートは当初、iPhone や iPad などの iOS デバイスに限定されていましたが、その後、幅広いプラットフォームでネイティブにサポートされるようになりました。 Android、Linux、Microsoft、および macOS デバイスと同様に、すべての Google Chrome ブラウザは、HLS を使用して配信されたストリームを再生できます。

低遅延 HLS

Low-Latency HLS (LL-HLS) は、低遅延のストリーミングに関する最新かつ最高の技術です。この Apple 独自のプロトコルは、ストリームを 3 秒以下遅延でグローバルに配信することを約束します。また、既存のクライアントとの下位互換性も提供します。

つまり、HLS と同じシンプルさ、スケーラビリティ、品質を提供しながら、遅延 (レイテンシー) を大幅に短縮するように設計されています。 Wowza では、この組み合わせをストリーミング トリフェクタと呼んでいます。

それでも、低遅延 HLS の展開を成功させるには、ビデオ配信エコシステムまたいだベンダーの統合が必要となります。ベンダーからのサポートはまだ不足しており、低遅延 HLS の大規模な展開はほとんどありません。

MPEG-DASH

MPEG-DASH は、ベンダーに依存しない HLS の代替手段です。 基本的に、DASH を使用すると、同じスケーラビリティと品質を保証するベンダー非依存（非プロプライエタリな) オプションを利用できます。しかし、Apple は自社の技術スタックを優先する傾向があるため、DASH のサポートは、多数の Apple デバイスの市場の中で 2 番目の役割を果たす傾向にあります。

MPEG-DASH 向けの低遅延 CMAF

MPEG-DASH 向けの低遅延 CMAF は、HTTP ベースのビデオ配信を高速化するためのもう 1 つの新しい技術です。 まだ初期段階ですが、この技術は、短いデータ セグメントを使用することで超高速で大規模にビデオを配信できる可能性を示しています。 とはいえ、多くのベンダーは、DASH の低遅延 CMAF のサポートよりも、低遅延 HLS のサポートを優先しています。

Microsoft スムース ストリーミング (Smooth Streaming)

Microsoft は、Silverlight プレーヤー アプリケーションで利用する Microsoft Smooth Streaming を 2008 年に開発しました。 これにより、すべての Microsoft デバイスへのアダプティブストリーミングの配信が可能になりました。 このプロトコルは他の HTTP ベースのストリーミング プロトコルと競争できず、使用されなくなりつつあります。 実際、Wowza の 2021 年のビデオ ストリーミング レイテンシー レポート では、この Microsoft スムース ストリーミング プロトコルを使用していた回答者はわずか 5% でした。

現在使用しているストリーミングプロトコルについての調査結果:

Adobe HDS

Adobe HDS は、最初のアダプティブ ビットレート プロトコルとして Flash Player で使用するために Adobe 社で開発されました。 Flash はもはや存在しないため、徐々にすたれつつあります。 上記の調査結果のグラフをもう一度確認してください。

新しい技術

最後になりましたが、WebRTC や SRT などの新しい技術は、ビデオ配信の状況を変えることを約束しています。 MPEG-DASH および Apple Low-Latency HLS で利用される低遅延 CMAF と同様に、これらのプロトコルは低遅延を考慮して設計されています。

SRT (Secure Reliable Transport)

このオープンソース プロトコルは、ネットワーク接続の品質に関係なく、信頼性の高いストリームを配信するのに役立ち、かつ、独自のトランスポート技術に代わる実証済みのプロトコルとして認識されています。ファーストマイル ソリューションとして RTMP および RTSP と直接競合しますが、エンコーダー、デコーダー、および、プレーヤーでこの技術がサポートがされ採用されています。

失われたパケットの回復からタイミング挙動の維持まで、SRT はパブリック インターネットをまたいだビデオの入力と配信の課題を解決するように設計されています。そして、急速に業界を席巻しています。 SRT が有効であることが証明されたインタラクティブなユース ケースの 1 つは、2020 年のバーチャル NFL ドラフトでした。 NFL は、最初の完全なバーチャルイベントのために 600 のライブ フィードの接続にこの画期的な技術を使用しました。

WebRTC

WebRTC は、利用可能な最も高速な技術として、主要なブラウザとの間でほぼ瞬時にオーディオとビデオのストリーミングを提供します。また、エンド・ツー・エンドで使用できるため、入力および配信プロトコルと競合します。このフレームワークは、純粋なチャット ベースのアプリケーション向けに設計されましたが、現在では、より多様なユース ケースに採用されています。

ただし、WebRTC にとって、スケーラビリティは依然として課題であるため、この課題を克服するには、Wowza の Real-Time Streaming at Scale 機能などのソリューションを使用する必要があります。このソリューションは、カスタム CDN 全体に WebRTC サービスを展開して、ほぼ無限のスケールを提供します。これにより、放送局は 500 ミリ秒未満の配信で 100 万人の視聴者にリーチできる可能性があります (これはかつて不可能だった偉業です)。

訳注: WebRTC は Webベースの技術であるが、HTTPベースのアダプティブストリーミングとは異なり、オーディオやビデオのデータのキャッシュ配信ができないため、大規模向けの配信のようなスケーラビリティが必要となるシナリオに課題がある

ワークフロー: Wowza Video の大規模なリアルタイム ストリーミング

ストリーミング プロトコルを選択する際の考慮事項

適切なストリーミング プロトコルの選択は、何を達成しようとしているのかを定義することから始まります。 選択したプロトコルにより、遅延、再生の互換性、視聴体験のすべてが影響を受ける可能性があります。 さらに、コンテンツ ディストリビューターは、コンテンツのキャプチャから再生まで常に同じプロトコルに固執する必要はありません。多くの放送局は、RTMP を使用してエンコーダーからサーバーに到達し、ストリームを HTTP ベースのアダプティブ ストリーミング プロトコルにトランスコードします。

メディア ストリーミング プロトコルは、次の領域で異なります。

• ファーストマイルの転送とラストマイルの配信
• 再生のサポート
• エンコーダーのサポート
• スケーラビリティ
• 遅延 (レイテンシー)
• 体験の品質 (アダプティブ ビットレートの有効化など)
• セキュリティ

上記の考慮事項に優先順位を付けることで、それぞれのシナリオで最適なものを簡単に絞り込むことができます。

転送と配信

RTMP と SRT は最初のファーストマイルの転送 (訳注: 映像の入力) に大きく貢献しますが、再生（訳注: エンドユーザーに対するビデオ配信）に関しては MPEG-DASH と HLS の両方のプロトコルがリードしています。一方では、RTMP は配信のための技術としては完全に支持されなくなり、HLS は理想的な入力プロトコルではありません。そのため、ほとんどのコンテンツ ディストリビューターは、メディア サーバーまたはクラウドベースのビデオ プラットフォームに依存して、コンテンツをあるプロトコルから別のプロトコルにトランスコードしています。

再生のサポート

もし視聴者がストリームにアクセスできないとしたら、ストリームを配信する意味は何でしょうか？ エンドユーザーへの配信で RTMP が役割を果たさなくなった理由は、再生サポートの欠如です。また、ユビキタスな再生サポートが、HLS が今日最も人気のあるプロトコルである理由です。

エンコーダーのサポート

再生のサポートの逆は、エンコーダーのサポートです。 RTMP は、RTMP エンコーダーがすでに市場で普及しているため、多くの欠陥があるにもかかわらず、強い地位を確保しています。同様に、RTSP は IP カメラに最適なプロトコルであるため、監視映像の業界での地位が維持されています。

WebRTC は、追加の技術を必要とせずにブラウザーベースの映像の公開と再生に利用できるという点で独特な技術であり、プロダクション品質のエンコーダーとカメラを必要としないユースケースでシンプルなストリーミングを実現可能にします。

スケーラビリティ

HLS はスケーラビリティと同義です。幅広くサポートされている HTTP ベースのプロトコルは、Web サーバーを活用して、今日の配信対象となりえるあらゆるデバイスに配信することができます。しかし、スケーラビリティを持って配信されるプロトコルは、配信の遅延 (レイテンシー) の観点で欠点があります。これは、従来、遅延 (レイテンシー) とスケーラビリティが相容れないものであったためです。ただし、大規模なリアルタイム ストリーミングなどの新しい技術は、この矛盾を解決することができます。

訳注: HLS, MPEG-DASH のような今日でも市場で広く使われている HTTP ベースのアダプティブストリーミングはスケーラビリティをもって配信することができます。

遅延（レイテンシー）

低遅延の HLS、MPEG-DASH 向けの低遅延の CMAF、および、WebRTC はすべて、(低遅延の) 高速な配信を念頭に置いて設計されています。インタラクティブ ビデオ環境を展開する場合は、これら 3 つの配信プロトコルのいずれかを検討する必要があります。

体験品質

一部のニッチなビデオ エクスペリエンスではリアルタイム配信が不可欠ですが、高品質の配信が最低限必要なものになっています。視聴者はもはや、スムーズで高解像度のストリームを評価しなくなりました。彼らはただそれを (当たり前のものとして) 期待しています。そして、最高のユーザー エクスペリエンス (視聴者体験) を確保するための最善の策は、アダプティブ ビットレート ストリーミングをサポートするプロトコルを使用することです。これは、HLS と MPEG-DASH によって展開されるコアとなる技術です。

セキュリティ

最後になりましたが、コンテンツ保護を検討する必要があるでしょう。暗号化とデジタル著作権管理 (DRM) は、HLS と MPEG-DASH では標準でサポートされています。一方、WebRTC はブラウザーによって保護されていますが、放送ワークフローのための DRM 機能と標準的なすぐに使えるセキュリティ対策が欠けています。したがって、ワークフローを設計するときは、このことを念頭に置いておく必要があります。

結論

2022 年の映像ストリーミングに最適なプロトコルは？

それはあなた次第です。

訳注: 特にどのプロトコルが優れているなどの比較ができないので、お客様のビデオワークフローの要件に依存します。

適切なビデオ技術は、各々のビジネスのニーズによって異なります。 最適なプロトコルを探すのではなく、最も柔軟性のあるビデオ プラットフォームを探すことがよいでしょう。

幅広いプロトコルから選択できることは、遅延を減らしたり、再生の互換性を高めたり、さらにはリモート ビデオ コントリビューションの課題に対処しようとする方法を探しているすべての人にとって不可欠となります。 さらに、今日の多くのビデオ エンジニアは、入力・転送と配信でさまざまなプロトコルを使用するハイブリッド ワークフローを構築しています。

ビデオは、現在、あらゆる業界のビジネスに力を与えています。そのため、規範的なストリーミング ワークフローや型にはまった技術だけではうまくいきません。 しかし、読者にとっては幸運なことに、Wowza の柔軟なビデオ プラットフォームは、幅広いプロトコルをサポートし、様々なニーズに合わせてカスタマイズできます。

ストリーミング ワークフローを設計する最適な方法について専門家に相談したり、無料でトライアルを開始したりするには、今すぐお問い合わせください。