RTMP 代替案 [ Wowza Blog 翻訳 ]

RTMP はかつて、メディアのインジェストとイーグレスの両方において標準的なプロトコルでした。最近では、最も人気のあるインジェストプロトコルであり続けています。しかし、ストリーミングプロトコルは進化し続けており、特に最近では WebRTC の成長により、開発者がいつまで RTMP に頼るのか、それとも数ある RTMP の代替プロトコルに頼るのかは分かりません。

RTMP が最後の足掻きであるかどうかに関わらず、ストリーミングのニーズにより適した代替インジェストのプロトコルが存在します。これらの RTMP 代替プロトコルと、今後登場するかもしれない他のプロトコルは、ストリーミング戦略を最適化する上で、十分に検討に値するものかと思います。この記事では、インジェストプロトコルとしての RTMP に代わる選択肢、2 つのプロトコルの利点、そしてこれから登場する可能性のあるものを探っています。

RTMP の歴史

Macromedia は 1996 年に RTMP を初めて開発し、投稿から配信までのストリーミングワークフロー全体に使用することを意図していました。その後、Adobe が 2005 年に Macromedia を買収し、かつてメジャーであった Flash Player に組み込まれました。そして 2012 年、Adobe は RTMP をオープンな仕様として公開し、そこから本格的に普及が始まりました。

その後、長い間、RTMP はライブおよびオンデマンドストリーミングのエンドツーエンドの標準とされてきました。しかし、HLS や MPEG-DASH などのHTTP ベースのプロトコルは、最終的に配信側で RTMP に取って代わりました。Apple 社のデバイスは、再生に RTMP をサポートしていなかったため、この問題に直面し、人々に HLS を使用するように促しました。さらに、Adobe が Flash のサポートを終了すると発表したことで、ブラウザは RTMP のサポートを終了し、ラストマイル配信のための RTMP の使用は現状。

インジェストとイーグレス（エグレス）を理解する

私たちは「ラストマイル」や「インジェスト」といった言葉を使ってきましたが、これらの言葉の本当の意味は何でしょうか？ RTMP がまだ有用な部分とそうでない部分を理解するためには、インジェスト（ファーストマイル）プロトコルとイーグレス（ラストマイル）プロトコルの違いを理解する必要があります。

最も単純な形式では、ストリーミングは、ある場所（ウェブカメラなど）から入ってきたメディアを、別の場所（ウェブブラウザなど）で再生するものです。しかし、通常、その間に何らかの中継が行われます。メディアサーバとコンテンツデリバリーネットワーク（CDN）は仲介役として、ストリーミングデータをより柔軟に、より安全に、より遠くまで届けることなどに役立っています。

メディアストリームは、ソースからメディアサーバへの取り込みに特定のプロトコルを使用し、メディアサーバから再生デバイスへの取り込みには別のプロトコルを使用することがあります。これらはそれぞれ、インジェストプロトコル、イーグレスプロトコルと呼ばれます。これらは同じプロトコルである場合もあれば、そうでない場合もあります。

RTMP はインジェストプロトコルとしてはまだ広く使われていますが、イーグレスプロトコルとしては廃れているため、使用する場合は、ラストマイル配信の前にデータをトランスマックスする複合ワークフローの一部である必要があります。

RTMP の長所と短所

以上のことから、RTMP の長所と短所について述べる際、インジェストプロトコルとしての RTMP の長所と短所について述べていきます。なぜならラストマイルにおいて RTMP はもはや意味がないからです。RTMP の長所と短所を考えるとき、同等のストリーミングプロトコルが同様の課題に直面していることを覚えておいてください。そして、どのプロトコルが最適かも、これからの比較を参考にしてみてください。

RTMP の長所

• 信頼性 ：3 ウェイハンドシェイクにより、より信頼性の高い接続を実現します。
• 柔軟性 ： RTMP は、オーディオとビデオ以外のメディアでも動作し、メディアタイプを効果的に組み合わせてまとまったパッケージにすることができます。これには、広告マーカー、キャプションデータ、または任意のカスタムデータに広く使用される埋め込み型時間指定メタデータが含まれます。
• 速度：RTMP は、わずか 3～5 秒の遅延でストリーミングします。

RTMP の短所

• 使用はインジェストのみ：HTTP と互換性がないため、RTMP はインジェストのみで、それを使用するには、ビデオソフトウェアまたはサービスを使用してストリームを再パッケージ化する必要があります。
• サポートが終了：RTMP の継続的に使用されているが、現在 Adobe は更新やサポートを終了。
• TCP の遅延と ※ 輻輳（ふくそう）：TCP ベースのプロトコルとして、RTMP は輻輳とパケットの再送のために、貧弱な接続で時間がかかり、遅延が生じる。
• 限られたコーデックのサポート：RTMP は、H.264 や VP8 などの古いコーデックに限定されています。 H.264 よりもエンコード効率が大幅に向上した H.265 や AV1 などの新しいコーデックはサポートされていません。

