Playback failure with Dolby Vision Encrypted content: "Operation not supported in this configuration"

[ramabyg]

Issue:
When Dolby Vision encrypted content is played, in certain scenearios, "playaback failed" message is displayed.
This issue is observed only on few specific devices
ex: Google Chromecast TV, TiVo 4K stick
adb log show as below when error happens

2021-03-10 16:31:39.100 7789-7878/com.google.android.exoplayer2.demo E/ExoPlayerImplInternal: Playback error
com.google.android.exoplayer2.ExoPlaybackException: MediaCodecVideoRenderer error, index=0, format=Format
at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:554)
at android.os.Handler.dispatchMessage(Handler.java:103)
at android.os.Looper.loop(Looper.java:214)
at android.os.HandlerThread.run(HandlerThread.java:67)
Caused by: android.media.MediaCodec$CryptoException: Operation not supported in this configuration
at android.media.MediaCodec.native_queueSecureInputBuffer(Native Method)
at android.media.MediaCodec.queueSecureInputBuffer(MediaCodec.java:2700)
at com.google.android.exoplayer2.mediacodec.SynchronousMediaCodecAdapter.queueSecureInputBuffer(Synchro
at com.google.android.exoplayer2.mediacodec.MediaCodecRenderer.feedInputBuffer(MediaCodecRenderer.java:
at com.google.android.exoplayer2.mediacodec.MediaCodecRenderer.render(MediaCodecRenderer.java:826)
at com.google.android.exoplayer2.ExoPlayerImplInternal.doSomeWork(ExoPlayerImplInternal.java:947)
at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:477)
at android.os.Handler.dispatchMessage(Handler.java:103) 
at android.os.Looper.loop(Looper.java:214) 
at android.os.HandlerThread.run(HandlerThread.java:67) 

Steps to reproduce the issue:

• • Google Chromecast TV and connect to Dolby Vision supported TV
• • Use latest Exoplayer demo application from GitHub
• • Use any of below asset to stream content
• • Make sure demo player initially starts with 1280x720 resolution (id:3), then it switches to 3840x2160(id:4) at around 19 sec.
• • Force stop the Exoplayer so that it start fresh. Otherwise, it may directly pick up id:4 i.e. 380x2160
• • Playback fails exactly at 34th sec.

      {
        "name": "HLS Encodes Stream",
        "uri": "https://ott.dolby.com/media/exoplayer_testing/shaka_universe_drm/universe_shaka_drm_cenc.m3u8",
        "drm_scheme": "widevine",
        "drm_license_url": "https://drm-widevine-licensing.axtest.net/AcquireLicense",
        "drm_key_request_properties": {
          "X-AxDRM-Message": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2ZXJzaW9uIjoxLCJjb21fa2V5X2lkIjoiYjMzNjRlYjUtNTFmNi00YWUzLThjOTgtMzNjZWQ1ZTMxYzc4IiwibWVzc2FnZSI6eyJ0eXBlIjoiZW50aXRsZW1lbnRfbWVzc2FnZSIsImtleXMiOlt7ImlkIjoiOWViNDA1MGQtZTQ0Yi00ODAyLTkzMmUtMjdkNzUwODNlMjY2IiwiZW5jcnlwdGVkX2tleSI6ImxLM09qSExZVzI0Y3Iya3RSNzRmbnc9PSJ9XX19.4lWwW46k-oWcah8oN18LPj5OLS5ZU-_AQv7fe0JhNjA"
        }
      },
      {
        "name": "MPEG-DASH Encodes Stream",
        "uri": "https://ott.dolby.com/media/exoplayer_testing/shaka_universe_drm/universe_shaka_drm_cenc.mpd",
        "drm_scheme": "widevine",
        "drm_license_url": "https://drm-widevine-licensing.axtest.net/AcquireLicense",
        "drm_key_request_properties": {
          "X-AxDRM-Message": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2ZXJzaW9uIjoxLCJjb21fa2V5X2lkIjoiYjMzNjRlYjUtNTFmNi00YWUzLThjOTgtMzNjZWQ1ZTMxYzc4IiwibWVzc2FnZSI6eyJ0eXBlIjoiZW50aXRsZW1lbnRfbWVzc2FnZSIsImtleXMiOlt7ImlkIjoiOWViNDA1MGQtZTQ0Yi00ODAyLTkzMmUtMjdkNzUwODNlMjY2IiwiZW5jcnlwdGVkX2tleSI6ImxLM09qSExZVzI0Y3Iya3RSNzRmbnc9PSJ9XX19.4lWwW46k-oWcah8oN18LPj5OLS5ZU-_AQv7fe0JhNjA"
        }
      }

[icbaker]

The logcat snippet doesn't include enough information to diagnose this issue.

Can you take a full bug report ($ adb bugreport)? It will include additional logging from before the stack trace you've snipped, as well as lots of useful info about the state of the device at the time of the problem.

If you're unable to share bug reports or test content publicly, please send them to dev.exoplayer@gmail.com using a subject in the format "Issue #1234" ("#1234" is replaced with your issue number). Please also update this issue to indicate you've done this.

[ramabyg]

hi, thank you for looking into this issue.
Attached is bugreport generated with $ adb bugreport just after playback failure.
bugreport-sabrina_prod_stable-QTS2.200918.033-2021-03-12-07-09-52.zip

[icbaker]

Thanks for the BR, there's a lot of lines like this coming from the DRM module which are apparently errors but seem like they might actually be fine (the length varies on each line):

E oemcrypto_tz: [_oecc48:872] decrypt CENC data_length 223968, decrypt in chunk

And then right before the Java playback error stack trace there's some other errors from the DRM/Widevine components that look like the probable cause:

I oemcrypto_tz: [OEMCrypto_TEEInvokeData:476] cmd 1048 return 28
E oemcrypto_tz: [OEMCrypto_TEEInvokeData:478] error return 28
E oemcrypto_tz: [_oecc48:905] error return 28
E WVCdm   : Decrypt error result in session sid9 during unencrypted block: 178

@jt64 can you take a look from a Widevine perspective? Thanks!

[ramabyg]

Hi,
We wanted to present another observation, it might help to analyze further this bug.
While trying to resolve a problem "Buffer too small" issue on Amazon Toshiba Fire TV, we observed that
"getCodecMaxInputSize" method in MediaCodecVideoRenderer.java gives "Format.NO_VALUE" for mime type VIDEO_DOLBY_VISION. So we added case to resolve "Buffer too small" issue as below

      case MimeTypes.VIDEO_DOLBY_VISION:
      case MimeTypes.VIDEO_H265:
      case MimeTypes.VIDEO_VP9:
        maxPixels = width * height;
        minCompressionRatio = 4;

In above code when "minCompressionRatio" is set to 2, i.e. increase Max Buffer requirement, current issue also seems to go away.

But, we could not get exact relation between Crypto Module error (Operation not supported) and buffer size.
Just providing additional info, if it helps to root cause correct issue..

[icbaker]

Thanks for that extra detail about MediaCodecVideoRenderer - changing something in that method looks like a sensible improvement to ExoPlayer.

Since Dolby Vision can wrap both AVC and HEVC content, and AVC has a lower minimum compression ratio, I'm going to add it to the H264 case block instead.

I'll go ahead and make that change.