How decodeQueueSize and encodeQueueSize behave will introduce web compatibility issues, and need to be better defined.
メンテナーはふだん 1 日以内に返信
@padenot がすでに取り組んでいます。
2025年5月13日 から。
評価
この issue はまだ評価されていません。
説明
Whenever decode() or encode() is called, we are to increase respectively decodeQueueSize or encodeQueueSize and enqueue a control message while immediately processing the control message.
If the codec is saturated, then we are to abort.
However "Codec Saturation" is defined as:
**_Codec Saturation
The state of an underlying codec implementation where the number of active decoding or encoding requests has reached an implementation specific maximum such that it is temporarily unable to accept more work. The maximum may be any value greater than 1, including infinity (no maximum). While saturated, additional calls to decode() or encode() will be buffered in the control message queue, and will increment the respective decodeQueuSize and encodeQueueSize attributes. The codec implementation will become unsaturated after making sufficient progress on the current workload._**
If a UA choose for a maximum a value of infinity; a side effect is that decodeQueueSize and encodeQueueSize will only ever be observed with a value of 0.
WebCodecs' demo player https://w3c.github.io/webcodecs/samples/audio-video-player/audio_video_player.html uses the value of decodeQueueSize as a rate limiter on how quickly it needs to decode ahead of time to fill its ring buffer for audio.
If the UA chose to have an unlimited queue and decodeQueueSize be always 0, then such rate limitation will be ineffective.
In the demo above, this causes the ring buffer to become full almost instantly and decoded audio frames are all dropped, and playback never progress.
While it's obviously an issue in this reference player itself, it will be used by others as an example (I already know of a few parties that based their work on it)
Chrome uses a maximum queue size of between 1 and 8 for video (Default: https://source.chromium.org/chromium/chromium/src/+/main:media/base/video_decoder.cc;drc=0e516eb08aa56163bfe649cebbba13da1fcf5f3c;bpv=1;bpt=1;l=30 max: https://source.chromium.org/chromium/chromium/src/+/main:media/gpu/chromeos/oop_video_decoder.h;drc=0e516eb08aa56163bfe649cebbba13da1fcf5f3c;bpv=1;bpt=1;l=207) and just 1 for audio (https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/webcodecs/audio_decoder.cc;drc=0e516eb08aa56163bfe649cebbba13da1fcf5f3c;bpv=1;bpt=1;l=132)
Firefox uses a maximum queue size of 1 (https://searchfox.org/mozilla-central/source/dom/media/webcodecs/DecoderTemplate.cpp#564-567) and won't enqueue a new decode/encode if one is pending.
And so the demo video player works fine on Firefox and Chrome; but it wouldn't had they not constricted the limit to such a low value.
It may be beneficial to provide guidelines of best practices and amend the demo player to cater for such condition.
- 主要言語
- HTML
- スター
- 1.3k
- フォーク
- 192
- 平均マージ
- 21時間 7分
- マージ済み PR（30日）
- 8
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
w3c/webcodecs のほかの issue
-
privacy-needs-resolution
難易度 1/5 1時間未満 初心者へのやさしさ 65/100
メンテナーはふだん 1 日以内に返信
-
editorial
難易度 1/5 1時間未満 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 55/100
w3c/webcodecs#973 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
w3c/webcodecs#972 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
w3c/webcodecs#971 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信