WebRTC、 綺麗に見るか滑らかに見るか

WebRTC Meetup Tokyo #31

まとめ
送信可能な帯域幅が狭まった場合やCPUの負荷が高い場合に、解像度とフレームレートをどのように調整するかを決めるためのdegradationPreferenceというオプションがある
基本的には、より抽象度の高いプロパティであるContent Hintを指定すればOK
degradationPreferenceにはmaintain-framerate-and-resolutionという値が新しく追加された
maintain-framerate-and-resolutionを指定するとブラウザ(libwebrtc)側での解像度・フレームレートの制御が無効化され、自前で細かい調整が実装できるようになる
MDNではdegradationPreferenceが非推奨になっているが、おそらく記載ミスなので安心して使って大丈夫

高画質版
https://docs.google.com/presentation/d/e/2PACX-1vTljVvr3HfWDHRw7-AX1Ef4JbHcd6Hb5XH0mVZsAQJQjAV7wlFw59yfsTHdXFbzFA0u2MtDGHtdaa2I/pub?start=false&loop=false&delayms=60000

Transcript

1. WebRTC、 綺麗に見るか滑らかに見るか WebRTC Meetup Tokyo #31 2025/11/27
2. 自己紹介 • @sublimer • NTT Communications NTTドコモビジネスでSkyWayを作るお仕事をし ています ◦ 先日Webhook機能をリリース[1] したので、もしよかったら使ってみてください [1] https://support.skyway.ntt.com/hc/ja/articles/52573289077017-Webhook機能のβ提供を開始しました
3. 本日お話すること・しないこと • お話すること ◦ エンコーダーを制御するためのWebRTCのオプションについて ◦ 綺麗さ(解像度)と滑らかさ(フレームレート)のトレードオフを制御する方法の説明 • お話しないこと ◦ ブラウザ(libwebrtc)側の詳細な実装の説明 • 今日のゴール ◦ アプリケーションの特性に合わせて、エンコーダーの振る舞いを制御する方法を理解する
4. 前提 • 以下の環境で動作確認をしています ◦ Google Chrome 142 ◦ macOS Sequoia ◦ 同一ホスト、同一タブ内で通信(loopback) • 以下の設定で動作確認をしています ◦ 映像のみの送信(VP8) ◦ FHD(1920 x 1080) ◦ 30 FPS ◦ 100Mbps(制限無し)と1Mbps(制限あり)で帯域幅を変更 • Firefox、Safariでは挙動が異なる可能性があります • 検証で利用したコードは公開しています ◦ https://github.com/kadoshita/webrtc-degradationpreference-demo
5. 映像のトレードオフを理解する WebRTCでは、エンコーダーに対してパラメーターを設定して、解像度やフレーム レートなどを調整する 送信可能な帯域幅が狭まった場合やCPUの負荷が高い場合は、データ量やエンコー ド処理の負荷を減らすために解像度とフレームレートのどちらか、または両方を調整 する必要が生じる degradationPreference[2] というオプションで指定できる • balanced ◦ 解像度とフレームレートの両方をいい感じにする • maintain-resolution ◦ 解像度を維持して、フレームレートの方を変化させる • maintain-framerate ◦ フレームレートを維持して、解像度の方を変化させる • One more thing… ◦ 後述 [2] https://w3c.github.io/mst-content-hint/#dom-rtcdegradationpreference
6. degradationPreferenceを指定した場合の振る舞い degradationPre ferenceの設定 解像度 フレームレート 送信開始時 帯域幅が狭 まった時 帯域幅が回復 した時 送信開始時 帯域幅が狭 まった時 帯域幅が回復 した時 未指定 徐々に上がる 下がる 徐々に上がる 変わらない 一度下がって 元に戻る 変わらない balanced 徐々に上がる 下がる 徐々に上がる 徐々に上がる 一度下がって 元に戻る 変わらない maintain-resolu tion 変わらない 変わらない 変わらない 変わらない 下がる 徐々に上がる maintain-frame rate 徐々に上がる 下がる 徐々に上がる 変わらない 一度下がって 元に戻る 変わらない
7. 未指定の挙動 送信開始時は解像度が徐々に上がる 送信開始時(11:20)
8. 未指定の挙動 帯域幅が狭まると解像度もフレームレートも下がる フレームレートは元に戻る 帯域幅が狭まった時(11:22)
9. 未指定の挙動 帯域幅が回復してもすぐに元の解像度には戻らず、解像度が徐々に上がる 帯域幅が回復した時(11:23)
10. balancedの挙動 送信開始時は解像度とフレームレートが徐々に上がる 送信開始時(17:53)
11. balancedの挙動 帯域幅が狭まると解像度もフレームレートも下がる フレームレートは元に戻る 帯域幅が狭まった時(17:55)
12. balancedの挙動 帯域幅が回復してもすぐに元の解像度には戻らず、解像度が徐々に上がる 帯域幅が回復した時(17:56)
13. maintain-resolutionの挙動 送信開始直後から指定した解像度で映像が送られる 送信開始時(11:42)
14. maintain-resolutionの挙動 帯域幅が狭まるとフレームレートのみが下がる 帯域幅が狭まった時(11:44)
15. maintain-resolutionの挙動 帯域幅が回復してもすぐに元のフレームレートには戻らず、フレームレートが徐々に上 がる 帯域幅が回復した時(11:45)
16. maintain-framerateの挙動 送信開始時は解像度が徐々に上がる 送信開始時(12:01)
17. maintain-framerateの挙動 帯域幅が狭まると解像度もフレームレートも下がる フレームレートは元に戻る 帯域幅が狭まった時(12:03)
18. maintain-framerateの挙動 帯域幅が回復してもすぐに元の解像度には戻らず、解像度が徐々に上がる 帯域幅が回復した時(12:04)
19. 結果の簡単なまとめ 映像の品質を下げる方は積極的な振る舞い 品質を上げていく方については保守的な振る舞い 帯域幅が広くなっても、元の映像品質に戻るまでに1〜2分くらいはかかる maintain-framerateでもフレームレートが下がることはある degradationPreference未指定の場合は、libwebrtc内部で maintain-framerateとして扱われる[3] 映像がカクつくよりも、ぼやける方が違和感が小さいから? [3] https://source.chromium.org/chromium/_/webrtc/src/+/19b6b65717166ec21cf1472e4da6f4bbfc96f473:media/engine/webrtc_video_engine.cc;l=1961
20. Content Hintとの違い • degradationPreference ◦ 映像の品質を下げざるを得ない場合にどうするかを指定する ◦ RTCRtpSenderのオプション ◦ 仕様としては、Content Hintの一部という位置付け • Content Hint[4] ◦ 通常時も含めて、エンコーダーに対して「ヒント」を伝えるための設定 ◦ MediaStreamTrackのプロパティ ◦ ユーザーがdegradationPreferenceを指定せず、Content Hintを指定している場合、 Content Hintの設定に応じて内部的にdegradationPreferenceが設定される 基本的には、抽象度の高いプロパティであるContent Hintの指定をすればOK 細部が重要な映像ならdetailを指定して綺麗に、動きが重要な映像ならmotionを 指定して滑らかに表示させる [4] https://w3c.github.io/mst-content-hint/#dom-mediastreamtrack-contenthint
21. degradationPreferenceの新しい値について 新たに「maintain-framerate-and-resolution」[5] が追加された 解像度とフレームレートを、ユーザー側で制御するために指定する値 ブラウザ(libwebrtc)側での解像度・フレームレートの制御を無効化し、ユーザー側 で細かいチューニングができるようになる getStatsを呼び出して必要な統計値を取得し、アプリケーション側で解像度・フレー ムレートをコントロールする必要がある(Bring Your Own Adaptation) 前述の通り、帯域幅が広くなっても元の映像品質に戻るまでに1〜2分くらいはかか るため、「できるだけすぐに映像品質を回復させたい」というユースケースなどで使 えるかもしれない [5] https://docs.google.com/presentation/d/11rr8X4aOao1AmvyoDLX8o9CPCmnDHkWGRM3nB4Q_104/edit?slide=id.g3657813d9b5_0_0#slide=id.g3657813d9b5_0_0
22. maintain-framerate-and-resolutionについて Chrome M144から利用可能らしい[6] が、Canary版(144.0.7529.0)では指定できなかった libwebrtc側の実装はあるので、JavaScriptから値を指定する部分が未実装っぽ い雰囲気 今後正式な機能としてリリースされると、Google Meetなどのつよつよサービスが 「最強のエンコーダー制御アルゴリズム」を実装してくるかもしれない [6] https://chromestatus.com/feature/5156290162720768
23. Q. degradationPreferenceは非推奨? A. いいえ MDNではdegradationPreferenceに非推奨のアイコンがついている[7] 元々はWebRTCの仕様として定義されていたが、途中で削除された[8] 代わりにContent Hintの仕様として定義された 仕様から削除された(=非推奨)と誤認されてしまったのでは? 新しい値の追加もあるので、さすがに非推奨ではないはず ”This is incorrect and needs to be updated, the feature was moved under content-hints” https://bugzilla.mozilla.org/show_bug.cgi?id=1329847#c7 [7] https://developer.mozilla.org/en-US/docs/Web/API/RTCRtpSender/setParameters#degradationpreference [8] https://github.com/w3c/webrtc-pc/pull/2399
24. おまけ Chromeの開発者ツールの「Network throttling profiles」はWebRTCの通信 も対象になる パケロスや遅延なども設定できるので、手軽に貧弱なネットワーク環境を再現できる 「No throttling」からスロットリングありに変えると、スロットリングが効かない 「100 Mbps」のような値でスロットリングありの設定にしてから、より帯域幅が狭い 設定に切り替える必要がある[9] 特に警告などは出ないのでちょっとハマった [9] https://issues.chromium.org/issues/338321620
25. まとめ 送信可能な帯域幅が狭まった場合やCPUの負荷が高い場合に、解像度とフレーム レートをどのように調整するかを決めるためのdegradationPreferenceという オプションがある 基本的には、より抽象度の高いプロパティであるContent Hintを指定すればOK degradationPreferenceにはmaintain-framerate-and-resolutionとい う値が新しく追加された maintain-framerate-and-resolutionを指定するとブラウザ(libwebrtc)側 での解像度・フレームレートの制御が無効化され、自前で細かい調整が実装できるよ うになる MDNではdegradationPreferenceが非推奨になっているが、おそらく記載ミス なので安心して使って大丈夫
26. 参考サイト • Bring Your Own Adaptation with "maintain-framerate-and-resolution" · Issue #62 · w3c/mst-content-hint • Intent to Ship: RTCDegradationPreference enum value "maintain-framerate-and-resolution" • MediaStreamTrack Content Hints • WebRTC September 2025 meeting – 16 September 2025 • Video Adaptation • RTCRtpSender: setParameters() method - Web APIs | MDN