通信状態が悪いときでも、高画質ビデオ通話を維持する方法

2021年6月9日 17:16

こんにちは。SkyWayのTechSol（テクニカルソリューション）チームの馬場です。

お客様がSkyWayを使って事業を成功していただくためのサポートをすることがメインミッションです。
皆様と直接お話をさせていただくことも多いかと思いますのでよろしくお願いします。

最近、通信環境が悪いときにも映像の画質を維持したいという要望が増えています。
例えば、商談におけるユースケースを想定してみましょう。
説明資料をクライアントに画面共有する際は、クライアントが画面共有中の資料の文字をはっきりと読めることが重要になってきます。
つまり、映像のフレームレートは下がってもいいから解像度は維持したいというユースケースです。

そこで本日は、上記要望に対して有効な手法である「アダプティブビットレートのコントロール」についてご紹介します。

この記事を読むとできるようになること

SkyWayを含むWebRTCを用いたビデオ通話で、通信環境が悪い場合に、解像度とフレームレートのどちらかを維持するよう指定することでできるようになります。
※Chrome、Edge、Safariブラウザで正常に動作することを確認しています。

アダプティブビットレート(ABR)とは

ABRとは通信状況に応じて、送信するデータのビットレートを自動で調節する機能です。
具体的には回線状況に応じたエンコードパラメータ(解像度・フレームレートなど)の調整により、ビットレートを調整します。

インターネット回線を使ってメディアのやり取りを行うWebRTCではとても重要な機能です。
パブリックなインターネット回線を利用して映像トラフィックをやり取りするため、回線帯域を分け合うための制御が必要となります。
libwebrtc(オープンソースのWebRTCエンジン。主要なブラウザで採用)を利用している場合には、Google Congestion Controlに基づいた制御が行われます。

WebRTCにおけるABRについて詳細に知りたい場合は、下記の記事をお読みください。

RFC: A Google Congestion Control Algorithm for Real-Time Communication
Qiita: WebRTC 映像フロー制御の仕組み - Google Congestion Control
Qiita: WebRTCの映像フロー制御の働きを実際に確かめてみた

WebRTCにおけるABRのコントロール

通常、WebRTCでは、ABRにより混み合っている回線や細い回線でもできる限り途切れずに通話することができます。

一方で、冒頭で述べたように解像度やビットレートを維持したいというユースケースも存在します。

このユースケースに応えるのがContent Hintsです。

Content Hintsとは

Content Hintsを利用することで、送信するメディアの特性に応じて、ABRでビットレートを調整する際のパラメータをコントロールすることができます。
W3C Working Draft MediaStreamTrack Content Hints

Content HintsはMediaStreamTrackのプロパティとして実装されています。
※ Content HintsとしてはChrome M60で実装されたものですが、Chrome M83以降でビットレートを調整する際のパラメータに指示が出せるようになったようです。

例えば、解像度を維持したい場合には、このContent Hintsに"detail" または "text" を指定してください。

なお、Content HintsのValueとしては下記が与えられます。
※ ここでは、kind=videoのHintsについてのみフォーカスします。kind=audioのHintsについては、W3C Working Draftなどのドキュメントを参照してください。
※ 以下説明は、W3C Working Draftのドキュメントの和訳です。

contentHint=""
ヒントは提供されていません。実装は、含まれているビデオコンテンツをどのように処理するかについて、十分な情報に基づいて推測する必要があります。
これは、たとえば、トラックがどのように開かれたか、またはコンテンツ分析を行うことによって推測できます。

contentHint=""は、フレームレートと解像度をバランスして落とします。

contentHint="motion"
トラックは、動きが重要なビデオが含まれているように扱う必要があります。
これは通常、ウェブカメラのビデオ、映画、またはビデオゲームです。
ターゲットのビットレートを維持しながら、モーションを可能な限り維持するために、量子化アーティファクトとダウンスケーリングを使用できます。妥協が必要な低ビットレートでは、エッジの品質や詳細よりもフレームレートの維持に多くの労力が費やされます。

contentHint="motion" はフレームレートを維持し、解像度を落とします。

contentHint="detail"
トラックは、ビデオの詳細が特に重要であるかのように扱う必要があります。
これは通常、テキストコンテンツ、絵画、線画を含むプレゼンテーションやWebページに適用されます。
この設定は通常、スムーズな再生ではなく、結果の個々のフレームの詳細を最適化します。
小さなテキストや線画を理解できないようにする量子化またはダウンスケーリングからのアーティファクトは避ける必要があります。

