URL-mode playback never populates audioTrackList / textTracks

Vega Open Beta Q&A
1

Hi Vega team,

We’re building an IPTV client (React Native 0.72, SDK 0.23.9221, @amazon-devices/react-native-w3cmedia in URL/src mode, tested on the arm64 VVD).

In URL mode, video.audioTracks and video.textTracks never populate, so apps cannot offer audio or subtitle selection. This is reproduced with MKV (H.264 + AAC + SubRip) and plain MP4 (H.264 + AAC).

Evidence from an MP4 playback session:

Native side works: the demuxer pads link, onTrackUpdated: addtrack id = 0 fires for both tracks, and MediaPlayerPipelineImpl::onTrackUpdate is invoked. Audio track can be heard when playing the file.

On the JS side, the media element emits only loadstart, play, waiting, timeupdate. It doesn’t emit addtrack and loadedmetadata, and reading the lists directly during playback shows that audioTracks.length is 0 and textTracks.length is 0.
So the track information is lost inside the w3cmedia native→JS bridge. Additionally, embedded MKV subtitle tracks are dropped earlier in the pipeline (with message “Text pad type found. Cannot handle it. Not linking it.”).

Is track enumeration/selection expected to work in URL mode?
Is loadedmetadata expected to fire in URL mode? (It doesn’t for us.)
What’s the recommended way to offer subtitles/audio track selection with URL-mode playback?

Thanks!

3

Hi @andrey.e,

Welcome to the community!

To answer your questions directly:
1. Is track enumeration/selection expected to work in URL mode?
No - this is a known limitation. URL mode is designed for simple non-adaptive playback (MP4, MP3). The native GStreamer pipeline handles demuxing and playback directly, but track metadata is not bridged to the JS-side audioTracks/textTracks properties. While the native side correctly detects and plays audio tracks (as you observed with onTrackUpdated: addtrack), this information is not surfaced to the W3C Media JS API in URL mode.

2. Is loadedmetadata expected to fire in URL mode?
The event lifecycle in URL mode is limited - you’ll get loadstart, play, waiting, and timeupdate, but not the full set of W3C events (loadedmetadata, addtrack, canplay). I’m checking internally whether this is by design or a gap that can be addressed.

3. What’s the recommended way to offer subtitles/audio track selection?
For an IPTV client that needs audio track selection and subtitle support, you should use MSE mode
Here’s why:

  • MSE mode gives you full access to audioTracks, textTracks, loadedmetadata, and addtrack events

For your use case (IPTV with MKV/MP4 containing multiple audio/subtitle tracks):
Option A - MSE mode with Shaka Player (recommended):

  • Wrap your stream URLs in a simple HLS manifest, or use Shaka in MSE mode to feed segments
  • Full track selection via JS APIs
  • You can also integrate with Vega Media Controls for system-level audio/subtitle track selection (AudioTracks and TextTracks features)

Option B - Out-of-band subtitles in URL mode (partial workaround):

Regarding embedded MKV subtitle tracks (“Text pad type found. Cannot handle it.”):
This confirms that the native GStreamer pipeline in URL mode does not link text pads. Embedded text/subtitle tracks in MKV containers are not supported in URL mode.

For an IPTV client, MSE mode is the right architecture. For the full picture on choosing between URL and MSE mode, see Selecting the Playback Mode.

Let us know if you need help with the Shaka Player integration.

Warm Regards,
Ivy