Shaka 4K / HDR playback failing to start

Vega Open Beta Bug Reports
1

1. Summary

HDR10 (PQ / 10-bit) HEVC Main10 video played through Media Source Extensions (Shaka Player) decodes and buffers normally but never presents a frame on Vega. SourceBuffer.appendBuffer() succeeds, the buffered range grows to 20+ seconds, and both MediaSource.isTypeSupported() and MediaCapabilities.decodingInfo() report the codec as supported — yet HTMLVideoElement.readyState never advances past 1 (HAVE_METADATA), currentTime stays frozen, playing/canplay never fire, and no error event is ever raised. The identical pipeline plays SDR HEVC and SDR AVC content (including Widevine HW_SECURE_ALL) without issue — only HDR10/PQ content hangs.

Confirmed to reproduce unchanged on the latest Vega SDK 0.23.8358 (@amazon-devices/react-native-w3cmedia 2.2.21), upgraded from 0.22.6150 / w3cmedia 2.2.20.

Impact: every HDR10-only channel/asset is unplayable and shows an indefinite loading spinner with no error.

Two secondary SDK gaps prevent the app from detecting or avoiding this (details in §4.a): window.matchMedia and window.screen are unavailable on Vega, and MediaCapabilities.decodingInfo() over-reports HDR support.

App Name: Fubo (app version 1.31.0, on a dev branch using Vega SDK 0.23.8358)
App Link on Amazon Appstore: Fubo TV

Bug Severity:

  • Impacts operation of app
  • Blocks current development
  • Improvement suggestion
  • Issue with documentation
  • Other

2. Steps to Reproduce

Device: Fire TV Stick 4K Select — model AFTCA002, Vega OS (UA Kepler/1.1 (Linux; AFTCA002)).
Vega SDK: 0.23.8358. Media component: @amazon-devices/react-native-w3cmedia 2.2.21.
Player: in-app player built on Media Source Extensions via the Shaka Player fork (v4.8.5) (MediaSource + SourceBuffer.appendBuffer).

  1. Load a live DASH (fMP4) stream whose video renditions are all HEVC Main10, HDR10 (transfer = PQ / SMPTE ST 2084, color = Rec.2020). Observed rendition set for the failing channel:

    id resolution bitrate codec HDR
    0 1280×720 4.3 Mbps hvc1.2.4.L123.B0 PQ
    1 3840×2160 10.5 Mbps hvc1.2.4.L153.B0 PQ
    2 3840×2160 18.7 Mbps hvc1.2.4.L153.B0 PQ
    • (Content is Widevine HW_SECURE_ALL, but DRM is not implicated)

  2. The MSE SourceBuffer is created with the matching codec (video/mp4; codecs="hvc1.2.4.L153.B0") and appendBuffer() is called with the media segments.

  3. Start playback (the element is unpaused and play() resolves).

Method calls involved: MediaSource.addSourceBuffer(), SourceBuffer.appendBuffer(), HTMLVideoElement.play() / .readyState / .currentTime, navigator.mediaCapabilities.decodingInfo()

Reproduced on:

  • AFTCA002 → USB HDMI capture card (1080p SDR sink)
  • AFTCA002 → HDR10-capable TV (Vizio M55Q7-H1), direct HDMI
  • A second, independent AFTCA002 unit → TV, direct HDMI (separate reporter)
  • Across Vega SDK 0.22.6150 and 0.23.8358 — identical behavior.

3. Observed Behavior

For HDR10/PQ HEVC content:

  • MediaSource.isTypeSupported('video/mp4; codecs="hvc1.2.4.L153.B0"') → true.
  • SourceBuffer.appendBuffer() succeeds for every segment; getBufferedInfo() shows the buffered range growing to 20+ seconds.
  • HTMLVideoElement.readyState stays at 1 (HAVE_METADATA) for the entire session and never reaches 2+.
  • currentTime never advances (frozen at the initial live-edge value).
  • canplay, playing, waitingforkey, and error events never fire. getVideoPlaybackQuality().totalVideoFrames stays 0. Shaka emits stalldetected.
  • Net result: indefinite stall, no error surfaced to the app.

For SDR content on the same device / SDK / pipeline / app build (HEVC Main, and AVC, including Widevine HW_SECURE_ALL): plays normally — frames present, readyState reaches 4, playing fires.

So the failure is isolated to the HDR10/PQ (10-bit) path, at the decode→present boundary (data is decoded/buffered but no frame is ever presented).

