RTMP 代替案 [ Wowza Blog 翻訳 ]
オリジナル:https://www.wowza.com/blog/rtmp-alternatives-2022(2022 年 11 月投稿分)
RTMP はかつて、メディアのインジェストとイーグレスの両方において標準的なプロトコルでした。最近では、最も人気のあるインジェストプロトコルであり続けています。しかし、ストリーミングプロトコルは進化し続けており、特に最近では WebRTC の成長により、開発者がいつまで RTMP に頼るのか、それとも数ある RTMP の代替プロトコルに頼るのかは分かりません。
RTMP が最後の足掻きであるかどうかに関わらず、ストリーミングのニーズにより適した代替インジェストのプロトコルが存在します。これらの RTMP 代替プロトコルと、今後登場するかもしれない他のプロトコルは、ストリーミング戦略を最適化する上で、十分に検討に値するものかと思います。この記事では、インジェストプロトコルとしての RTMP に代わる選択肢、2 つのプロトコルの利点、そしてこれから登場する可能性のあるものを探っています。
RTMPとは
RTMP とは、Real-Time Messaging Protocol の略です。プレイヤーのクライアントとサーバの間で、TCP(Transmission Control Protocol)接続を一定に保つことで動作します。この TCP 接続は、クライアントとサーバのハンドシェイクを必要とし、安定した接続と信頼性の高いストリームを保証します。
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 が適しているかどうか、適切な判断をすることが重要です。
プロトコルを選択する際の懸念点
では、ストリームのインジェストプロトコルはどのように選択すればよいのでしょうか。ライブおよびオンデマンドのストリーミングに共通する以下の事項に注意してください。
- スケーラビリティ:視聴者は何人か?
- 遅延:視聴者にとっての速度の重要性は?
- 品質:目標に対して品質はどの程度重要か?
- 独自規格とオープン規格:ストリーミングソリューションをカスタマイズするために必要な自由度は?また、どの程度の費用を投じられますか?
- コーデック要件:利用可能なプロトコルを制限するような特定のオーディオまたはビデオコーデックの要件があるか?
しかし、どのプロトコルがあなたのニーズに最も適しているかという基準は、用途に起因します。以下の RTMP の選択肢を読みながら、考えてみましょう。
- リアルタイムのやり取りが必要なのか?
- 高度なコンテンツ保護が必要か?
- 視聴者は誰なのか?視聴者の規模は?
- どのようなプラットフォームでストリーミングするのか?
RTMP を RTSP に置き換える
RTMP と同様に、RTSP (Real-Time Streaming Protocol)も古いプロトコルであり、今日ではインジェストのみに使用されています。RTSP は、特に IP カメラや同様のシステムで、安全性の高い低遅延のストリーミングを実現するために使用されます。言い換えれば、監視が目的であれば、RTSP はよりベターなインジェストの選択肢かもしれません。
RTSP の長所と短所
RTSP 長所
- 高い安全性
- 多くの IP カメラに搭載されている
- 特定のユースケースで一般的にサポートされている
RTSP 短所
- レガシーなプロトコルなので、廃止の可能性がある
- Android や iOS ではサポートされていないため、一般的にはインジェストのみに使用される
- ニッチな用途以外のエンコーダでは広くサポートされていない
RTSP のベストな使用例
結論としては、RTSP は IP カメラが関わる場合に最も適しています。これは、IP カメラの間で広く使用されているため、サポートも広範囲にされているからです。もし、IP カメラを使ったセキュリティシステムでストリーミングをしたいのであれば、これ以上のインジェストプロトコルはないでしょう。
結論:RTMP と RTSP の比較
この 2 つを比較するのは、正直言って難しいです。RTSP と RTMP は、どちらか一方を選ぶというより、並べて考えるのがベストです。どちらもインジェストにのみ使用されるようになった古いプロトコルであり、インジェストにどちらを使用しても、その後のメディアの転送にはトランスマックスが必要になります。RTMP はエンコーダによってより広くサポートされているため、より一般的に適用可能なオプションとなっていますが、RTSP はよりニッチなプロトコルとなっています。
RTMP を SRT に置き換える
SRT(Secure Reliable Transport) は、予測不可能な公共ネットワーク上でコンテンツを迅速かつ確実にストリーミングするために設計されたオープンソースのプロトコルです。現在では、このプロトコルも一般的にはインジェストのみに使用されています。しかし、SRT はまだ新しいプロトコルであり、エンコーダとメディアサーバはこのプロトコルのサポートを拡大している途中です。いずれは、SRT が効果的なエンドツーエンドの選択肢となる可能性があります。
最新の Wowza LinkedIn の投票では、SRT が RTMP の代替として人気を集めています。
SRT の長所と短所
SRT の長所
- オープンソース
- 高品質・低遅延
- コーデックに依存しない
- 低遅延でありながらパケットロスを考慮した信頼性
- AES 128/256 暗号によるエンド・ツー・エンドのセキュリティを提供
SRT の短所
- 多くの再生機器でまだ広くサポートされていない
- 大人数での再生にはあまり向いていない
SRT のベストな使用例
SRT は、予測不可能な公共ネットワークでのライブストリーミングのために設計されています。そのため、ストリーミングにベストな使用例は、その利点を生活かしたものです。2020 年のバーチャル式の NFLドラフトのようなインタラクティブで大規模な放送は、こういった技術から恩恵を得ています。
結論:RTMP と SRT の比較
どちらのストリーミングプロトコルも、高速で信頼性が高く、安全なのが特長です。SRT は RTMP よりも高速で、低遅延を維持しながら信頼性の低いネットワークで配信するために特別に設計されたプロトコルとして、より効果的にパケットロスに対処しています。SRT はまだ開発中の新しい技術で、インジェスト側とイーグレス側の両方でサポートが拡大しています。つまり、RTMP ほどエンコーダが広くサポートしているわけではありませんが、いつか SRT が広く使われる可能性があります。
RTMP を WebRTC に置き換える
WebRTC (Web Real-Time Communications)は、超低遅延ストリーミングを提供するために協働するプロトコル、標準、および JavaScript API の集合体です。このため、WebRTC は「ストリーミング プロトコル」と呼ばれ、RTMP などの他のプロトコルと比較されることがよくあります。WebRTC はインジェストとイーグレスの両方で機能しますが、最も頻繁に使用されるのは後者です。この比較では、インジェストプロトコルとしての WebRTC に焦点を当てます。
WebRTC の長所と短所
WebRTC 長所
- 超低遅延(秒以下)
- オープンソース
- 継続的に進化する機能とサポート
- 高い柔軟性
- エンコーダを必要としない、シンプルなブラウザベースの配信が可能
- WebRTC によるサイマルキャスティングでストリーム品質を向上
WebRTC 短所
- コア部分の拡張性が低い
- 安全性が低い
- アダプティブ・ビットレート・ストリーミング(ABR)には非対応
- デジタル著作権管理(DRM)プロバイダーと互換性がない
WebRTC のベストな使用例
WebRTC の最大のセールスポイントは、1 秒以下の遅延であり、ほぼリアルタイムのインタラクティブなストリーミングに理想的な選択肢となります。しかし、スケーラビリティが限られているため、大規模な配信をする場合は、より複雑なワークフローが必要になる場合があります。
結論:RTMPと WebRTC 比較した場合
RTMP から WebRTC へのワークフローは、エンドツーエンドの WebRTC ワークフローよりはるかに効果的です。しかし、ブラウザのサポートがますます良くなったおかげで、インジェストプロトコルとしての実用性は近年変化してきており、RTMP に代わるより競争力のある選択肢となっています。SRT と同様に、WebRTC も開発が続けられており、様々なワークフローにおいて RTMP や RTSP のような古いプロトコルに取って代わる可能性があります。
WHIP の特長
Milicast は、WebRTC インジェストの課題に対応するため、WHIP (WebRTC HTTP Ingest Protocol)を開発しました。しばらくの間、WebRTC はブラウザベースの配信でのみ動作し、プロフェッショナルなエンコーダを経由した WebRTC のインジェストは不可能でした。現在ではより多くのプロフェッショナルなエンコーダが WebRTC をサポートしていますが、WHIP は依然として WebRTC インジェストをするための一般的な選択肢です。WHIP はエンコードソフトウェアとハードウェアに、メディアサーバと通信する際の標準的な信号プロトコルを提供し、ベンダーを超えて WebRTC のインジェストを可能にします。さらに WHIP は、エンコーダとメディアサーバ間の接続の障壁を取り除きながら、RTMP に対する遅延の利点を維持し、WebRTC を直接インジェストすることを可能にします。
RTMP から RIST への置き換え
RIST(Reliable Internet Stream Transport)は、オープンソースかつオープンスタンダードなプロトコルで、特に予測不可能な公共ネットワークでデータを転送するために設計されています。RIST は SRT と本質的には同じ性能で、SRT の後継と意図されていました。RIST と SRT はどちらもまだ進化をしていて、非常によく似た機能をしていますが、古いデバイスとの互換性やパケットロスへの耐性という点では、RIST が SRT よりわずかに優れているように思われます。
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 のワークフロー
サポートがないにもかかわらず、RTMP は幅広いストリーミングにおいて、まだ有効な(そして広く使用されている)インジェストプロトコルです。しかし、インジェストプロトコルのみでは不十分で、エンドユーザーに配信するためのイーグレスプロトコルとペアにする必要があります。ここでは、インジェストで RTMP を使用する一般的なワークフローと、それらの特長を紹介します。
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 を開発し提供する業界のリーダー企業です。多機能な動画プレイヤーの開発だけでなく低遅延技術の開発に力を入れており、多くの企業で導入されています。
RTMP の将来と新たなテクノロジー
RTMPの未来について、最近発表されたストリーミングプロトコルについて説明し、この話を締めくくりたいと思います。ある意味、これらの新しいプロトコルの存在は、時の試練に耐えた技術である RTMP への信頼を再確認するものです。一方、新たな技術革新は新たな可能性をもたらします。
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 は、遅延を最小化するために、必要に応じて必要なメディアセグメントに優先順位をつけようとするものです。この技術はまだ開発中であり、オープンスタンダードになるにはもう少し先になりそうです。
QUIC 上のメディアを紹介
RUSH と Warp はデータ配信に QUIC を使用していますが、moq(Media over QUIC)と混同しないように注意してください。これは、QUIC と潜在的には WebTransport を使用したメディアの取り込みと配信のためのシンプルで低遅延のメディア配信ソリューションを開発する IETF の提案に関連しています。Media over QUIC、WebTransport、WebCodecs の組み合わせは、WebRTC の置き換えとして、あるいは次世代の HLS や DASH として有効かもしれませんが、まだ道半ばです。
おわりに:適切な選択肢を選ぶ
ストリーミングプロトコルの世界は、一言で言えば「広大」です。1 つの技術に追いつくまでに、他の全く新しい技術がその場所を取って代わる準備ができています。このことが、RTMP を快適なソリューションにしているのかもしれません。結局のところ、私たちは RTMP が未だに機能することをよく理解しています。しかし、本当にストリーミングソリューションを最大限に活用したいのであれば、何が最新で、何が段階的に廃止され、次に何が来るのか、何らかの指針を決めた方がよいでしょう。そのためには、目標を定め、ニーズを見極めながら考え、信頼できるストリーミングの選択肢を見つけることから始めましょう。