Media fallback chains must cover decode failure and unsupported formats

What it is

Newer formats are smaller; they are not guaranteed to decode on every device. A fallback chain has to cover two failures: the format is unsupported, and the format is supported but decode fails (corrupt bytes, memory, hardware decoder refusal). “Prefer AVIF, else JPEG” is a format preference. A real chain still lands on something visible after a decode throw, an error event, or a timeout. The end of the chain is that the user can still finish the task, not a broken-image icon.

Why it happens

<picture> / <source> pick the first candidate the engine claims to support, given type and media queries. That handles “unsupported.” Runtime decode is a second step: a matching type can still fail on a corrupt bitstream, a resolution over budget, or a software-decode OOM. Failure fires error; with no next candidate the slot stays empty. A complete chain is: preferred codec → secondary codec → a universally decodable baseline (JPEG / H.264 poster) → a non-media substitute (text, link, retry). Video that cannot play should fall to a poster, not a black frame.

“Claims support” and “can decode this file” are different. Hardware decoders accept a narrower subset of color space, level, and alpha; the software path is slower and likelier to be killed on low memory. The chain must switch on failure, not only pick once when capability detection is true.

Where it stops holding

A single format in a fully controlled runtime (an internal binary, one decoder) can skip a long chain, but still has to handle corruption. Decorative backgrounds may fail silently; they should not show a loud broken-image glyph. DRM and encrypted media fail on authorization; switching codec does not fix that. When the user has disabled image loading, the chain’s end is alternative text, not another image that will also be blocked.

Applying it

• List types from preferred to baseline in <picture>; give video multiple <source> elements and a poster that remains visible.
• On error or decode rejection, move to the next URL in the chain instead of stopping on a broken image; if the baseline also fails, swap in text and a way to open the original.
• Use capability detection to order candidates, not to skip error handling—true still has to survive a failed decode.
• Verify by forcing an unsupported type, truncating the file, and opening an oversized resolution on a low-memory device. The slot should show the baseline or readable substitute, never a permanent broken image. Walk each failure down the chain.

Related

• Same group: R3.07.1 Size and format must be generated per use case · R3.07.2 Undeclared dimensions cause layout jump · R3.07.3 Autoplay consumes bandwidth and attention · R3.07.4 Off-viewport media is deferred; in-viewport media is prioritized · R3.07.5 Placeholder color close to the final image reduces pop
• Adjacent: R3.16 Low-end devices and degradation · J2.05 Decorative Images
• Search terms: decode failure · picture element · codec fallback