Hardware decoder limits: when a TV says it supports a codec and then cannot play it
The most frustrating class of TV bug: the same stream plays on one model and fails on another with supposedly identical specifications. The codec API said yes; the silicon behind it said no.
What it looks like
Playback fails outright on particular models, or produces a black screen while audio continues, or crashes the app when a specific rendition is selected. It happens on some devices and not on others that should be equivalent, and it usually only affects one or two rungs of the ladder - the top ones.
Why the API answer is not enough
When an app asks whether a device can play H.264, the answer is yes on every television made in the last decade. What the answer does not say is which profile and level the hardware decoder actually handles. A chipset that decodes H.264 High Profile up to Level 4.2 will reject a 4K rendition encoded at Level 5.1, and the media capability APIs on several platforms do not distinguish between the two. The same gap exists for 10-bit colour, HDR metadata formats, high frame rates and multichannel audio: the codec is supported, that specific combination is not.
Decoder instances are a second limit. Silicon typically provides one or two hardware decoders, so a design that plays a trailer preview in the browse UI while a stream is paused behind it, or shows picture-in-picture, can exceed what the device has. And underneath all of it are firmware bugs in the media pipeline that no API will ever report.
- Profile and level caps: H.264 Level 5.1 for 4K is the classic failure.
- 10-bit colour, HDR10, HLG or Dolby Vision metadata the decoder does not handle.
- High frame rate renditions on chipsets limited to 30 fps at 4K.
- More simultaneous decode sessions than the hardware provides.
- Firmware defects specific to a model year or a chipset family.
Build a capability database, then test
The reliable approach is to stop trusting the device to describe itself and keep your own record instead: a capability database keyed by platform, model and firmware, populated from real device testing and from playback failures reported by analytics, that says what each model can decode. The player uses it to filter the manifest before playback, so a device known to fail on Level 5.1 never sees that rung.
The Media Capabilities API, where available, is a useful first filter and reports whether decoding is expected to be smooth and power-efficient, but it should be treated as input to the database rather than a replacement for it. A short decoder warm-up at app start - decoding a tiny sample at the target profile - catches some failures before the viewer presses play. And the manifest served to a constrained device should simply omit what it cannot play, which is cheaper and more reliable than any amount of runtime fallback logic.