Media over QUICとRTMP+HLSの比較

WebRTC Meetup 10周年記念イベントでの登壇資料です
https://webrtcmeetup.connpass.com/event/313737/

Transcript

1. Media over QUICとRTMP+HLSの⽐較 Kota Yatagai (@kota_yata)
2. ⾃⼰紹介 ⼋⾕航太（ヤタガイ コウタ） 2 • 慶應義塾⼤学環境情報学部2年（村井研究室） • QUICに興味がある • WebRTCも⾼校の頃からいじっていたりする • X: @kota_yata, GitHub: kota-yata
3. 今回やったこと 新興技術Media over QUICと従来のライブ配信⼿法（RTMP+HLS）との⽐較 3 • Media over QUICについてはデコーダは⾃作、エンコーダとサーバーはMetaのOSSを利⽤ ◦ facebookexperimental/moq-go-server ◦ facebookexperimental/moq-encoder-player • RTMP+HLSについてはAmazon IVSのLow-latency Streamingを利⽤
4. Media over QUICとは？？ 4 • QUIC上で動くメディアプロトコル • コアプロトコルとしてMedia over QUIC Transport (MOQT), ストリーミングフォーマットとして WARPやLOCが存在する ◦ QUICの多重化ストリームを利⽤することでHoLブロッキングを避ける ◦ リレーサーバーの振る舞いをプロトコルに組み込んで⼤規模配信に対応
5. Media over QUICの特徴 5 1フレームごとにストリームを分けて送信できる （⼩松さんの資料から引⽤） • フレームごとにQUICのストリームを張って送信する • フレーム単位での優先順位制御（ex.新しいフレームを優先）が可能になる • パケットドロップしても⽋落するのは1フレーム分のみ • 複数トラックの時間同期が可能になる（⾳声‧映像‧MIDI‧触覚データ等）
6. Media over QUICと他プロトコルの⽐較 6 • HLSやDASHではダメなのか？ ◦ TCPを使っている限りHoLブロッキングの問題がついて回る ◦ Adaptive bitrate(ABR)やセグメント処理が遅延の原因になる（LL-*でもなお遅い） ◦ HLSやMPEG-DASHをQUIC上で使っても多重化ストリームを利⽤できない • WebRTCじゃダメなのか？ ◦ WebRTCはカスタマイズ性が著しく低い ▪ libwebrtcをいじらないといけない ▪ MoQはエンコード/デコードはWebCodecsに任せるなど、結構柔軟性がある ◦ P2Pのユースケースに特化されている（特にビデオ会議）
7. 7 デモ
8. 8 デモの構成
9. 感想 9 • jitter buffer⼊れていないとはいえMoQとても早い ◦ QUICが普及するにつれてもっと注⽬されそう • 輻輳を意図的に発⽣させたりしてその時の挙動も⽐較したい