※輻輳（ふくそう）：インターネット回線や電話回線にアクセスが集中すること。

なぜ移行するのか

RTMP は、今後しばらくは存続する可能性が高いです。しかし、ラストマイルには使えないというのが、今のところ事実です。したがって、RTMP を含むストリームは、ストリームを再パッケージ化するための追加技術を利用する必要があります。言い換えれば、メディアサーバは、RTMP ストリームを配信に適したプロトコルに送信するか、再パッケージ化する必要があります。これにより、ストリーミング ワークフローが複雑になり、時間がかかり、遅延が大きくなる可能性があります。

さらに、新しいストリーミングプロトコルや関連技術が常に開発されているという事実もあります。それらは RTMP のような強力な信頼性の歴史はないかもしれませんが、RTMPとは異なり、積極的にサポートされ、改良が加えられているのです。もちろん、RTMP には長所もあれば短所もあります。RTMP が適しているかどうか、適切な判断をすることが重要です。

RTSP の長所と短所

RTSP 長所

• 高い安全性
• 多くの IP カメラに搭載されている
• 特定のユースケースで一般的にサポートされている

RTSP 短所

• レガシーなプロトコルなので、廃止の可能性がある
• Android や iOS ではサポートされていないため、一般的にはインジェストのみに使用される
• ニッチな用途以外のエンコーダでは広くサポートされていない

RTSP のベストな使用例

結論としては、RTSP は IP カメラが関わる場合に最も適しています。これは、IP カメラの間で広く使用されているため、サポートも広範囲にされているからです。もし、IP カメラを使ったセキュリティシステムでストリーミングをしたいのであれば、これ以上のインジェストプロトコルはないでしょう。

結論：RTMP と RTSP の比較

この 2 つを比較するのは、正直言って難しいです。RTSP と RTMP は、どちらか一方を選ぶというより、並べて考えるのがベストです。どちらもインジェストにのみ使用されるようになった古いプロトコルであり、インジェストにどちらを使用しても、その後のメディアの転送にはトランスマックスが必要になります。RTMP はエンコーダによってより広くサポートされているため、より一般的に適用可能なオプションとなっていますが、RTSP はよりニッチなプロトコルとなっています。

SRT の長所と短所

SRT の長所

• オープンソース
• 高品質・低遅延
• コーデックに依存しない
• 低遅延でありながらパケットロスを考慮した信頼性
• AES 128/256 暗号によるエンド・ツー・エンドのセキュリティを提供

SRT の短所

• 多くの再生機器でまだ広くサポートされていない
• 大人数での再生にはあまり向いていない

SRT のベストな使用例

SRT は、予測不可能な公共ネットワークでのライブストリーミングのために設計されています。そのため、ストリーミングにベストな使用例は、その利点を生活かしたものです。2020 年のバーチャル式の NFLドラフトのようなインタラクティブで大規模な放送は、こういった技術から恩恵を得ています。

WebRTC の長所と短所

WebRTC 長所

• 超低遅延（秒以下）
• オープンソース
• 継続的に進化する機能とサポート
• 高い柔軟性
• エンコーダを必要としない、シンプルなブラウザベースの配信が可能
• WebRTC によるサイマルキャスティングでストリーム品質を向上

WebRTC 短所

• コア部分の拡張性が低い
• 安全性が低い
• アダプティブ・ビットレート・ストリーミング（ABR）には非対応
• デジタル著作権管理（DRM）プロバイダーと互換性がない

WebRTC のベストな使用例

WebRTC の最大のセールスポイントは、1 秒以下の遅延であり、ほぼリアルタイムのインタラクティブなストリーミングに理想的な選択肢となります。しかし、スケーラビリティが限られているため、大規模な配信をする場合は、より複雑なワークフローが必要になる場合があります。

結論：RTMPと WebRTC 比較した場合

RTMP から WebRTC へのワークフローは、エンドツーエンドの WebRTC ワークフローよりはるかに効果的です。しかし、ブラウザのサポートがますます良くなったおかげで、インジェストプロトコルとしての実用性は近年変化してきており、RTMP に代わるより競争力のある選択肢となっています。SRT と同様に、WebRTC も開発が続けられており、様々なワークフローにおいて RTMP や RTSP のような古いプロトコルに取って代わる可能性があります。

RIST の長所と短所

RIST 長所

• オープンソース、オープンスタンダード
• 低遅延・高品質
• 不安定なネットワークでも高い信頼性
• DTLS を含むエンドツーエンドの暗号化をサポート

