VideoEncoder: an orientation change after a bitrate-only configure() produces a delta chunk with a new VideoDecoderConfig
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- html
- Ambito
- api
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
The flow is the following:
- The encoder is configured once.
- The encoder encodes a frame. This generates a first encoded chunk (key frame) and a first VideoDecoderConfig.
- 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.
- 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:
- The decoder is configured with the first VideoDecoderConfig.
- The decoder decodes the first encoded chunk.
- The decoder is configured with the second VideoDecoderConfig.
- 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.
- Lingua principale
- HTML
- Stelle
- 1.3k
- Fork
- 190
- Merge medio
- 1g 4h
- PR unite (30g)
- 12
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di w3c/webcodecs
-
privacy-needs-resolution
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 65/100
I maintainer di solito rispondono entro 1 giorno
-
editorial
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
w3c/webcodecs#983 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
w3c/webcodecs#977 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
w3c/webcodecs#973 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di w3c/webcodecs
Issue simili
-
.NET ep:WebGPU platform:web
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
microsoft/onnxruntime#33755 ·
I maintainer di solito rispondono entro 2 giorni
-
changelog investigate
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
ramnes/notion-sdk-py#433 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
intake/intake-esm#789 ·
-
area: core priority: low type: bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
RicoSuter/Namotion.Interceptor#863 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
MemMachine/MemMachine#1877 ·
I maintainer di solito rispondono entro 3 giorni