Capability-API observations on Vega (AFTCA002, SDK 0.23.8358):

  • navigator.mediaCapabilities.decodingInfo() for the HDR config {contentType:'video/mp4; codecs="hvc1.2.4.L153.B0"', transferFunction:'pq', colorGamut:'rec2020', 3840×2160} → { supported: true, smooth: false, powerEfficient: true }. smooth is also false for an SDR baseline config that does play, so smooth does not appear meaningful on this platform.

The SDK upgrade from 0.22.6150 → 0.23.8358 (w3cmedia 2.2.20 → 2.2.21) produced no change in any of the above.

4. Expected Behavior

One of the following:

  1. Preferred: HDR10 (PQ) HEVC Main10 content that the platform reports as decodable should actually decode and present — readyState should advance and playing should fire — when the device/output supports HDR.
  2. If the current output/display cannot present HDR, the SDK should surface an error on the HTMLVideoElement (or via Shaka) instead of silently stalling at readyState === 1 indefinitely.
  3. The capability APIs should give the app a reliable way to know this in advance:
    • MediaCapabilities.decodingInfo() should return supported: false (or otherwise not report supported: true) for an HDR config the device cannot actually present, and
    • a working mechanism to query HDR/output capability should exist (e.g. window.matchMedia('(dynamic-range: high)') / window.screen.colorDepth, or a documented Vega equivalent), since these standard web APIs are currently unavailable.

4.a Possible Root Cause & Temporary Workaround

Suspected area: HDR10/PQ (10-bit) HEVC presentation in the Vega W3C media layer (react-native-w3cmedia). Decode input clearly works (segments append, buffer fills), but frames are never presented and no error is raised. We could not determine from the app layer whether the HDMI/HDR output mode is negotiated.

Ruled out (no change in behavior):

  • DRM — SDR Widevine HW_SECURE_ALL content plays on the same device; the hang is HDR-specific.
  • MSE SourceBuffer codec/level mismatch — forcing the SourceBuffer to be created with the exact 4K codec string (hvc1.2.4.L153.B0) made no difference.
  • Bandwidth / buffering / network — all segments return HTTP 200 and append successfully; buffer reaches 20+s.
  • Decoder capability reporting — isTypeSupported and decodingInfo both report the codec/HDR config as supported.
  • SDK version — reproduced identically after upgrading to the latest 0.23.8358 (w3cmedia 2.2.21).

Workarounds tried (all unsuccessful):

  • Capping ABR to the HD rendition — no effect; every rendition is HDR10/PQ.

Current workaround: None. There is no app-side path to play this content, and no reliable way to pre-detect the failure (capability APIs report support and don’t expose HDR/display state).

Questions for the SDK team:

  1. Why does HDR10 (PQ, 10-bit) HEVC Main10 decode + buffer but never present (readyState pinned at 1) on AFTCA002 / SDK 0.23.8358, while SDR HEVC/AVC present normally — and why is no error raised?
  2. What is the supported way to detect HDR/display output capability on Vega, given window.matchMedia and window.screen are unavailable?
  3. Why does MediaCapabilities.decodingInfo() report supported: true for an HDR config that never presents, and smooth: false for all configs (including working SDR)?

5. Logs

Device: Fire TV Stick 4K Select (AFTCA002), Vega SDK 0.23.8358, react-native-w3cmedia 2.2.21
Player: Shaka Player (MSE). [HDR-DBG] = our instrumentation. (We seed a high ABR
bandwidth estimate so it deterministically selects the 4K HDR rendition; the hang
is identical under normal ABR.)

— at load: what we’re playing + what the platform claims it can decode —

[HDR-DBG] playing: 3840x2160 hvc1.2.4.L153.B0 hdr=PQ bw=18702800 drm=com.widevine.alpha/HW_SECURE_ALL
[HDR-DBG] offered renditions: 1280x720 hvc1.2.4.L123.B0 hdr=PQ bw=4347200 | 3840x2160 hvc1.2.4.L153.B0 hdr=PQ bw=10477600 | 3840x2160 hvc1.2.4.L153.B0 hdr=PQ bw=18702800
(every rendition is HEVC Main10 PQ/HDR10 — no SDR fallback exists)
[HDR-DBG] decodingInfo 4K HDR pq/rec2020: supported=true smooth=false powerEfficient=true
[HDR-DBG] decodingInfo 4K SDR baseline: supported=true smooth=false powerEfficient=true

— shaka load pipeline completes, playback is started —

[HDR-DBG] shaka onstatechange → drm-engine (readyState=0)
[HDR-DBG] shaka onstatechange → load (readyState=0)
[HDR-DBG] shaka buffering=false willTriggerPlay=true buffered=4.2s readyState=1
[HDR-DBG] buffering ended → calling videoElem.play()
[HDR-DBG] videoElem.play() resolved (awaiting native “playing” event)
[HDR-DBG] shaka stalldetected at currentTime=1782405493.711 (buffered=4.2s, readyState=1)

