Repository navigation
HLS: SDR variant selected over PQ variant with the same BANDWIDTH #3441
Description
Version
Media3 main branch
More version details
Devices that reproduce the issue
Not device-specific. Reproduces in a Robolectric test.
Reproducible in the demo app?
Not tested
Reproduction steps
Multivariant playlist with a PQ variant followed by SDR variants at the same BANDWIDTH (Jellyfin serves this when it can remux an HDR source):
#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=60000000,AVERAGE-BANDWIDTH=60000000,VIDEO-RANGE=PQ,CODECS="hvc1.2.4.L153.B0,mp4a.40.2",RESOLUTION=3840x2160,FRAME-RATE=23.976
hdr_hevc.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=60000000,AVERAGE-BANDWIDTH=60000000,VIDEO-RANGE=SDR,CODECS="hvc1.1.4.L153.B0,mp4a.40.2",RESOLUTION=3840x2160,FRAME-RATE=23.976
sdr_hevc.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=60000000,AVERAGE-BANDWIDTH=60000000,VIDEO-RANGE=SDR,CODECS="avc1.640033,mp4a.40.2",RESOLUTION=3840x2160,FRAME-RATE=23.976
sdr_h264.m3u8
- Configure an HEVC decoder supporting Main, Main10 and Main10HDR10.
- Build the player with
DefaultBandwidthMeterand an initial estimate of 4,300,000 (the highest default Wi-Fi estimate). - Prepare the playlist and check the track format of the first media chunk load.
Expected result
The PQ variant is selected.
Actual result
The HEVC SDR variant is selected. With an initial estimate of 1,000,000,000 the PQ variant is selected.
Media
Playlist above. The segments can be any fMP4 segments.
Cause
HlsPlaylistParseronly setscolorInfofor Dolby Vision variants (L541-L546), soVIDEO-RANGE=PQis dropped and the HDR preference inDefaultTrackSelector(L4036) never applies.VideoTrackInfo.isCompatibleForAdaptationWith(L3950) does not compare HDR and SDR, so both HEVC variants share one adaptive selection. When neither fits the allocated bandwidth,AdaptiveTrackSelection.determineIdealSelectedIndex(L697-L717) returns the last one, which is the SDR variant.
Proposed fix
- Map
VIDEO-RANGEtoFormat.colorInfofor every variant. - Keep HDR and SDR tracks out of the same adaptive selection.
Both would select HDR on an SDR display unless HDR10 and HLG are checked against display capabilities (#1074). I can open PRs for 1 and 2.
Activity
tonihei commentedon Oct 8, 2026
Thanks for highlighting this issue again. We are aware of some track selection gaps in relation to HDR tracks and this is one of them. We not only need to keep them out of the same selection, but also make sure the prefer the right one according to display capabilities.
a-lyons commentedon Oct 11, 2026
Caveat: I'm not a software developer. I used AI to help troubleshoot my setup and draft this comment. I just want to help and provide additional information!
Another real-device repro, with a trigger not covered above: the HDR format is fully supported and only the audio needs transcoding.
Setup
OMX.dolby.vision.dvhe.*decoders are present. The same file direct plays (progressive MKV) on this device without issue.Trigger
Enabling the app's "downmix to stereo" option restricts audio to AAC/MP3/MP2 with ≤2 channels. The server then plans a remux: copy the video and transcode only the audio (
TranscodeReasons=AudioCodecNotSupported, no video reasons). It serves the same multivariant shape as the original report: the PQ copy variant first, then SDR transcode variants at identicalBANDWIDTH.Result
Every media segment requested came from an SDR variant:
hvc1Main 10 + SDRhvc1Main + SDRavc1variants: SDR HEVC was selected.hvc1Main 10 + SDRavc1only): SDR H.264 was selected over the PQ HEVC variant.The server ends up doing a full 4K decode → tone-map → re-encode for a stream the device could play untouched, and the viewer gets SDR instead of DV/HDR10.
In case it's useful: in the second case, selection moved to a different codec rather than to the PQ variant. So an HDR preference might need to apply across MIME types too, not only between same-codec variants. That's a guess from the outside, though.
Happy to test a build or share more logs.