Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#983 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
html
Bereich
api, web-dev

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
HTML
Sterne
1.3k
Forks
190
Ø Merge
1 T. 4 Std.
Gemergte PRs (30 T.)
12

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus w3c/webcodecs

Alle Issues in w3c/webcodecs

Ähnliche Issues

Weitere Issues zu Backend & API Design

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.