— the stall: buffer grows steadily, but currentTime is frozen, readyState

never passes 1 (HAVE_METADATA), and 0 frames are ever decoded/presented —

[HDR-DBG] t=2s readyState=1 currentTime=1782405493.711 buffered=0.2s videoSegmentsAppended=1 totalVideoFrames=0
[HDR-DBG] t=4s readyState=1 currentTime=1782405493.711 buffered=4.2s videoSegmentsAppended=2 totalVideoFrames=0
[HDR-DBG] t=8s readyState=1 currentTime=1782405493.711 buffered=12.2s videoSegmentsAppended=4 totalVideoFrames=0
[HDR-DBG] t=14s readyState=1 currentTime=1782405493.711 buffered=20.2s videoSegmentsAppended=6 totalVideoFrames=0
[HDR-DBG] t=17s readyState=1 currentTime=1782405493.711 buffered=20.2s videoSegmentsAppended=6 totalVideoFrames=0

currentTime never advances from 1782405493.711; readyState never exceeds 1;

totalVideoFrames stays 0; no “playing”, “error”, or “waitingforkey” event ever fires.

6. Environment

SDK Version: (vega --version)

Active SDK Version: 0.23.8358
Vega CLI Version: 1.3.2

App State: Foreground

OS Information:

##################################################
#####     Welcome to Developer mode Shell    #####
##################################################
sh(com.amazon.dev.shell):/$ cat /etc/os-release
NAME="OS"
OE_VERSION="4.0.0"
OS_MAJOR_VERSION="1"
OS_MINOR_VERSION="1"
RELEASE_ID="21"
OS_VERSION="1.1"
BRANCH_CODE="TV Ship"
BUILD_DESC="OS 1.1 (TV Ship/27)"
BUILD_FINGERPRINT="4.0.344088.0(3072cab629675a74)/27N:user/release-keys"
BUILD_VARIANT="user"
BUILD_TAGS="release-keys"
BUILD_DATE="Thu Jun 18 06:50:08 UTC 2026"
BUILD_TIMESTAMP="1781765408"
VERSION_NUMBER="2101010002720"```

7. Example Code Snippet / Screenshots / Screengrabs

We play via Shaka Player (MSE). Minimal representative setup:

import shaka from '@fubotv/shaka-player-kepler'

const player = new shaka.Player(videoElement)

// DASH manifest whose ONLY video renditions are HEVC Main10, HDR10 (PQ / Rec.2020):
//   hvc1.2.4.L153.B0 (4K) and hvc1.2.4.L123.B0 (720p)
await player.load(manifestUri)
await videoElement.play()

// Observed: SourceBuffer.appendBuffer() succeeds, buffered range grows to 20+s,
// but videoElement.readyState never advances past 1 (HAVE_METADATA),
// currentTime stays frozen, no frame is presented, and no 'error' fires.

This reproduces at the MSE layer independent of Shaka — appending HEVC Main10 PQ segments to a SourceBuffer created with video/mp4; codecs="hvc1.2.4.L153.B0" fills the buffer but never presents a frame, while the same pipeline presents SDR HEVC/AVC normally.

:backhand_index_pointing_right: Playback Issues

  • Player SDK: Shaka Player
  • Player SDK Version: based on Shaka Player 4.8.5
  • Audio Codecs: AAC (mp4a.40.2)
  • Video Codecs: HEVC / H.265 Main10, HDR10 (PQ) — hvc1.2.4.L153.B0 (4K, Level 5.1) and hvc1.2.4.L123.B0 (720p, Level 4.1). (Note: not H.264 — the failing content is HEVC.)
  • Manifest Types: DASH (.mpd)
  • Architecture: ARM — physical device (Fire TV Stick 4K Select / MediaTek MT8698, aarch64). Not the x86 simulator (it can’t reproduce: no HW HEVC/HDR decode and no DRM).

Q: Content / media URL for testing
With the Fubo app, play Fox 4K or FS1 4K channels

4

Hi @fubo-thughes,

Thank you for the detailed bug report on the HDR10/PQ HEVC playback issue. The thorough reproduction steps, logs, and capability API observations are very helpful.

Our team is investigating this issue and will provide an update as soon as we have more information.

Could you also share the complete device logs (via vega logs) captured during a reproduction attempt? The full system-level logs will help us trace the issue through the media pipeline beyond what’s visible at the app layer.

Thanks for helping us improve the Vega platform.

Warm regards,
Aishwarya