L3 Widevine provisioning fails #1925
Comments
|
|
Some of these devices play successfully with Widevine-Dash content in Exoplayer 2.0.2 with Level 1 but not with Level 3. samsung Galaxy S5 SM-G900F Android 5 We have seen errors such as: |
|
@mlondon1 we reviewed a HTC10 log provided via email. The 'error' above is really a warning and is not the root cause. The log did not indicate that the error is not in the DRM space. Could this be an issue in serving up the content? Alternatively we have seen an issue similar to this and the cause was an inaccurate URL in the MPD. Does this content fail on all devices or just some devices? |
|
The http 404 is not the license server nor for the Dash content. I watch for that in Wireshark during playback. There seems to be a Google API for a cert in the media codec, could that be if?
|
|
This is what I was talking about that seems to be requested as the provisioning profile? https://www.googleapis.com/certificateprovisioning/v1/devicecertificates/create?key=< Key withheld> The full stack trace shows that it is the provisioning request in the Exoplayer DRM code: 10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): com.google.android.exoplayer2.ExoPlaybackException |
|
Note that this 404 happens with the Widevine Secure HD content on HTC 10 (Android 6.0.1) as well, when setting security level to 3. Staying in level 1 does not exhibit this issue. |
|
@wvpaf / @jefftinker - This looks quite serious. When the CDM requests provisioning, we generate the URL to which the request is sent as: But we're seeing 404s. This seems to occur across all devices. |
|
@mlondon1 - How are you implementing |
|
@ojw28 Yes I am taking the default implementation. Could you provide some assistance on that ? |
|
Yes. This is an unfortunate issue that I think we introduced as part of our work to support Cronet via an extension. Investigating possible fixes now. |
ojw28
changed the title
Issue #1925 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136035192
|
The change above fixes V1, where the issue was introduced as a regression in r1.5.11. We'll push a fix for V2 tomorrow. |
1. HttpMediaDrmCallback.executeProvisionRequest needs to specify an empty byte[], else we do a GET instead of a POST. 2. Content-Type should not be set when making the provision request, since there's no body. 3. DataSource implementations must correctly handle a non-null body with zero length. CronetDataSource was not handling this case. DefaultHttpDataSource was, but made a code modification to make it a little clearer. OkHttpDataSource seems to handle the case correctly, and it doens't look like the code can be made clearer. Issue #1925 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=136042641
|
This should now be fixed in |
|
This seems to have broken L1 playback for some devices such as |
|
It seems highly unlikely to me that the failure in the response above is related to this issue. The fix for this issue is only touching provisioning requests and POST requests via DefaultHttpDataSource. Changing these areas shouldn't in any way result in failures in the media decoder. You can probably verify the issue is unrelated pretty easily by patching the change in and out. I doubt this will reliably toggle the failure on and off. I doubt you'll find going back between tip-of-tree dev-2 and r2.0.2 makes any difference either, since I don't think we've changed anything that would have caused this as a new issue. It would be good if you could check though. |
|
That seems similarly unlikely. There were only 19 commits in 2.0.2 and I can't see any of them affecting this. If this is really true, please can you binary search to the exact commit that broke things (should take <=5 attempts) so that we can take a look and fix whatever the issue is. There are other important fixes in r2.0.3 (just released). I wouldn't recommend basing anything on earlier revisions of v2. |
|
Sorry - i deleted the comment after i was able to reproduce it in 2.0.1 as well after a few tries. I don't recall seeing the issue before, but I must have missed it - there must be something else going on. I will try 2.0.3. |
|
Thanks. The issue looks like some kind of device specific thing to be honest. I wouldn't be surprised if it reproduces on all ExoPlayer releases (including v1). |
Hi,
We see some older Android devices (4.4.2) only work with Level 3 security, while some newer devices only work with Level 1. This is not always the case, though.
What is the recommended approach for determining if a device supports one or the other in order to trigger one of the other like so:
mediaDrm.setPropertyString("securityLevel", "L3");
The text was updated successfully, but these errors were encountered: