DASH Widevine issue when scheme specific ContentProtection is omitted #3630
Comments
|
I'm not sure either, although regardless of whether it's required to include the scheme specific Assigning to myself to figure out whether we should be more lenient in this case. |
ojw28
changed the title
|
I am experiencing a similar issue, except my app crashes trying to parse the UUID from the the defaultKid string. I too have no control over the manifests, but it seems that the switch statement in the parseContentProtection method changed from 2.5.4 to 2.6.0, and now does not allow me to proceed for DASH Widevine parsing. Here is a sample of a manifest my app might use: <MPD xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:cenc="urn:mpeg:cenc:2013" xmlns:mas="urn:marlin:mas:1-0:services:schemas:mpd" xmlns:mspr="urn:microsoft:playready" mediaPresentationDuration="PT2H9M27.301S" minBufferTime="PT3.00S" profiles="urn:mpeg:dash:profile:isoff-on-demand:2011" type="static">
<!-- Created with Bento4 mp4-dash.py, VERSION=1.6.0-601 -->
<Period>
<AdaptationSet lang="English (United States)" mimeType="audio/mp4" segmentAlignment="true" startWithSAP="1">
<Role schemeIdUri="urn:mpeg:dash:role:2011" value="alternate" />
<!-- Common Encryption -->
<ContentProtection cenc:default_KID="12677be9-4e98-86cd-d05eee34fd5c547f" schemeIdUri="urn:mpeg:dash:mp4protection:2011" value="cenc" />
<!-- Marlin -->
<ContentProtection schemeIdUri="urn:uuid:5E629AF5-38DA-4063-8977-97FFBD9902D4">
<mas:MarlinContentIds>
<mas:MarlinContentId>urn:marlin:kid:12677be94e9886cdd05eee34fd5c547f</mas:MarlinContentId>
</mas:MarlinContentIds>
</ContentProtection>
<!-- PlayReady -->
<ContentProtection schemeIdUri="urn:uuid:9a04f079-9840-4286-ab92-e65be0885f95">
<mspr:pro>egIAAAEAAQBwAjwAVwBSAE0ASABFAEEARABFAFIAIAB4AG0AbABuAHMAPQAiAGgAdAB0AHAAOgAvAC8AcwBjAGgAZQBtAGEAcwAuAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBvAG0ALwBEAFIATQAvADIAMAAwADcALwAwADMALwBQAGwAYQB5AFIAZQBhAGQAeQBIAGUAYQBkAGUAcgAiACAAdgBlAHIAcwBpAG8AbgA9ACIANAAuADAALgAwAC4AMAAiAD4APABEAEEAVABBAD4APABQAFIATwBUAEUAQwBUAEkATgBGAE8APgA8AEsARQBZAEwARQBOAD4AMQA2ADwALwBLAEUAWQBMAEUATgA+ADwAQQBMAEcASQBEAD4AQQBFAFMAQwBUAFIAPAAvAEEATABHAEkARAA+ADwALwBQAFIATwBUAEUAQwBUAEkATgBGAE8APgA8AEsASQBEAD4ANgBYAHQAbgBFAHAAaABPAHoAWQBiAFEAWAB1ADQAMAAvAFYAeABVAGYAdwA9AD0APAAvAEsASQBEAD4APABDAEgARQBDAEsAUwBVAE0APgBFAFAAbABWAG0AOQBWAFkAZABWAGcAPQA8AC8AQwBIAEUAQwBLAFMAVQBNAD4APABMAEEAXwBVAFIATAA+AGgAdAB0AHAAcwA6AC8ALwBwAHIALgBzAHcAYQBuAGsAbQBwAC4AYwBvAG0ALwByAGkAZwBoAHQAcwBtAGEAbgBhAGcAZQByAC4AYQBzAG0AeAA8AC8ATABBAF8AVQBSAEwAPgA8AC8ARABBAFQAQQA+ADwALwBXAFIATQBIAEUAQQBEAEUAUgA+AA==</mspr:pro>
</ContentProtection>
<!-- Widevine -->
<ContentProtection schemeIdUri="urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
<cenc:pssh>AAAAXXBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAAD0IARIQEmd76U6Yhs3QXu40/VxUfxoFc3dhbmsiIDEyNjc3QkU5NEU5ODg2Q0REMDVFRUUzNEZENUM1NDdG</cenc:pssh>
</ContentProtection>
<!-- Primetime -->
<ContentProtection schemeIdUri="urn:uuid:F239E769-EFA3-4850-9C16-A903C6932EFB" />
<Representation audioSamplingRate="48000" bandwidth="221502" codecs="mp4a.40.2" id="audio-en-US">
<AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2" />
<BaseURL>A56627_E2_XX_XX_XX_en-US.mp4</BaseURL>
<SegmentBase indexRange="1467-32578">
<Initialization range="0-1466" />
</SegmentBase>
</Representation>
</AdaptationSet>
<AdaptationSet mimeType="video/mp4" segmentAlignment="true" startWithSAP="1">
<!-- Common Encryption -->
<ContentProtection cenc:default_KID="12677be9-4e98-86cd-d05eee34fd5c547f" schemeIdUri="urn:mpeg:dash:mp4protection:2011" value="cenc" />
<!-- Marlin -->
<ContentProtection schemeIdUri="urn:uuid:5E629AF5-38DA-4063-8977-97FFBD9902D4">
<mas:MarlinContentIds>
<mas:MarlinContentId>urn:marlin:kid:12677be94e9886cdd05eee34fd5c547f</mas:MarlinContentId>
</mas:MarlinContentIds>
</ContentProtection>
<!-- PlayReady -->
<ContentProtection schemeIdUri="urn:uuid:9a04f079-9840-4286-ab92-e65be0885f95">
<mspr:pro>egIAAAEAAQBwAjwAVwBSAE0ASABFAEEARABFAFIAIAB4AG0AbABuAHMAPQAiAGgAdAB0AHAAOgAvAC8AcwBjAGgAZQBtAGEAcwAuAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBvAG0ALwBEAFIATQAvADIAMAAwADcALwAwADMALwBQAGwAYQB5AFIAZQBhAGQAeQBIAGUAYQBkAGUAcgAiACAAdgBlAHIAcwBpAG8AbgA9ACIANAAuADAALgAwAC4AMAAiAD4APABEAEEAVABBAD4APABQAFIATwBUAEUAQwBUAEkATgBGAE8APgA8AEsARQBZAEwARQBOAD4AMQA2ADwALwBLAEUAWQBMAEUATgA+ADwAQQBMAEcASQBEAD4AQQBFAFMAQwBUAFIAPAAvAEEATABHAEkARAA+ADwALwBQAFIATwBUAEUAQwBUAEkATgBGAE8APgA8AEsASQBEAD4ANgBYAHQAbgBFAHAAaABPAHoAWQBiAFEAWAB1ADQAMAAvAFYAeABVAGYAdwA9AD0APAAvAEsASQBEAD4APABDAEgARQBDAEsAUwBVAE0APgBFAFAAbABWAG0AOQBWAFkAZABWAGcAPQA8AC8AQwBIAEUAQwBLAFMAVQBNAD4APABMAEEAXwBVAFIATAA+AGgAdAB0AHAAcwA6AC8ALwBwAHIALgBzAHcAYQBuAGsAbQBwAC4AYwBvAG0ALwByAGkAZwBoAHQAcwBtAGEAbgBhAGcAZQByAC4AYQBzAG0AeAA8AC8ATABBAF8AVQBSAEwAPgA8AC8ARABBAFQAQQA+ADwALwBXAFIATQBIAEUAQQBEAEUAUgA+AA==</mspr:pro>
</ContentProtection>
<!-- Widevine -->
<ContentProtection schemeIdUri="urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
<cenc:pssh>AAAAXXBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAAD0IARIQEmd76U6Yhs3QXu40/VxUfxoFc3dhbmsiIDEyNjc3QkU5NEU5ODg2Q0REMDVFRUUzNEZENUM1NDdG</cenc:pssh>
</ContentProtection>
<!-- Primetime -->
<ContentProtection schemeIdUri="urn:uuid:F239E769-EFA3-4850-9C16-A903C6932EFB" />
<Representation bandwidth="1212093" codecs="avc1.4D401F" frameRate="24000/1001" height="720" id="video-1" scanType="progressive" width="1280">
<BaseURL>A56627_E2_XX_XX_XX_720p_1200kbps_en-US.mp4</BaseURL>
<SegmentBase indexRange="1539-9334">
<Initialization range="0-1538" />
</SegmentBase>
</Representation>
<Representation bandwidth="1511461" codecs="avc1.4D401F" frameRate="24000/1001" height="480" id="video-2" scanType="progressive" width="854">
<BaseURL>A56627_E2_XX_XX_XX_480p_1500kbps_en-US.mp4</BaseURL>
<SegmentBase indexRange="1539-9334">
<Initialization range="0-1538" />
</SegmentBase>
</Representation>
</AdaptationSet>
</Period>
</MPD>And here is the exception: Clearly that string is not a valid UUID, hence the crash, but the format of the manifest has not changed, which leads me to wonder why the change from 2.5.4 to 2.6.0 was made that would break this step in the parsing process. I would love to be able to take advantage of the improvements made in 2.6.0, but cannot until this is resolved. Thanks! |
|
Does your app really crash (i.e. the process actually dies because the exception is uncaught), or is it just that playback fails? If your app really crashes, please provide the complete stack trace (i.e. there must be more call stack calling into |
|
My application does not crash, since I catch the exception, but the exception is received via the onPlayerError listener method, as a ExoPlaybackException, with the cause of the error being the UUID stacktrace above. |
|
@piatt - I took a look at your example. The manifest is not spec compliant, and unfortunately failure is expected in this case. We have no plan to mitigate the issue unless it turns out to be a widespread problem, so I suggest you contact whoever's content you're attempting to play and ask them to fix it. The reason it fails now when it didn't previously is that we're parsing more elements from the manifest, which was required to fix #3138. If you require a workaround for the issue then you can extend |
|
@ojw28 thanks for letting me know. I can try your workaround in the interim, but could you provide a couple of technical specifics or point me to spec reqs that I could bring to the manifest vendor as items that would need to change? Any help would be much appreciated! |
|
The only thing wrong with the manifest is that the UUID we're failing to parse is missing a dash where there should be one. It's in the manifest as: But it should be: See: https://en.wikipedia.org/wiki/Universally_unique_identifier |
|
@llooz - I think our plan is to optimistically attempt playback of media in the case you describe (printing a warning to logcat). Playback will then fail a bit later in the initialization process if scheme specific DRM init data for the correct scheme (Widevine) isn't present in the streams themselves. |
|
@ojw28 We have experienced the same issue here: in 2.5.4 parsing content protection is omitted, so when using DashUtil.loadDrmInitData, it goes to DashUtil.loadSampleFormat to get drmInitData; while in 2.6.0 it parses content protection, but drmInitData.data is null, which will causes DefaultDrmSessionManager.acquireSession failure. |
|
@ojw28 thank you for you help! |
|
@ojw28 Same problem here, looks like @llooz one. Here is mpd which fails: |
- Parse multiple kids from default_KID. It's specified as a whitespace separated list of UUIDs rather than a single UUID. - Opportunistically proceed with playback in cases where the manifest only defines a single SchemeData with the common PSSH UUID. In such cases the manifest isn't saying anything about which specific DRM schemes it supports. Issue: #3630 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=180675056
DASH manifests can now contain non-null but incomplete DRM init data. Hence using the manifest init data when non-null is not always the correct thing to do. This change merges the sample and manifest formats (which correctly merges the DRM init data) and then uses the result. Issue: #3630 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=180787784
|
The issue should be fixed on the latest |
|
I verified a1bac99, it's working for me. Thanks. |
|
@llooz - Is it possible for you to verify also? The issue @letianxu verified is related, but different. Thanks! |
|
@ojw28 with the latest dev commit |
|
Right, that's probably still a problem. Are you able to share a sample piece of media? It would help us to fix this more efficiently. |
|
@ojw28 same problem as @llooz with the commit a1bac99 |
|
@llooz - I'm not sure I understand that manifest, regardless of this issue. It appears to indicate that the audio streams are not DRM protected at all, when in fact they are. |
|
Ignore me, the audio streams appear to not be DRM protected after all. |
|
@AquilesCanta - Current status of this issue is approximately:
I'm not sure we can avoid having a special case for the manifest containing only a
There might be a simpler or completely different way. WDYT? |
---------------------------------- Original change description: DRM fixes - Parse multiple kids from default_KID. It's specified as a whitespace separated list of UUIDs rather than a single UUID. - Opportunistically proceed with playback in cases where the manifest only defines a single SchemeData with the common PSSH UUID. In such cases the manifest isn't saying anything about which specific DRM schemes it supports. Issue: #3630 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=181137621
|
Another attempt to fix this is 8716c0e, now in |
|
I tested on last commit in dev-v2 (f432b52). |
I have a DASH content protected with Widevine that doesn't work only on ExoPlayer 2.6.0 (it works on 2.5.4).
The manifest for content protection contains only
<ContentProtection schemeIdUri="urn:mpeg:dash:mp4protection:2011" value="cenc" cenc:default_KID="fe2cbd2e-78a3-5fdd-b1f7-3b166d8abbed" />When checking if the video format is supported 2.6.0 returns
FORMAT_UNSUPPORTED_DRM.I have debugged the ExoPlayer source of 2.5.4 and 2.6.0 to find the difference.
On 2.5.4 the previous
ContentProtectiontag is ignored inDashManifestParserand sodrmInitDatainsidesupportsFormatofMediaCodecRendereris null and it assumes that there is no protection. Only later it will updatedrmInitDataby parsing a WidevineSchemeDatafrom the MP4 atoms and ask for the license.On 2.6.0 the
ContentProtectiontag is parsed with aSchemeDatahavingCOMMON_PSSH_UUIDas uuid. Because there is an existingDrmInitDatatheMediaVideoCodecRendererclass doesn't assume that there is no protection and checks if it's a supported DRM by callingcanAcquireSessionofDrmSessionManager.DefaultDrmSessionManagercallsgetSchemeDatathat will return null because there is no match with the Widevine UUID or with the CLEARKEY logic, this will finally result inFORMAT_UNSUPPORTED_DRM.I don't know much about DASH manifest and DRM standards so currently i can't say if it's an ExoPlayer issue or it's a malformed manifest.
Unfortunately i don't have any control on these DASH manifests.
The text was updated successfully, but these errors were encountered: