ビデオ・ストリーミング・プロトコル。

ライブ ストリーミングを始めると、さまざまな目的を果たす略語があふれていることに気がつくでしょう。 RTMP、HLS、HDS などです。

これらの略語の多くは、さまざまなビデオ ストリーミング プロトコルに関連しています。 基本的に、プロトコルは、1 つのプログラムから別のプログラムへのデータの転送を容易にする技術的なプロセスです。 ストリーミングでは、エンコーダー、ストリーミング ホスト、そして最終的には、視聴者がストリームを表示するビデオプレーヤーとの間の動画ファイルの転送を意味します。

本日は、遭遇する最も一般的なストリーミング プロトコルをいくつか特定し、それらが何を行い、いつそれらを使用すべきかを明らかにするつもりです。 理解を助けるために関連する背景を説明するために、コーデックとコンテナー形式の関係も説明します。

ライブ ストリーミング プロトコルに飛び込む準備はできていますか

Please note that this post has been updated to reflect the latest developments in video streaming protocols as of November 2020.11.

目次

• Video Streaming Protocol とは？
• Streaming Protocol vs. Codecs vs. Codecs vs. Codecs。 コンテナー形式
• Common Video Streaming Protocols
• Video Protocol for Professional Live Streaming
• Conclusion

What is a Video Streaming Protocol?

先に進む前に、ビデオ ストリーミング プロトコルの定義についてもう少し見ておきましょう。 ほとんどのデジタル ビデオは、保存と再生の 2 つを目的として設計されています。 つまり、ビデオをストリーミングするには、まずそれをストリーム可能なファイルに変換する必要があります。 つまり、動画をストリーミングするには、まず動画をストリーミング可能なファイルに変換する必要があります。これは、動画を小さなチャンクに分割することを意味します。 これらのチャンクは、順次受信され、受信されると再生されます。 ライブ映像のストリーミングの場合、ソース映像はカメラから直接送られてきます。

ビデオ ストリーミング プロトコルは、ビデオをチャンクに分割し、視聴者に送信し、再組み立てするための標準の配信メソッドです。 たとえば、多くは「アダプティブ ビットレート」プロトコルです。 このテクノロジーは、視聴者がその時点でサポートできる最高の品質を提供します。

一部のプロトコルは、遅延、つまり、実生活で起こるイベントとそれが視聴者のスクリーンで再生される間の遅延を減らすことに重点を置いています。 また、デジタル著作権管理 (DRM) に焦点を当てたプロトコルもあります。

いくつかの特定のプロトコルを見ていく中で、これらの特徴や他の特徴を整理していきます。

ストリーミング プロトコル vs. コーデック vs. コンテナ形式

プロトコル、コーデック、コンテナ形式はそれぞれストリーミングの個別の側面となります。

中でも、ストリーミング ビデオの領域でよくある混乱の原因は、プロトコルとコーデックの違いに関連するものです。

簡単に言うと、「コーデック」という用語は、ビデオ圧縮技術を指します。 論理的には、異なるストリーミング コーデックは異なる目的のために使用されます。 たとえば、Apple ProRes はビデオ編集によく使用され、最も一般的なビデオ コーデックである H.264 はオンライン ビデオに広く使用されています。

コーデックと同様に、「フォーマット」という用語も、ビデオ ストリーミング プロトコルのコンテキストで混乱する可能性があります。 多くの場合、フォーマットは、単にビデオ ファイルのコンテナー形式を指します。 一般的なコンテナー形式には、.mp4、.m4v、.avi があります。

本質的には、コンテナー形式は、通常、動画ファイル、音声ファイル、およびメタデータを含む「箱」のように機能します。

コーデック、コンテナー形式、およびストリーミング プロトコルの間の関係を理解しやすくするために、比較してみましょう。

あなたが商人で、衣類を大量に輸送していると想像してください (衣類はビデオ コンテンツに相当します)。 ストリーミング コーデックは、スペースを節約するために衣類を束に圧縮する機械と同等です。 コンテナ形式は、これらの束が中に詰め込まれる箱車です。 ストリーミング・プロトコルは、それを目的地まで届ける線路、信号、運転手に相当します。

放送事業者として、ライブ ビデオ コンテンツがコーデック、コンテナー形式、およびストリーミング プロトコルと協調して機能することを望んでいます。

また、ほとんどのストリーミング プロトコルは、特定のコーデックしかサポートしていないということに注意することが重要です。

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

ビデオ ストリーミング プロトコルの目的について理解できたところで、現在最も一般的なビデオ ストリーミング プロトコルを比較し始めましょう。

この比較では、可能な限り、各プロトコルのユースケースも提供します。

リアルタイム メッセージング プロトコル (RTMP)

まず最初に、ベテラン プロトコルからです。 RTMP または Real-time messaging protocol です。 元々はストリーミングの初期に Macromedia によって開発されたもので、RTMP プロトコルは今でも広く使用されています。

今日、RTMP は、RTMP 対応のエンコーダーの助けを借りて、ライブ ストリームを取り込むために主に使用されています。 わかりやすく言うと、動画ホスティング プラットフォームに動画フィードを送信するようにエンコーダーをセットアップすると、その動画は RTMP プロトコルを介して CDN に到達します。 そのコンテンツは、最終的に別のプロトコル、通常は HLS ストリーミング プロトコルで視聴者に届きます。

RTMPは、かつてのように視聴者向けのビデオ ストリーミング プロトコルとして使用されることはほとんどありません。

RTMP を使用すべきなのは誰ですか

RTMP は、非常に低遅延のストリームを提供するストリーミング プロトコルです。 しかし、再生に Flash プラグインが必要なため、あまりお勧めできません。 繰り返しになりますが、ストリーム インジェストの場合は例外です。 この目的では、RTMPは依然として最良の選択肢の1つです。

Real-Time Streaming Protocol (RTSP)

おそらくあまり知られていないビデオ ストリーミング プロトコルである Real-Time Streaming Protocol (RTSP) は、1998 年に初めて公開されました。 RTSP は、特に、エンターテインメントおよび通信システムにおけるストリーミング メディア サーバーを制御するために開発されました。

2016年に、更新されたRTSP 2.0が利用可能になりました。 全体として、エンドポイント間のメディア セッションを確立および制御するためのビデオ ストリーミング プロトコルとして知られています。

RTSPは、以下で取り上げるHTTPライブ ストリーミング (HLS) プロトコルといくつかの点で類似しています。 しかし、ライブ ストリーミング データの送信は、RTSP がそれ自体で実現するものではありません。 その代わり、RTSP サーバーは、多くの場合、RTP (Real-Time Transport Protocol) および RTCP (Real-Time Control Protocol) と連携してメディア ストリームを配信します。

誰が RTSP を使うべきか

RTSPは低レイテンシーのストリーミングをサポートするために設計されており、IP カメラのフィード (セキュリティ カメラなど)、IoT デバイス (ラップトップ制御ドローンなど) やモバイル SDK などのストリーミング使用例に適した選択肢です。

しかし、1 つの重大な欠点は、RTSP のネイティブ ブラウザーのサポートが限られていることです。

RTMP と RTSP はどちらもストリーミング プロトコルであり、データがある通信システムから別のシステムに移動する方法を制御する一連のルールであることを意味します。

RTMP を使用する利点:

• 低レイテンシー。 低遅延により、インターネット接続が不安定な場合でも、ライブ ビデオ ストリームは安定した接続と視聴者のためのビデオ フィードを維持することができます。 これは、不安定なインターネット接続であなたのビデオを見るとき、視聴者に少ない「遅れ」を提供し、彼らのインターネット接続が安定した後、迅速にストリームを再開することができます。
• Adaptable。 適応性のあるフィードは、視聴者が1つの直線的な方向でフィードを見ることに縛られないことを意味します。 適応性があるため、視聴者はフィードの一部をスキップしたり巻き戻したり、ライブ ストリームが始まった後に参加することができます。
• 柔軟性。 RTMP では、さまざまな種類のメディアを 1 つのまとまったパッケージに統合し、音声、動画、およびテキストをシームレスに融合させることができます。 さらに、MP3 と AAC の両方のオーディオ ストリームや、MP4、FLV、F4V のビデオのストリーミングなど、複数のバリエーションのメディア チャンネルを持つことができます。

RTMP を使用することの短所

• HTML5 ではサポートされません。 RTMP は Flash プレーヤーでサポートされていますが、このフォーマットは陳腐化に向かって進んでいます。 HTML5 プレーヤーは急速に現代の標準になりつつありますが、RTMP は HLS などのコンバータを使用しないと HTML5 プレーヤーで再生できません。
• 帯域幅の問題。 RTMP ストリームは、低帯域幅の問題に対して特に脆弱な場合があります。 これは、ストリームの中断を頻繁に引き起こし、視聴者の体験を台無しにする可能性があります。
• HTTP の互換性がない。 HTTP 接続で RTMP フィードを直接ストリーミングすることはできません。 Web サイトで RTMP ストリームを使用するには、Flash Media Server などの特別なサーバーに接続し、サードパーティのコンテンツ配信ネットワーク (CDN) を使用する必要があります。

RTSP を使用する利点:

• 分割されたストリーミング。 視聴者に動画全体をダウンロードさせてから視聴させるのではなく、RTSP ストリームにより、ダウンロードが完了する前にコンテンツを視聴させることができます。
• カスタマイズ。 TCP (Transmission Control Protocol) や UDP (User Datagram Protocol) などの他のプロトコルを利用することで、独自のビデオ ストリーミング アプリケーションを作成することができます。

RTSP の短所

• あまり普及していない。 他のメディア ストリーミング プロトコルと比較すると、RTSP ははるかに人気がありません。 ほとんどのビデオ プレーヤーやストリーミング サービスは RTSP ストリーミングをサポートしていないため、ブラウザでストリームをブロードキャストすることがより困難になっています。 RTSPストリームをブロードキャストするには、別のRTSPライブストリーミングサービスを使用する必要があります。
• HTTP は互換性がありません。 RTMP と同様に、HTTP 上で RTSP を直接ストリーミングすることはできません。 このため、RTSP は企業内のセキュリティ システムなどのプライベート ネットワーク上でビデオをストリーミングするために設計されているため、Web ブラウザで RTSP をストリーミングする簡単でわかりやすい方法はありません。 しかし、あなたのウェブサイトに埋め込まれている追加のソフトウェアを使用して、RTSPをストリーミングすることができます。

RTMP と RTSP のどちらのストリーミング プロトコルを選択するかは、個々のビジネス ニーズと、Web サイトでコンテンツを再生できるようにするためにどれだけの追加手順を踏むかによって大きく異なります。

Dynamic Adaptive Streaming over HTTP (MPEG-DASH): 新進気鋭のプロトコル

Adaptive ストリーミング能力はプロの放送局にとって非常に価値があります。

その反対側には、MPEG-DASH があり、このシーンにおける最新のプロトコルの 1 つです。 まだ広く使用されていませんが、このプロトコルにはいくつかの大きな利点があります。

まず、アダプティブ ビットレート ストリーミングをサポートしています。 つまり、視聴者は常に、現在のインターネット接続速度がサポートできる最高のビデオ品質を受け取ることができます。

MPEG-DASH は、配信と圧縮に関する長年の技術的な問題を修正しました。 もう 1 つの利点は、MPEG-DASH が「コーデックに依存しない」、つまり、ほとんどすべてのエンコーディング フォーマットで使用できることです。 また、ブラウザベースのデジタル著作権管理 (DRM) 用の標準ベースの API である Encrypted Media Extensions (EME) と Media Source Extension (MSE) もサポートしています。

MPEG-DASH を使用すべき対象者は？

最近では、HLS と比較して MPEG-DASH は一部のプロの放送局でしか使用されていません。 しかし、将来的には標準的なテクノロジーになると考えています。

このプロトコルがまだ信じられないほど普及していない理由は、互換性 (Apple Safari および iOS デバイスがサポートしていないなど) およびその他の関連する問題に起因します。

Microsoft Smooth Streaming (MSS)

次は、Microsoft の Smooth Streaming (MSS) プロトコルです。 もともとは 2008 年に導入され、MSS はその年の夏季オリンピックに不可欠なものでした。

Smooth Streaming は、アダプティブ ビットレート ストリーミングをサポートし、DRM のための堅牢なツールをいくつか備えています。 全体として、これはストリーミングのように機能しながら、HTTP プログレッシブ ダウンロードに基づくハイブリッド メディア配信方法です。

Who Should Use Smooth Streaming?

主なターゲット層が Xbox ユーザーか Windows 固有のアプリケーションを構築する予定でない限り、MSS を主要なビデオ ストリーミング プロトコルとして使用することはお勧めしません。

HTTP ダイナミック ストリーミング (HDS)

HDS は最もお勧めできないストリーミング プロトコルです。

Adobe がストリーミング プロトコルの世界に参入したのは HTTP Dynamic Streaming (HDS) で、RTMP の後継にあたります。 RTMP と同様に、HDS はフラッシュベースのストリーミング プロトコルです。 しかし、アダプティブ ストリーミングのサポートも追加され、高品質であることに定評があります。

HDSは、遅延に関しても優れたプロトコルの 1 つです。 一方、断片化と暗号化処理により、遅延は RTMP ほど低くなく、スポーツや秒単位が重要なイベントのストリーミングにはあまり人気がありません。

誰が HDS を使用すべきでしょうか

一般的に、HDS の使用はお勧めしません。 近年、Flash のサポートがあまりにも弱くなったため、どの放送局も視聴者に到達するためにこのテクノロジーに依存せざるを得なくなったのです。 要するに、Flash プレーヤーを中心に Web ビデオを構築することは、今日では、単に悪い選択です。

HTTP ライブ ストリーミング (HLS)

最後に説明するビデオ ストリーミング プロトコルは、HTTP Live Streaming または HLS です。 Apple は当初、iPhone から Flash を削除できるようにするために、2009 年にこのプロトコルをリリースしました。 それ以来、HLS は最も広く使用されているストリーミング プロトコルとなっています。

これにはいくつかの理由があります。 まず、デスクトップ ブラウザー、スマート TV、および Android と iOS の両方のモバイル デバイスのすべてが HLS をサポートしています。 HTML5 ビデオ プレーヤーも、HDS や RTMP と比較して、HLS をネイティブでサポートしています。

これにより、ストリームをできるだけ多くの視聴者に届けることができ、HLS は、ライブ ストリームを大規模な視聴者に拡大するための、現在最も安全なプロトコルとなっています。

機能に関しては、HLS 標準はアダプティブ ビットレート ストリーミングもサポートしており、いつでも最適なビデオ品質を動的に提供します。

現在のところ、HLS の唯一の欠点は、遅延が比較的大きいことです。

Who Should Use HLS?

HLS は、堅牢で効果的であるため、今日最も広く使用されているプロトコルです。 たとえば、動画に障害が発生した場合、ストリーム中にサイトに戻る視聴者はほとんどいないことが分かっています。

また、HLS は現在 Dacast で使用されているデフォルトのストリーミング プロトコルであることをお伝えしたいと思います。

プロフェッショナルなライブ ストリーミングのためのビデオ プロトコル

どのビデオ プロトコルがプロのライブ ストリーミングに最適かご存知ですか/caption>?

おさらいすると、今日、多くのビデオ ストリーミング プロトコルが存在し、これらの多くはライブ ビデオ ストリーミングに使用できます。

ここで説明するすべてのプロトコル (TMP、RTSP、MPEG-DASH、MSS、HDS、および HLS) には、特定の放送局向けの特定の使用事例があります。 しかし、すべてを考慮すると、特にコーデックの互換性、すべてのデバイスの互換性、HTML5 ビデオ プレーヤーのネイティブ サポート、および適応ビットレート ストリーミング容量の点で、HLS がトップとなります。

覚えておいていただきたいのは、MPEG-DASH は新進気鋭のオプションであるということです。 近い将来、そのストリーム プロトコルの採用が進むことを期待してください。

結論