Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Specify how decode() handles an EncodedVideoChunk/EncodedAudioChunk with empty data

Aberta
  • Algo errado?
#983 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Funcionalidade
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
html
Domínio
api, web-dev

Direção de pesquisa

Read the VideoDecoder and AudioDecoder “decode the chunk” control message algorithms and compare them with the WPT case in webcodecs/videoDecoder-codec-specific.https.any.js, “Decode empty frame.” The issue proposes queuing the appropriate close algorithm with an EncodingError when chunk data is empty; done when both decoder algorithms specify that behavior and the test expectations align.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

The spec does not say what happens when decode() is given a chunk whose [[internal data]]
has zero length.

  • The EncodedVideoChunk/EncodedAudioChunk constructors accept a zero-length data and just
    record [[byte length]].
  • decode() only checks [[state]] and [[key chunk required]].
  • The codec registrations say chunk data "is expected to be" a frame of the codec (e.g. VP8:
    "a frame as described in Section 4 and Annex A of [[VP8]]"), but that is descriptive. Whether
    an empty chunk "results in an error" in the decode control message is left to the codec
    implementation.

Implementations differ in where this is decided:

  • Chromium rejects it generically, for every audio and video codec, before it reaches the
    codec: DecoderTemplate::ProcessDecodeRequest() closes the decoder with
    EncodingError ("Null or empty decoder buffer."). decode() itself does not throw.
  • In WebKit it has depended on the codec backend. Some libraries treat an empty input as a
    request to flush (libvpx does so for a null/zero-size buffer to vpx_codec_decode()), so
    without an explicit check an empty chunk can silently produce no output and no error.

WPT already expects the Chromium behaviour: webcodecs/videoDecoder-codec-specific.https.any.js,
"Decode empty frame", decodes a key chunk followed by a zero-length key chunk and expects the
error callback with EncodingError, flush() to reject, and state "closed".

Proposal: in the "decode the chunk" control message of VideoDecoder and AudioDecoder, before
handing the chunk to [[codec implementation]], add:

If chunk's [[internal data]] is empty, queue a task to run the Close VideoDecoder
(resp. Close AudioDecoder) algorithm with an EncodingError DOMException and return
"processed".

This keeps decode() from throwing (matching current behaviour and WPT), makes the result
independent of the codec and backend, and keeps an empty chunk from ever being interpreted as a
codec-level flush.

Alternatives:

  1. Throw synchronously from decode() (TypeError or DataError) when the chunk is empty. Simpler
    for authors, but changes the behaviour Chromium ships and WPT tests for.
  2. Reject zero-length data in the EncodedVideoChunk/EncodedAudioChunk constructors. Would
    affect encoders and other uses of chunks, and is a larger compatibility risk.

Related: a decode that produces no output, such as a VP8 frame with show_frame = 0 (an
alternate reference frame), is not an error, and the spec already handles it: "If decoded
outputs is not empty". This issue is only about chunks that carry no data.

Linguagem predominante
HTML
Estrelas
1.3k
Forks
190
Merge médio
1d 4h
PRs com merge (30d)
12

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de w3c/webcodecs

Todas as issues de w3c/webcodecs

Issues semelhantes

Mais issues de Backend & API Design

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.