編集部注: 以下は、Media over QUIC の開発者の一人である Luke Curley 氏によるスポンサー付きのゲスト投稿です。以下で表明されている見解、技術的視点、および意見はすべて執筆者個人のものであり、Fastly の見解、プロダクトの提供内容、および技術仕様とは一切関係ありません。
Fastly ファンの皆様、こんにちは。
私は Luke (別名 @kixelated) で、Media over QUIC の開発者のひとりです。Fastly が私の MoQ に関するブログ投稿を気に入ってくれ、さらに記事を執筆できるようにスポンサーをしてくれました。どういうわけか...
面白いのは、このブログ投稿のコピーが以下のように2つあるということです:
MoQ と Formula 1に関するこの通常の投稿。
Lightning McQueen に関する型破りな投稿。
お好みの手法を選択してください。ここでは、MoQ をファストレーンで活用するさまざまな方法について学びます。どちらにしても、不正確にトレースされた車の画像が得られることになります。少なくとも AI で生成されたものではありません。
対応の現状
例えば、あなたが F1 の大ファンであっても、可処分所得というちょっとした問題のために、すべてのレースに行くことはできません。
遅かれ早かれ、リビングルームからレースを観戦したくなるでしょう。インターネット経由でレースをライブストリーミングして、皆さんにお届けする方法が必要なのです。
過去10年間、その答えは HLS/DASH でした。メディアストリームを取得し、0.5秒〜4秒のチャンクに分割して、HTTP 経由で配信します。退屈ではありますが、しっかりと機能し、Fastly はそれを上手にこなしています (ちなみにスポンサーによるシリングです) 。
問題は、以下のようなレイテンシの壁にぶつかることです。
メディアをバッチ単位でフラッシュすると、レイテンシが発生する (0.5秒～4秒)。
ネットワークの輻輳が、ヘッドオブラインブロッキングやバッファリングを引き起こす。
バッファリングが1秒発生するごとに、レイテンシはさらに増大する。
このレイテンシの壁こそが、私が Twitch 在籍時に MoQ を開発した理由です。その目的は、ライブストリーミングをよりインタラクティブに (そしてより退屈しないものに) することでした。フレームをストリーミングし、ブロックする代わりに時々ドロップします。
どんなに LL- プリフィックスや ULTRA LOW LATENCY のマーケティングを展開しても、これを解決することはできません。ヘッドオブラインブロッキングを回避するために、至急新しいプロトコルが必要です。
ファン向け MoQ
まず、触れづらい問題について取り上げたいと思います。 私はかつて高品質なコンテンツに MoQ は必要ない、 とお伝えしました。
そして、それは事実です。ライブストリームのすべてのフレームを確認したい場合、MoQ から得られるものはあまりありません。ネットワークの不具合を解消するために大きなバッファを指定した HLS/DASH を使用する方がはるかによいでしょう。YouTube が数分の分量の動画を事前にダウンロードするのと同様です。
それはそうですが、待てば常に画質が良くなりますから。しかし、画質を犠牲にしてでも低レイテンシを好むユーザーもいるという仮説です。
多くの場合、ライブストリームを視聴する醍醐味は、392周のあらゆるミリ秒の一瞬を見ることではなく、リアルタイムでストーリーの一部になることです。そもそも Twitch が存在するのはそのためであり、品質よりもインタラクティブ性の方が重要なのです。
ユーザーはレースに賭けているのかもしれないし、ソーシャルメディアに投稿しているのかもしれないし、あるいは単に誰よりも早く知りたいだけかもしれません。最下位になるのは気分が悪いものです。隣の人が393ラップ目に到達しているのに、自分はまだ392ラップ目であることを知るのですから。
いずれにせよ、その仕組みについて説明しなければ、技術的なブログ投稿とは言えません。MoQは、(依存関係の順序に従って) 古いコンテンツよりも新しいコンテンツを優先できます。そのため、各閲覧者は、中央にギャップがあるか、最後にギャップがあるかを選択できます。
ここには間違いなくトレードオフが存在します。しかし、それこそが MoQ の魅力でもあります。レイテンシを自由に上げ下げして調整できるダイヤルのようなものです。
NOTE: MoQ は、HLS または DASH に期待される品質やレイテンシと同等の性能を実現できます。Fastly は、より低いレイテンシの下限を許容しています。
自動車向けの MoQ
もともとはファンのために MoQ を作ったのですが、企業はどうしても車上で稼働させたがるのです。あるいはドローンで。あるいはボートで。
ライブストリーミングの課題の1つは、車両からコンテンツを取り出すことです。セルラーネットワークや衛星ネットワークは複雑で混乱しています。私は普段 F1 を観戦しませんが、切り抜き映像などを見ると、車載カメラの映像はひどいものです。
私はラジオスターではなくビデオスターですが、それはおそらくネットワーキングによるものだと推測しています。追跡の周囲には、デッドゾーンや干渉などが生じる可能性があります。信号伝送の現実として、帯域幅が高くなる期間、低くなる期間、そしてゼロになる期間に対処しなければなりません。
F1 マシンからのフィードには、UDP 上の RTP のようなものが使用されます。非常に多様なアプローチが存在しますが、通常、RTP パブリッシャーはフレームが永久に破棄されるまでに 約100 ms の期限を設定します。そのため、わずかな信号干渉によって、アーティファクトやティアリング、映像のフリーズが発生します。
しかし、MoQ はあきらめません。
先ほどお話ししたように、MoQ は代わりに (依存関係の順序で) より新しいデータを優先して送信します。古いデータは破棄されず、RAM にキューイングされます (有効期限 (TTL) まで) 。帯域幅が回復すると、古い映像を永久に失うことなくバックフィルできます。
各 MoQ サブスクライバーは、次のように各フレームをどれくらい待機するかを個別に決定します。
ライブストリーミングは最大1秒間待機する可能性があります。
インスタントリレーは最大10秒間待機する場合があります
VOD 録画は最大1分間待機する場合があります。
この余分な時間により、古いフレームが到着するまでの時間がさらに長くなります。リアルタイムフィードはかなり劣化している可能性がありますが、VOD は非常にクリアな状態です。
ロボットのための MoQ
ライブストリーミングを必要としているのは人間だけではありません。ここでロボットの登場です。彼らも「バイト (byte)」します。
MoQ は以下のように、メディア以外の用途にも活用できることがわかっています。
スピードメーター ?ライブストリーミング
ステアリングホイール ?ライブストリーミング
Gフォースセンサー ?信じられないかもしれませんが、ライブストリーミング
実際、メディアに特別なところはありません。単なるデルタ符号化データです。JSON を含め、多くのものをデルタエンコードできます。
ネットワークには限りがあるため、メディアを細かく分割します。個々の追跡、グループ、フレーム、パケットは、メディアストリームを停止することなくドロップされる可能性があります。実際のところ、一部のバイトは他のバイトほど価値がありません。
難しいのは、ハンプティを元通りに組み立てることです。それが、タイムスタンプを使用する理由です。タイムスタンプは、ある出来事が他の出来事と比較していつ起こったかを教えてくれます。メタデータにもタイムスタンプが付与されて、音声や映像のフレームと関連付けられます。
あなたは赤い錠剤を飲んで、あらゆることに MoQ を使うことができますし、そうすべきです。次の組み合わせの単一の協調 QUIC 接続: 「コントロール > オーディオ > メタデータ > ビデオ」
豆知識: MoQ は Starlink 経由でドローンを遠隔操縦するために使用されています。カメラフィードだけでなく、コントロールにも使用されています！
そして確かに、これは一見シンプルに思えますが、WebRTC が完全に台無しにしている部分でもあります。メタデータには別の接続を使用する必要があり、タイムスタンプはブラウザ上で公開されません。
追跡向け MoQ
実は、レーストラックの周りには非常に多くのビデオカメラがあります。そして、それらを見たいと思っている人は非常に多いのです。
もちろん私たちは、閲覧者をそれぞれのカメラに直接接続させたくはありません。その貧弱なビデオカメラが同じフィードのコピーを10万回も配信できるわけがありません。放送スタジオがそれらの入力フィードを受け取り、配信用のシンジケートフィードに統合してもらいたいと考えています。
しかし、複数の放送局が同じ映像を欲しがっている場合はどうなるでしょうか ?中継車は高額であり、予算的に利用できる帯域幅にも限りがあります。同じ映像を複数送信することは避けたいですし、誰も求めていない映像を送信することも避けたいところです。
ここで MoQ の真価が発揮されます。
moq-relay は、1 パブリッシャーと N サブスクライバー (ブロードキャストまたはトラックごと) を接続するシンプルなプロキシです。moq-relay インスタンスが互いに接続すると、自動的にクラスタが形成されます。ご自身でホスティングすることも (すべてオープンソースです) 、CDN に料金を支払ってホスティングを依頼することもできます。
moq-relay はディスカバリー、ルーティング、プロキシ処理を行います。例えば、
各カメラは
192.168.420.69の自己ホスト型の moq-relay に接続します。moq-relay は
--cluster-connect https://cdn.moq.dev/f1を指定して実行されます。Studio クライアント (またはリレー !) は
https://cdn.moq.dev/f1に接続します。
不思議なことに、すべてのカメラフィードがどのリレーでも自動的に利用可能になり、必要に応じて自動的にプロキシされます。また、下流のサブスクライバーの数に関係なく、各 moq-relay インスタンス間で送信されるコピーは常に1つだけです。
会場のインターネット接続が不安定で、高額な衛星中継車を使用するような状況において、これは非常に大きな意味を持ちます。各レーストラックでいくつかの moq-relay インスタンスを実行してすべてのフィードを自動的に集約し、CDN に公開します。とても簡単です !
また、確立できる接続数に制限はありません。moq-lite は、同等の場合は最も短いパスの接続を使用します。片方の接続はイーサネット経由、もう片方は衛星経由、といった具合に自由に設定してみてください。
最後に
Media over QUIC には、メディアの枠を超えて、数多くの興味深いユースケースがあります。これこそがライブストリーミングの未来です。ぜひ皆さんも仲間に加わってください。では出発です。
この記事のスポンサーになっていただいた Fastly に改めて感謝いたします。MoQ について何か書くように言われましたので、書いてみた次第です。免責事項: 私自身は F1 は観戦すらしません (笑)。
執筆: @kixelated。MoQ の詳細については、お気軽にメールでお問い合わせいただくか、moq.dev をご確認ください。
