Version

Media3 main branch

More version details

No response

Devices that reproduce the issue

All Android devices

Devices that do not reproduce the issue

NA

Reproducible in the demo app?

Yes

Reproduction steps

1. Play a DASH manifest where the SCTE-214 namespace uses a non-standard prefix (e.g., _ instead of scte214):

<MPD xmlns:_="urn:scte:dash:scte214-extensions">
  <AdaptationSet mimeType="video/mp4">
    <Representation codecs="hvc1.2.4.L150.90" bandwidth="4725303"
        _:supplementalCodecs="dvh1.08.05" _:supplementalProfiles="db1p" />
  </AdaptationSet>
</MPD>

2. Compare with the same manifest using the standard prefix:

<MPD xmlns:scte214="urn:scte:dash:scte214-extensions">
  <AdaptationSet mimeType="video/mp4">
    <Representation codecs="hvc1.2.4.L123.90" bandwidth="4827805"
        scte214:supplementalCodecs="dvh1.08.03" scte214:supplementalProfiles="db1p" />
  </AdaptationSet>
</MPD>

In 1st case, ExoPlayer DashManifestParser skips the supplementalCodecs and treat this as a HEVC codec where as in 2nd case, It parse the supplemental property scte214:supplementalCodecs and treat it as a dolby-vision codec.

When it decipher as dolby-vision codec, and mark this as fallback decoder where the device does not support the Dolby vision and does not usage the backward compatible HEVC. whereas it should usage the backward compatible decoder.

We have create another bug to address this observation: #3135

Expected result

ExoPlayer should parse the supplementalCodecs attribute regardless of the namespace prefix used in the manifest. A manifest using _:supplementalCodecs with xmlns:_="urn:scte:dash:scte214-extensions" is semantically identical to one using scte214:supplementalCodecs with xmlns:scte214="urn:scte:dash:scte214-extensions", and both should produce the same parsed output.

Actual result

• scte214:supplementalCodecs — ExoPlayer recognizes it, promotes MIME type to video/dolby-vision, and sets the DV codec string.
• _:supplementalCodecs — ExoPlayer silently ignores it. The HEVC track stays as video/hevc with the base codec string.

In the seconds case(_:supplementalCodecs), It works only because the parser fails to recognize the attribute and fallback to HEVC with DV.

This means identical content packaged with different (but equally valid) namespace prefixes produces different playback behavior.

DashManifestParser uses a literal string match instead of a proper namespace-aware attribute lookup using the namespace URI.

DashManifestParser.java

String supplementalCodecs =
    parseString(xpp, "scte214:supplementalCodecs", adaptationSetSupplementalCodecs);
String supplementalProfiles =
    parseString(xpp, "scte214:supplementalProfiles", adaptationSetSupplementalProfiles);

  public static boolean isDolbyVisionCodec(
      @Nullable String codecs, @Nullable String supplementalCodecs) {
    if (codecs == null) {
      return false;
    }
    if (codecs.startsWith("dvhe") || codecs.startsWith("dvh1")) {
      // profile 5
      return true;
    }
    if (supplementalCodecs == null) {
      return false;
    }
    // profiles 8, 9 and 10
    return (supplementalCodecs.startsWith("dvhe") && codecs.startsWith("hev1"))
        || (supplementalCodecs.startsWith("dvh1") && codecs.startsWith("hvc1"))
        || (supplementalCodecs.startsWith("dvav") && codecs.startsWith("avc3"))
        || (supplementalCodecs.startsWith("dva1") && codecs.startsWith("avc1"))
        || (supplementalCodecs.startsWith("dav1") && codecs.startsWith("av01"));
  }

Shaka player consider the namespace along with codec:
https://github.com/shaka-project/shaka-player/blob/main/lib/dash/dash_parser.js#L2170-L2186

PR that added the DV support, but failed to added/consider for backward compatible HEVC with DV8 profile: 79078c3

Media

How other players handle this:

Shaka Player uses getAttributeNS with the namespace URI

const supplementalCodecs = TXml.getAttributeNS(
    rep, 'urn:scte:dash:scte214-extensions', 'supplementalCodecs');

This matches by namespace URI, so any prefix (scte214:, _:, foo:, etc.) works correctly.

Bug Report

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