DASH Widevine CBC1 and CBCS encrypted content not playing on Android 7.1

[jhughes]

Issue description

I'm testing DASH manifests encrypted with CBC1 and CBCS with Widevine DRM.
On Android 7.1, Exoplayer playback exits with an exception when it reaches the first encrypted segment.

The same manifests play OK on Android 8.0 and 8.1.
DASH manifest encrypted with CENC plays OK on Android 7.1, the issue seems to be with CBC.

Exception excerpt:

WVCdm   : Decrypt error result in session sid2 during encrypted block: 176
ExoPlayerImplInternal: Renderer error.
ExoPlayerImplInternal: com.google.android.exoplayer2.ExoPlaybackException
ExoPlayerImplInternal:         at com.google.android.exoplayer2.mediacodec.MediaCodecRenderer.feedInputBuffer(MediaCodecRenderer.java:765)
ExoPlayerImplInternal:         at com.google.android.exoplayer2.mediacodec.MediaCodecRenderer.render(MediaCodecRenderer.java:568)
ExoPlayerImplInternal:         at com.google.android.exoplayer2.ExoPlayerImplInternal.doSomeWork(ExoPlayerImplInternal.java:518)
ExoPlayerImplInternal:         at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:301)
ExoPlayerImplInternal:         at android.os.Handler.dispatchMessage(Handler.java:98)
ExoPlayerImplInternal:         at android.os.Looper.loop(Looper.java:154)
ExoPlayerImplInternal:         at android.os.HandlerThread.run(HandlerThread.java:61)
ExoPlayerImplInternal: Caused by: android.media.MediaCodec$CryptoException: Unknown Error
ExoPlayerImplInternal:         at android.media.MediaCodec.native_queueSecureInputBuffer(Native Method)
ExoPlayerImplInternal:         at android.media.MediaCodec.queueSecureInputBuffer(MediaCodec.java:2480)
ExoPlayerImplInternal:         at com.google.android.exoplayer2.mediacodec.MediaCodecRenderer.feedInputBuffer(MediaCodecRenderer.java:756)
ExoPlayerImplInternal:         ... 6 more

Reproduction steps

Play provided test content using the demo player for at least 10 seconds (The first encrypted segment occurs at 10 seconds)

Link to test content

The failing content is from the demo application:

{
  "name": "WV: Secure SD & HD (cbc1,MP4,H264)",
  "uri": "https://storage.googleapis.com/wvmedia/cbc1/h264/tears/tears_aes_cbc1.mpd",
  "drm_scheme": "widevine",
  "drm_license_url": "https://proxy.uat.widevine.com/proxy?provider=widevine_test"
},
{
  "name": "WV: Secure SD & HD (cbcs,MP4,H264)",
  "uri": "https://storage.googleapis.com/wvmedia/cbcs/h264/tears/tears_aes_cbcs.mpd",
  "drm_scheme": "widevine",
  "drm_license_url": "https://proxy.uat.widevine.com/proxy?provider=widevine_test"
}

Version of ExoPlayer being used

Exoplayer 2.7.0

Device(s) and version(s) of Android being used

Tested with Pixel XL (Android 7.1)

A full bug report captured from the device

Bug report for Pixel XL provided in email.

[AquilesCanta]

We'll have a look and update with any findings.

[AquilesCanta]

It seems to be broken on 7.1, but does work correctly on MR1 (7.1.1) and later. Without knowing any workaround, the only suggestion I can give you is to update Android. Maybe @wvpaf can provide insight. Otherwise, I think it is okay to close this issue, as there is not much we can do in ExoPlayer (except maybe improving support detection to avoid a crash -- @ojw28?).

[AquilesCanta]

[Internal ref: b/77217735]

[jhughes]

Thanks, @AquilesCanta Do you know if it works on 7.0? I don't have a 7.0 device to test on.

If this can't be fixed, the supported formats is misleading. Can that be updated?

[AquilesCanta]

Will update this next week. We need to figure out if flaky support is the case on all devices. It is rather ambitious to try building a supported format list that takes into account specific device issues. Thanks for your patience!

[AquilesCanta]

Hi @jhughes, did you manually flash the device to 7.0 (build = NDE63L)? Or did it only receive OTA updates?

[jhughes]

@AquilesCanta It's a phone from our device lab so I don't know its history. To the best of my knowledge it's only received OTA updates. I've reached out to my device lab manager, I'll update this with what he says.

[jhughes]

The device has not been flashed. To the best of our knowledge, it is stock and OTA updates only.

[AquilesCanta]

Hi @jhughes, we have tightened the check for CBC support to be API 25+. However, your phone will be a false positive case for this check, since it is not running a post MR1 version, which included the fix for this widevine bug. We have not agreed on how to prevent these devices from reporting support for AES-CBC, so the only suggestion I have for the time being is to update the device (anything 7.1.1+ will work). There are very few devices in the wild running 7.1, so this should not be an issue for your app (if you have one). If we find evidence that this is a real problem, we will revisit this discussion. Thanks for your report!

[goffioul]

Hi @AquilesCanta, I have a Rockchip-based device running 7.1.2 (NHG47K) and I'm having the same problem: the ExoPlayer demo produces the same backtrace when playing the CBC1 or CBCS samples (the error occurs about 10 seconds after playback starts). I'm also using ExoPlayer 2.7.0. Are you positive these sample should work, and the problem is likely on the platform-side?

[AquilesCanta]

Hi @goffioul, could you open a new issue including all the info required in the template? I don't think it's actually the same issue but rather a device-specific one.

[goffioul]

@AquilesCanta I got feedback from the OEM (and Rockchip) that the CBC1 and CBCS sample streams require Widevine L1, and the device I'm testing with only supports Widevine L3. Can you confirm that these samples actually require L1?

[AquilesCanta]

Can you confirm that these samples actually require L1?

I don't think they require L1. It might be better for you to follow up with them than with us, considering it's a device specific issue (not much we can do, usually).

[goffioul]

Thanks. I'm following with them, but I was looking for an alternate way to verify their claim (which is I need to use another chipset as that one has no support for L1).