L3 Widevine provisioning fails

[mlondon1]

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");

[ojw28]

• I'm pretty sure all devices should work with L3. If you know of devices where forcing L3 with setPropertyString doesn't work, please let us know exactly which models and OS versions. Ideally please provide bug reports so we can take a look.
• A MediaDrm should default to its best supported level without you having to do anything. Once you've instantiated a MediaDrm instance, you can query its level using mediaDrm.getPropertyString("securityLevel"). If the best supported level is L1 then it should be possible for you to force L3 by calling mediaDrm.setPropertyString("securityLevel", "L3"). If the best supported level is L3 then you will not be able to force L1. You can query the level again after an attempt to force to see whether forcing was successful. Forcing of level is only allowed prior to opening any sessions.

[mlondon1]

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
Motorola Moto X (2nd gen) Android 5.1
HTC 10 HTC6545LVM Android 6.0.1

We have seen errors such as:
10-07 12:13:00.734 364-364/? W/WVCdm: DeviceFiles::RetrieveFile: /data/mediadrm/IDM1013/L3/cert.bin does not exist

[wvpaf]

@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.
Here is an interesting bit:
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): Caused by: com.google.android.exoplayer2.upstream.HttpDataSource$InvalidResponseCodeException: Response code: 404

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?

[mlondon1]

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?

On Oct 11, 2016, at 6:23 PM, wvpaf notifications@github.com wrote:

@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.
Here is an interesting bit:
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): Caused by: com.google.android.exoplayer2.upstream.HttpDataSource$InvalidResponseCodeException: Response code: 404

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?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[mlondon1]

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
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at com.google.android.exoplayer2.mediacodec.MediaCodecRenderer.maybeInitCodec(MediaCodecRenderer.java:298)
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at com.google.android.exoplayer2.mediacodec.MediaCodecRenderer.render(MediaCodecRenderer.java:474)
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at com.google.android.exoplayer2.ExoPlayerImplInternal.doSomeWork(ExoPlayerImplInternal.java:431)
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:265)
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at android.os.Handler.dispatchMessage(Handler.java:98)
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at android.os.Looper.loop(Looper.java:168)
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at android.os.HandlerThread.run(HandlerThread.java:61)
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at com.google.android.exoplayer2.util.PriorityHandlerThread.run(PriorityHandlerThread.java:40)
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): Caused by: com.google.android.exoplayer2.upstream.HttpDataSource$InvalidResponseCodeException: Response code: 404
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at com.google.android.exoplayer2.upstream.DefaultHttpDataSource.open(DefaultHttpDataSource.java:212)
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at com.google.android.exoplayer2.upstream.DataSourceInputStream.checkOpened(DataSourceInputStream.java:118)
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at com.google.android.exoplayer2.upstream.DataSourceInputStream.read(DataSourceInputStream.java:89)
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at com.google.android.exoplayer2.upstream.DataSourceInputStream.read(DataSourceInputStream.java:79)
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at com.google.android.exoplayer2.util.Util.toByteArray(Util.java:116)
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at com.google.android.exoplayer2.drm.HttpMediaDrmCallback.executePost(HttpMediaDrmCallback.java:107)
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at com.google.android.exoplayer2.drm.HttpMediaDrmCallback.executeProvisionRequest(HttpMediaDrmCallback.java:74)
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at com.google.android.exoplayer2.drm.StreamingDrmSessionManager$PostRequestHandler.handleMessage(StreamingDrmSessionManager.java:513)
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at android.os.Handler.dispatchMessage(Handler.java:102)
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at android.os.Looper.loop(Looper.java:168)
10-11 14:14:52.222: E/ExoPlayerImplInternal(14445): at android.os.HandlerThread.run(HandlerThread.java:61)

[mlondon1]

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.

[ojw28]

@wvpaf / @jefftinker - This looks quite serious. When the CDM requests provisioning, we generate the URL to which the request is sent as:

String url = request.getDefaultUrl() + "&signedRequest=" + new String(request.getData());

But we're seeing 404s. This seems to occur across all devices.

[ojw28]

@mlondon1 - How are you implementing executeProvisionRequest? If you've taken ExoPlayer's default implementation, please try nulling out the request properties so that the Content-Type property doesn't get set. This appears to fix the issue when I tried it.

[mlondon1]

@ojw28 Yes I am taking the default implementation. Could you provide some assistance on that ?

[ojw28]

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.