VideoEncoder: an orientation change after a bitrate-only configure() produces a delta chunk with a new VideoDecoderConfig
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- html
- Área
- api
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- HTML
- Estrellas
- 1.3k
- Forks
- 190
- Merge medio
- 1 d 4 h
- PR fusionados (30 d)
- 12
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de w3c/webcodecs
-
privacy-needs-resolution
Dificultad 1/5 Menos de una hora Aptitud para principiantes 65/100
Los mantenedores suelen responder en 1 día
-
editorial
Dificultad 1/5 Menos de una hora Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
w3c/webcodecs#983 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
w3c/webcodecs#977 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 55/100
w3c/webcodecs#973 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de w3c/webcodecs
Issues similares
-
.NET ep:WebGPU platform:web
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
microsoft/onnxruntime#33755 ·
Los mantenedores suelen responder en 2 días
-
changelog investigate
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
ramnes/notion-sdk-py#433 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
intake/intake-esm#789 ·
-
area: core priority: low type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
RicoSuter/Namotion.Interceptor#863 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
MemMachine/MemMachine#1877 ·
Los mantenedores suelen responder en 3 días