Zenn
Open4

MediaStreamTrack Content Hints メモ

WebRTC
voluntasvoluntas

MediaStreamTrack Content Hints

DeepL Pro による雑な翻訳と、雑なサンプルコード。そして実際の libwebrtc の挙動。

要約

  • MediaStremaTrack の contentHint でストリームの内容に向いているエンコードさせるため、内容のヒントを指定することができる
  • できるだけ指定しておいた方がいい
  • libwebrtc の挙動が特殊なので気をつけた方がいい
voluntasvoluntas

概要

本仕様はMediaStreamTrackを拡張し、完全な再生のためのリソースが不足している場合に、メディアをどのように扱うべきかというユーザの好みに関するオプションのヒントを提供する。

このオプションのヒントは、RTCPeerConnection（[webrtc]で定義）やMediaRecorder（[mediastream-recording]で定義）のような、トラックのオーディオまたはビデオコンテンツを処理するMediaStreamTrackシンクが、ユーザの好みに合った処理パラメータを選択することを可能にします。

はじめに

音声と音楽の処理に使われるアルゴリズムは大きく異なります。音声信号用に開発されたエコーキャンセリングアルゴリズムは、音楽信号ではうまく機能しない場合があります。また、ノイズ抑制アルゴリズムでは、ドラムのスネアなどの「うるさい」コンテンツを除去します。雑音抑制アルゴリズムでは、ドラムのスネアなどの「雑音」を除去しますが、これは音声をより明瞭にする一方で、音楽信号にはあまり適しません。

ビデオの場合、ウェブカメラのコンテンツはノイズ除去が必要な場合が多く、ダウンスケールや高い量子化レベルでも理解できる場合が多いです。プレゼンテーションのスクリーンキャストコンテンツやテキストコンテンツの多いウェブページは、量子化レベルが高すぎたり、コンテンツがダウンスケールされていたり、ぼやけていたりすると、まったく理解できません。

メディアストリームトラックの利用者は、メディアコンテンツの自動検出ができなければ、経験に基づいた推測を行うしかありません。この推測は、chrome.desktopCaptureのようなスクリーンキャストコンテンツにはテキストコンテンツが含まれており、低い量子化レベルを使用しなければならず、ビットレート要件を満たすために広範囲にフレームをドロップしなければならないと仮定することに基づいているかもしれません。また、通常のUSBビデオデバイスはウェブカメラのビデオを提供しており、高い量子化レベルとダウンスケールが許容されているという仮定もあります。

通常、このような経験に基づく推測は適切ですが、正しくない場合には最適ではない設定になります。これは、映画などの動きの多いコンテンツをスクリーンキャストしたり、ビデオゲームをストリーミングしてテキストとして扱ったりすると、フレームドロップが多くなることで現れます。一方、高精細なコンテンツを通常のウェブカメラの映像として扱うと、ビットレート要件を満たすために可読性を超えて量子化またはダウンスケールされた場合、コンテンツがぼやけすぎてしまいます。また、HDMIビデオキャプチャカードをUSBウェブカメラと見なして、実際にはウェブページのテキストをスクリーンキャストしている場合にも、このようなミスマッチが発生します。

ダウンスケールによって失われたテキストの明瞭性。

図1 ダウンスケールは、低ビットレートのシナリオで動きを維持するために行うことができますが、この例は、詳細なコンテンツに誤って適用された場合にテキストの明瞭度が失われることを示しています。この例では、HDからVGAおよびQVGAへのダウンスケールに対応して、100%、50%、25%の立方体ダウンスケールを示しています。

場合によっては、ウェブアプリケーションがより高度な推測を行ったり、ユーザーからの入力を受けたりして、エンコードされているコンテンツの種類を消費者に知らせることができます。例えば、ビデオゲームのコンテンツを配信するウェブアプリケーションでは、個々のフレームの詳細を犠牲にしても、デスクトップキャプチャの動きを維持することができます。音楽スタジオのアプリケーションでは、音楽トラックからスネアを削除することによるノイズ抑制を防ぐことができます。

これらの設定は、エンコーダーレベルの設定を完全に置き換えるものではなく、ビデオエンコーダーやオーディオ処理のステップに関する幅広い知識や、より広範な調整を必要としないシンプルなヒントで、エンコーダーレベルの設定を補完するものです。

本仕様書の別項では、MediaStreamTrackを処理する特定のコンポーネントに期待される動作について説明しています。

MediaStreamTrack の拡張

本仕様はMediaStreamTrackを拡張し、[GETUSERMEDIA]で定義されているkind属性を使用しています。

各MediaStreamTrackには、アプリケーションセットコンテンツヒントが関連付けられており、これは初期状態では""、つまり未設定を意味します。このアプリケーションセットコンテンツヒントはMediaStreamTrackのcontentHint属性に対応しており、ウェブアプリケーションはトラック内に含まれるコンテンツのタイプを示すヒントを提供し、MediaStreamTrackの消費者がどのように扱うべきかを導くことができます。

アプリケーションが設定するコンテンツヒントの有効な値は、含まれるMediaStreamTrackの種類に依存します。contentHintをvalueに設定すると。

  1. このMediaStreamTrackのkind属性が "audio "であり、valueが""、"speech"、"speech-recognition"、"music "のいずれでもない場合、このステップを中止する。