contentHint="detail"は解像度を維持し、フレームレートを落とします。

contentHint="text"
トラックは、ビデオの詳細が特に重要であるかのように扱う必要があり、重要な鋭いエッジと一貫した色の領域が頻繁に発生する可能性があります。
これは通常、テキストコンテンツを含むプレゼンテーションまたはWebページに適用されます。
この設定は通常、スムーズな再生ではなく、結果の個々のフレームの詳細を最適化し、テキストレンダリングを最適化するエンコーダツールを利用する場合があります。
小さなテキストや線画を理解できないようにする量子化またはダウンスケーリングからのアーティファクトは避ける必要があります。

contentHint="text"は解像度を維持し、フレームレートを落とします。
さらに、コーデックがAV1の場合は、"text"モードのエンコーディングツールをアクティブにします。

Content Hintsを試してみた

実際に試してみました。

検証条件

以下の条件で検証しました。

MediaStream Constraintsで指定したidealの解像度と、カメラの最大解像度が1024 x 720であることから、回線状況さえ良ければ1024 x 720の解像度で映像が伝送されることが期待されます。

検証手順

条件1-1 および 1-2（または、条件2-1 および 2-2, 条件3-1 および 3-2）が同一Roomに入室し、回線を圧迫しジッタを揺らがせた際のABRの挙動をWebRTC Internalsで確認しました。

ただし、条件1-X, 2-Xは送信側の統計情報で確認し、条件3-Xは同じRoomにChromeで入室を行い、Chrome側で各条件のPeerから受信したMedia Streamの統計情報で確認しています。

今回の検証では、contentHintの指定は下記のように与えています。

localStream.getTracks().forEach( track => {
   if( track.kind && track.kind == 'video') track.contentHint = hint;
});

検証結果

Chrome M90で接続した、条件1-X(MeshRoom), 条件2-X(SFURoom)では、contentHintにより、ビットレート調整時の挙動をコントロールできました。
一方、FirefoxはcontentHintによる挙動の違いは見られませんでした。
※FirefoxではcontentHintは実装されているものの、ビットレート調整時の挙動のコントロールに対応していません。

以下では、特にChrome M90/Meshの場合にフォーカスし、
条件1-1(contentHint = "motion"), 1-2(contentHint = "detail")の挙動の違いについて見ていきます。

ともにABRによって、ビットレートが調整されていますが、
条件1-1(contentHint = "motion")では、フレームレート(framesSent/s)の変動は小さく、映像解像度(frameWidthおよびframeHeight)が変動していることがわかります。

また、条件1-2(contentHint = "detail")では、映像解像度(frameWidthおよびframeHeight)に変化はなく、フレームレート(framePerSecond)が大きく変動していることがわかります。
※ 条件1-1におけるフレームレートの揺れは、検証当時端末負荷がかなり上がっていたためその影響があるかもしれません。

Chrome M90/MeshRoomでの結果
左: 条件1-1(contentHint = "motion"), 右: 条件1-2(contentHint = "detail")

Chrome M90/SFURoomでの結果
左: 条件2-1(contentHint = "motion"), 右: 条件2-2(contentHint = "detail")

Firefox M88/MeshRoomでの結果
左: 条件3-1(contentHint = "motion"), 右: 条件3-2(contentHint = "detail")

まとめ

contentHintの指定により、劣悪な通信環境下においても、解像度やフレームレートが維持されることが確認できました。

contentHint = "detail" または contentHint = "text" とすることで解像度が維持され、
contentHint = "motion" とすることでフレームレートが維持されました。

できるだけ高画質な映像をリアルタイム伝送したいというユースケースや、通常のWeb会議ではないような動きの大きな映像を配信するユースケースでは、contentHintの指定により、より良いユーザ体験を実現できるかもしれません。

※ 2021年6月現在、Firefoxでは動作しないのでご注意ください。(ChromiumベースのMicrosoft Edgeや、Safari 14.1/iOS Safari 14.0.2(iOS 14.3)では動作することを確認しました。)

contentHintの活用が想定されるユースケース例

・"text": Web会議の画面共有機能など
・"detail": リモート接客での商品紹介(衣服, 化粧品など)など
・"motion": ダンスやヨガのリモートレッスン, 動きの多い動画の共有など

是非お試しください。

▼SkyWayサービスサイトはこちら▼

この記事が気に入ったらサポートをしてみませんか？