Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

VideoEncoder: an orientation change after a bitrate-only configure() produces a delta chunk with a new VideoDecoderConfig

オープン
  • 何か問題がありますか？
#978 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
html
領域
api

調査の方向性

Start with the VideoEncoder orientation and configure() behavior described in the issue, then review the linked CodePen reproduction. Decide how orientation changes should interact with bitrate-only reconfiguration, decoder configuration changes, and key-frame requirements; the issue offers forcing a key frame or rejecting the change as options. Done means the behavior and any spec note address the stated decoder failure and preserve the bitrate-only optimization.

索引モデルが issue の本文から書いたものです。

説明

The flow is the following:

  1. The encoder is configured once.
  2. The encoder encodes a frame. This generates a first encoded chunk (key frame) and a first VideoDecoderConfig.
  3. The encoder is reconfigured only to change the bitrate. In Chrome and Safari at least, this does not recreate the underlying encoder, so no key frame is generated by default.
  4. The encoder encodes a new frame with a different orientation. This generates a second encoded chunk (delta frame) and a second VideoDecoderConfig.

On the decoder side:

  1. The decoder is configured with the first VideoDecoderConfig.
  2. The decoder decodes the first encoded chunk.
  3. The decoder is configured with the second VideoDecoderConfig.
  4. The decoder fails to decode the second encoded chunk because it is not a key frame (A key frame is required after configure() or flush()).

Repro: https://codepen.io/editor/youennf/pen/01a167cd-55d7-75b2-baa6-f4aa8523920a
This reproduces in Chrome. It does not reproduce in Safari yet, because orientation support is still being implemented there.

This is a problem as:

  • Not triggering a key frame when only the bitrate changes is useful for realtime conferencing so should be preserved in some way.
  • There is also an assumption that a chunk carrying a new VideoDecoderConfig must be decodable by a decoder freshly configured with it, so it must be a key frame. This flow breaks that assumption.

A first option is to force a key frame on orientation change
This is probably the simplest approach.
Whenever the orientation of the encoded frames changes, the encoder produces a key frame together with a new VideoDecoderConfig. A bitrate-only configure() by itself still never forces a key frame.

If doing so, we could also remove the synchronous active orientation check in VideoEncoder.encode().
This might be handy for video conferencing web applications having to deal with orientation changes.

An alternative is to disallow an orientation change after a bitrate-only configure(). For example, the next encode() with a different orientation throws a DataError, so the application has to do a full reconfiguration, which produces a key frame.
This requires defining bitrate-only configure though so my preference goes to the first option.

I would alsol tend to add to the spec a note about supporting bitrate-only configure.
Otherwise, we might end up into interop issues if one browser implements this optimization and another does not.

主要言語
HTML
スター
1.3k
フォーク
190
平均マージ
1日 4時間
マージ済み PR（30日）
12

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

w3c/webcodecs のほかの issue

w3c/webcodecs の issue をすべて見る

似ている issue

Backend & API Design の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。