RIST 短所

• SRT に比べエンコーダやメディアサーバのサポートが少ない
• 多くの再生機でサポートされていない
• 大規模な視聴者に向けての再生にはあまり適していない

RIST のベストな使用例

SRT の答えとして、RIST の使用例は類似しています。RIST は、予測不可能なネットワーク、特にインターネットをナビゲートするのに役立ちます。その速度と品質は、複数のプラットフォームへのライブストリーミング（サイマルキャスティング）のための選択肢となります。

結論：RTMP と RIST の比較

RIST と SRT を比較するのは、両者の目的が一致しているため、より理にかなっていると言えます。重要なのは、どちらかのプロトコルが RTMP より使用者に適しているかどうかです。SRT と同様に、「ロスの多いネットワークでストリーミングしているか？」と「パケットロスを心配しているか？」などが問題になります。

Zixi の特長

Zixi の RIST 実装は、オープンソースであることによる利点、すなわち特定のベンダーに依存しないことによる柔軟性に欠けています。実際、Zixi は、VideoFlow や QVidium など、RIST をサポートする多くの商用ベンダーの 1 つです。とはいえ、商用プロトコルは、ゼロからソリューションを構築するのとは対照的に、より機能的なものを求めている人々にとって重要な役割を担っています。

Zixi （ジクシー）は、インターネット及び閉域網における、レイテンシー（遅延）やパケットロス（データ欠損）、ジッター（映像音声乱れ）を解決することによって、IP ネットワークに、放送品質の配信および伝送を実現させるソフトウェアシステムです。

RTMP から HLS/DASH

RTMP から Apple の HLS のワークフローは、品質と（多かれ少なかれ）速度を維持しつつ、全体的な互換性を最大化します。結局のところ、HLS は最も広く互換性のあるイーグレスプロトコルであり、様々な再生デバイスの視聴者にリーチしたいと考える人にとって理想的なプロトコルとなっています。また、HTTP ベースのプロトコルは、CDN を介してより多くの視聴者に簡単にスケーリングできます。さらに、HLS と DASH はどちらも DRM、キャプション、広告挿入をサポートしています。

RTMPからWebRTCへ

RTMP から WebRTC のワークフローは、WebRTC の超低遅延を利用したいが、WebRTC インジェストをサポートするエンコーダがない場合によく使用されるワークフローです。このワークフローを使えば、簡単に生のメディアストリームをキャプチャし、RTMP でエンコードして、メディアサーバに送り、トランスコードとトランスマックス（WebRTC に変更すること）を行うことができます。要するに、簡単なキャプチャとリアルタイム配信の両方を手に入れることができる、わかりやすい方法なのです。Wowza 独自の Real-Time Streaming at Scale は、このワークフローをサポートし、幅広い視聴者に超低遅延を提供します。

Wowza VideoのReal Time Streaming at Scale を使った RTMP から WebRTC のワークフロー

HESP の特長

HESP（High Efficiency Streaming Protocol）は、ほとんどの CDN と互換性のある HTTP ベースのプロトコルで超低遅延ストリーミングを行うために THEO technologies 社 によって開発されました。これは、HLS と DASH の間のハイブリッドなオプションと考えられていますが、まだ開発中でありますが、注目に値します。THEO 社 はこのプロトコルの標準化に向けて取り組んでいます。HTTP ベースの別の候補が登場することも考えられます。

THEO 社は HMTL5 ベースの低遅延動画プレイヤーである THEOplayer を開発し提供する業界のリーダー企業です。多機能な動画プレイヤーの開発だけでなく低遅延技術の開発に力を入れており、多くの企業で導入されています。

RUSH の紹介

RUSH（Reliable (unreliable) Streaming Protocol）は、ライブストリーミングビデオのためのアプリケーションレベルのインジェスト専用プロトコルです。この新しいプロトコルは、RTMPの（一種の）代替として Facebook によって最も実装されています。しかし、現実的には、RTMP を置き換えるものではありません。むしろ、メディアエンコーダに実装されるものです。QUIC（RushはQuick UDP Internet Connections） の上で実行されます。これは、TCP 接続を利用する RTMP と対照的であることが注目されます。

Warp の紹介

Facebook が RUSH を採用したように、Twitch も Warp を採用しています。Warp は、QUIC 上で分割されたライブビデオデータを転送するもので、RUSH に似ています。しかし、RUSH とは異なり、インジェストとイーグレスの両方で動作します。このように、RTMP だけでなく、HLS/DASH の代替も目指しています。Warp は、遅延を最小化するために、必要に応じて必要なメディアセグメントに優先順位をつけようとするものです。この技術はまだ開発中であり、オープンスタンダードになるにはもう少し先になりそうです。