MediaSource.isTypeSupported() returns true for video/mp2t containing AC‑3, but the TS demuxer cannot demux AC‑3

Vega Open Beta Bug Reports
1

1. Summary

MediaSource.isTypeSupported('video/mp2t; codecs="avc1.4D401F,ac3"') returns true even though MediaSource.isTypeSupported('audio/mp2t; codecs="ac-3"') and MediaSource.isTypeSupported('video/mp2t; codecs="ac-3"') both correctly return false. The combined check appears to validate each codec id against the global support list rather than against the container × codec compatibility matrix.

When a SourceBuffer is then created with the combined MIME type and fed a muxed TS containing H.264 video and AC‑3 audio, Vega’s TS demuxer extracts and decodes the H.264 video correctly but silently drops the AC‑3 audio PID with no error event and no log.

  • App Name: Tablo

  • Bug Severity: Impacts operation of app (silent audio loss is the worst-possible failure mode for QA and end users — there is no observable signal that anything is wrong)

2. Steps to Reproduce

  1. Probe support:

    MediaSource.isTypeSupported('audio/mp2t; codecs="ac-3"');             // false  (correct)

MediaSource.isTypeSupported('audio/mp4;  codecs="ac3"');              // true   (correct)

MediaSource.isTypeSupported('video/mp2t; codecs="avc1.4D401F"');      // true   (correct)

MediaSource.isTypeSupported('video/mp2t; codecs="avc1.4D401F,ac3"');  // true   incorrect

  2. Create an HLS master playlist with CODECS="avc1.4D401F,ac3" whose media playlist serves muxed MPEG‑TS segments containing one H.264 video PID + one AC‑3 audio PID.

  3. Load with Shaka Player (no forceTransmux). Shaka reads isTypeSupported, sees true, and feeds the TS natively to a single addSourceBuffer('video/mp2t; codecs="avc1.4D401F,ac3"') SourceBuffer.

3. Observed Behavior

Video plays. AC‑3 audio is silently dropped. No error event on the SourceBuffer, no error event on the <video> element, no error in Shaka, no audio output, no warning in the console.

addSourceBuffer: video/mp2t; codecs="avc1.4D401F,ac3"
appendBuffer(261320)                                       // muxed TS init+seg
SourceBuffer[0]:handleEvent: 2,5
…
[handleStateChangedEvent] newstate: playing

audiofocusgranted is never fired. Only one source buffer is ever created.

4. Expected Behavior

MediaSource.isTypeSupported('video/mp2t; codecs="avc1.4D401F,ac3"') should return false whenever AC‑3 inside MPEG‑TS is not supported (which Vega already reports correctly when each codec is queried alone). Per the MSE spec, isTypeSupported is a strict precondition - if the platform cannot actually decode every codec in the listed combination inside the requested container, it must return false.

If the platform really can demux AC‑3 from MPEG‑TS in some configuration, then the audio stream should be decoded; failing that, the SourceBuffer should fire an error event when the un-demuxable bytes are appended.

4.a Possible Root Cause & Temporary Workaround

Suspected root cause: the codec list validator iterates each codec id and checks support independently, OR’ing/AND’ing the per-codec results without consulting a container × codec table. So ac3 (supported in MP4) and avc1 (supported in TS) both individually probe true, and the combined query inherits that.

Workaround: there is no clean workaround. The two paths we’re left with:

  1. Don’t trust isTypeSupported for combined codec strings on mp2t. Maintain a hand-coded compatibility matrix in the app and pre-filter codec lists before they ever reach Shaka.

  2. Force Shaka to transmux every TS variant to fMP4 via mediaSource.forceTransmux: true - but that triggers Bug 3 (filed separately) for muxed TS containing AC‑3.

Neither is acceptable; we currently have the silent-audio state.

6. Environment

  • SDK Version: 0.22.5600

  • App State: Foreground

  • OS Information:

    NAME="OS"
OE_VERSION="4.0.0"
OS_MAJOR_VERSION="1"
OS_MINOR_VERSION="1"
RELEASE_ID="14"
OS_VERSION="1.1"
BRANCH_CODE="TV Ship day60"
BUILD_DESC="OS 1.1 (TV Ship day60/99)"
BUILD_FINGERPRINT="4.0.227617.0(3072cab629675a74)/99N:user-external/release-keys"
BUILD_VARIANT="user-external"
BUILD_TAGS="release-keys"
BUILD_DATE="Tue Feb 17 22:57:51 UTC 2026"
BUILD_TIMESTAMP="1771369071"
VERSION_NUMBER="1401010009950"

  • Device: Fire TV Stick 4K Select

  • React Native: system-bundled (Vega 0.22 / RN 0.72)

  • Player SDK: Shaka Player 4.8.5 (from the docs)

7. Example Code Snippet

Master playlist:

#EXTM3U
#EXT-X-VERSION:4
#EXT-X-STREAM-INF:BANDWIDTH=10000000,CODECS="avc1.4D401F,ac3"
pls.m3u8

Where pls.m3u8 references muxed MPEG‑TS segments. Loading this with Shaka 4.x on top of @amazon-devices/react-native-w3cmedia’s MediaSource reproduces the silent-audio behavior.

Playback Issues

  • Player SDK: Shaka Player

  • Player SDK Version: 4.8.5

  • Audio Codecs: AC‑3 (also reproducible with E‑AC‑3 / eac3)

  • Video Codecs: H.264 (codec under test for this bug is audio-only)

  • Manifest Types: HLS (m3u8)

Additional Context

The failure mode is invisible to all observability. There is no error to trap, no event to forward to crash reporting, just “user reports no audio”.

4

Hi @Jon_Page,

Thank you for the detailed bug report on the MediaSource.isTypeSupported() behavior with AC-3 in MPEG-TS containers, and for sharing the workarounds you’ve explored so far.

Our team is investigating this issue and will provide an update as soon as we have more information. In the meantime, could you please share the complete device logs captured during reproduction? This will help us with a more thorough analysis.

Thanks for helping us improve the Vega platform.

Warm regards,
Aishwarya

5

I have sent device logs for this bug to our Amazon contact