2.本MediaStreamTrackのkind属性が "video "であり、valueが"", "motion", "detail", "text "のいずれでもない場合、この手順を中止する。

  1. このMediaStreamTrackのapplication-set content hintをvalueに設定する。

  2. 実装は、アプリケーションセットコンテンツヒントの新しい値に従って、このMediaStreamTrackのコンテンツをどのように処理するかについての決定を適応しなければならない。この適応は合理的な範囲で迅速に行われるべきであり、例えば、次のキャプチャされたビデオフレームまたはオーディオバッファの数以内に行われるべきである。

contentHintの取得について。

  1. このMediaStreamTrackのアプリケーションセットコンテンツヒントを返す。

アプリケーションセットコンテンツヒントの初期値は""で、ヒントが提供されていないことに対応しています。これは、含まれるコンテンツのタイプについての実装の最良の推測をデフォルトとしません。

オーディオコンテンツのヒント

""

ヒントが提供されていないので、実装は、含まれるオーディオデータをどのように処理するかについて、最善の情報に基づいて推測しなければならない。これは、トラックがどのように開かれたかから推測されるか、またはコンテンツの分析によって推測されます。

"speech"

このトラックは、音声データが含まれているかのように扱われます。トラックは、音声データが含まれているかのように扱われるべきです。この信号を消費することで、ノイズ抑制を適用したり、入力信号の明瞭度を高めたりすることが適切かもしれません。

"speech-recognition"

このトラックは、機械による音声認識を目的としたデータが含まれているものとして扱われます。この信号を消費する際には、トランスクリプションのために入力信号の明瞭度を高め、人間が消費するために使用される音声処理コンポーネントをオフにすることが適切な場合があります。

"music"

ビデオコンテンツのヒント

""

ヒントが提供されていないので、実装は、含まれるビデオコンテンツがどのように扱われるべきかについて、最善の情報に基づいて推測しなければならない。これは例えば、トラックがどのように開かれたかから推測したり、コンテンツの分析を行うことができる。

"motion"

トラックは、動きが重要なビデオが含まれているかのように扱う必要があります。これは通常、ウェブカメラの映像、映画、ビデオゲームなどです。量子化アーチファクトやダウンスケールは、目標ビットレートを維持しながらできる限り動きを維持するために許容されます。ビットレートが低いときには、エッジの品質やディテールよりもフレームレートを維持することに多くの努力が払われ、妥協を余儀なくされます。

"detail"

トラックは、ビデオのディテールが特に重要であるかのように扱われるべきです。これは一般的に、テキストコンテンツ、絵画、ラインアートを含むプレゼンテーションやウェブページに適用されます。この設定では通常、スムーズな再生ではなく、結果として生じる個々のフレームの詳細を最適化します。量子化やダウンスケールによるアーチファクトで、小さなテキストやラインアートが理解できなくなることは避けなければなりません。

"text"

トラックは、ビデオのディテールが特に重要であり、重要なシャープエッジや一貫したカラーのエリアが頻繁に発生する可能性があるように扱われるべきです。これは一般的に、プレゼンテーションやテキストコンテンツを含むウェブページに適用されます。この設定では、通常、スムーズな再生ではなく、結果として生じる個々のフレームの詳細を最適化し、テキストレンダリングを最適化するエンコーダツールを利用することができます。量子化やダウンスケールによるアーチファクトで、小さなテキストやラインアートが理解できなくなることは避けなければなりません。

voluntasvoluntas

サンプルコード

> const stream = await navigator.mediaDevices.getUserMedia({"audio": true, "video": true});
undefined
> const audioTrack = stream.getAudioTracks()[0];
undefined
> audioTrack.contentHint;
""
> audioTrack.contentHint = "speech";
"speech"
> stream.getAudioTracks()[0].contentHint;
"speech"

> const videoTrack = stream.getVideoTracks()[0];
undefined
> videoTrack.contentHint;
""
> videoTrack.contentHint = "motion";
"motion"
> stream.getVideoTracks()[0].contentHint;
"motion"
voluntasvoluntas

WebRTC Stats rtp-inboud/rtp-outbound

比較的新しい仕様

libwebrtc の挙動

Video Content Hint について

  • Firefox は対応していない
  • https://webrtc.googlesource.com/src/+/refs/heads/main/docs/native-code/rtp-hdrext/video-content-type は指定しなくても有効になる
  • getUserMedia で Video Content Hint を指定しなければ contentType は含まれない
  • getDisplayMedia で Video Content Hint を指定しなければ contentType: "screenshare" が含まれる
  • Video Content Hint に "motion" を指定すると非スクリーンキャストモードになり contentType が含まれなくなる
    • getUserMedia でも getDisplayMedia のどちらでも含まれない
  • Video Content Hint に "detail" と "text" はスクリーンキャストモードになり含まれるようになる
    • getUserMedia でも getDisplayMedia のどちらでも含まれる
  • "detail" と "text" の挙動は同じ
  • "motion" はフレームレート優先
  • "detail" と "text" は解像度優先

参考ソース