Version

Media3 main branch

More version details

DashManifestParser.buildFormat() unconditionally promotes HEVC to Dolby Vision when supplementalCodecs is present, causing wrong track selection

Devices that reproduce the issue

All Android Device

Devices that do not reproduce the issue

NA

Reproducible in the demo app?

Yes

Reproduction steps

Play a DASH stream where the manifest contains both AVC and HEVC AdaptationSets, and the HEVC representations include scte214:supplementalCodecs="dvh1.08.xx" (Dolby Vision Profile 8):

<!-- AVC AdaptationSet -->
<AdaptationSet mimeType="video/mp4" codecs="avc1.640020">
  <Representation bandwidth="3911733" codecs="avc1.64001f" height="720" width="1280" />
  <Representation bandwidth="10246893" codecs="avc1.64002a" height="1080" width="1920" />
</AdaptationSet>

<!-- HEVC AdaptationSet with DV Profile 8 supplementalCodecs -->
<AdaptationSet mimeType="video/mp4" codecs="hvc1.2.4.L123">
  <Representation bandwidth="4013913" codecs="hvc1.2.4.L93" height="720" width="1280"
      scte214:supplementalCodecs="dvh1.08.02" scte214:supplementalProfiles="db1p" />
  <Representation bandwidth="8714193" codecs="hvc1.2.4.L123" height="1080" width="1920"
      scte214:supplementalCodecs="dvh1.08.05" scte214:supplementalProfiles="db1p" />
</AdaptationSet>

Observe that DefaultTrackSelector selects the AVC track instead of the HEVC track.

Expected result

ExoPlayer should select the HEVC track. Per RFC 8216bis Section 4.4.6.2, SUPPLEMENTAL-CODECS (the HLS equivalent of SCTE-214's scte214:supplementalCodecs) describes:

"media samples with both a backward-compatible base layer and a newer enhancement layer. The base layers are specified in the CODECS attribute and the enhancement layers are specified by the SUPPLEMENTAL-CODECS attribute."
The Dolby Vision Profiles and Levels specification further confirms that Profile 8 content:
"Can be played by a decoder system that is unaware of Dolby Vision using only the base layer"
When the device lacks a primary DV decoder, the player should fall back to the base HEVC codec (which the device can decode as PRIMARY) rather than discarding it.

Actual result

ExoPlayer selects AVC instead of HEVC. The cause is in DashManifestParser.buildFormat():

if (MimeTypes.isDolbyVisionCodec(codecs, supplementalCodecs)) {
    sampleMimeType = MimeTypes.VIDEO_DOLBY_VISION;  // Unconditional promotion
    codecs = supplementalCodecs;                      // Base HEVC codec discarded
}

This unconditionally promotes sampleMimeType from video/hevc to video/dolby-vision and replaces the base codec string with the supplemental DV codec string — without checking whether the device has a primary DV decoder.

On devices without a native DV decoder, MediaCodecVideoRenderer.supportsFormat() returns DECODER_SUPPORT_FALLBACK_MIMETYPE for the DV track.

DefaultTrackSelector.VideoTrackInfo.compareNonQualityPreferences then compares usesPrimaryDecoder:

AVC: usesPrimaryDecoder = true (PRIMARY)
HEVC/DV: usesPrimaryDecoder = false (FALLBACK_MIMETYPE)

AVC wins, despite HEVC being a more efficient codec that the device can fully decode.

Media

How other players handle this:

Shaka Player (dash_parser.js, PR #7720):
Keeps the original HEVC representation as-is
Creates a duplicate representation with the DV codec
Both go through MediaCapabilities.decodingInfo() — the device decides which it can play
If DV is unsupported, the duplicate is filtered out and the original HEVC survives

dash.js (CapabilitiesFilter.js , PR #4585):
Checks device capability for both the base codec and the supplemental codec independently
Only upgrades the codec string to DV if the device confirms support
If only the base HEVC is supported, the representation stays as HEVC
Both players follow the spec's intent: parse both codecs, check device capability, then decide.

Bug Report

• You will email the zip file produced by adb bugreport to android-media-github@google.com after filing this issue.