New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 719135 link

Starred by 2 users
Status: Fixed
Owner:
xhw...@chromium.org
Closed: May 2017
Cc:
█ ti...@chromium.org
█ joeyparrish@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

Shaka player cannot play Sintel 4l Widevine on WebView

Reported by ti...@chromium.org, May 6 2017 
Nexus 5X, Android N (bullhead-userdebug 7.1.2 N2G47F 3769476 dev-keys)

WebView monochrome_apk 60.0.3089.0 Debug build

To reproduce:

1. In WebView shell navigate to https://shaka-player-demo.appspot.com
2. Select asset Sintel 4k (multicodec, Widevine)
3. Press Load

The video plays for some time, then stops.

05-05 19:36:39.964 24395 24660 D cr_media: [MediaDrmBridge.java:1364] Key successfully added for session 7369643232
05-05 19:36:39.987 24395 24395 I MediaDrm: Drm key status changed
05-05 19:36:39.987 24395 24395 D cr_media: [MediaDrmBridge.java:1314] KeysStatusChange: 7369643232, true
05-05 19:36:39.988 24395 24660 V chromium: [VERBOSE2:mojo_cdm_service.cc(228)] OnSessionKeysChange has_additional_usable_key=1
05-05 19:36:39.989 24395 24395 I MediaDrm: Drm key expiration update: 0
05-05 19:36:39.989 24395 24395 D cr_media: [MediaDrmBridge.java:1337] ExpirationUpdate: 7369643232, 0
05-05 19:36:39.990 24395 24660 V chromium: [VERBOSE2:mojo_cdm_service.cc(240)] OnSessionExpirationUpdate expiry=1601-01-01 00:00:00.000 UTC
05-05 19:36:39.995 24395 24438 V chromium: [VERBOSE2:mojo_cdm.cc(306)] OnSessionKeysChange
05-05 19:36:39.996 24395 24438 V chromium: [VERBOSE2:cdm_session_adapter.cc(200)] OnSessionKeysChange: session_id = sid22
05-05 19:36:39.996 24395 24438 V chromium: [VERBOSE2:cdm_session_adapter.cc(201)]   - has_additional_usable_key = 1
05-05 19:36:39.996 24395 24438 V chromium: [VERBOSE2:cdm_session_adapter.cc(203)]   - key_id = 26470F4296D45D04A9BABB442E169800, status = USABLE, system_code = 0
05-05 19:36:39.996 24395 24438 V chromium: [VERBOSE2:cdm_session_adapter.cc(203)]   - key_id = 517453862D4256FD8BAD4F58422004D7, status = USABLE, system_code = 0
05-05 19:36:39.996 24395 24438 V chromium: [VERBOSE2:cdm_session_adapter.cc(203)]   - key_id = F0937E9A77C855F0A6D43864C5D9F365, status = USABLE, system_code = 0
05-05 19:36:39.996 24395 24438 V chromium: [VERBOSE2:mojo_cdm.cc(333)] OnSessionExpirationUpdate
05-05 19:36:39.996 24395 24438 V chromium: [VERBOSE2:cdm_session_adapter.cc(216)] OnSessionExpirationUpdate: session_id = sid22
05-05 19:36:39.996 24395 24438 V chromium: [VERBOSE2:cdm_session_adapter.cc(218)]   - new_expiry_time = NaN
05-05 19:36:40.680 24395 24438 V chromium: [VERBOSE1:webmediaplayer_impl.cc(1302)] OnBufferingStateChange(1)
05-05 19:36:40.680 24395 24438 V chromium: [VERBOSE1:webmediaplayer_impl.cc(1806)] SetReadyState(4)
05-05 19:36:40.681 24395 24438 V chromium: [VERBOSE1:webmediaplayer_impl.cc(584)] SetRate(1)
05-05 19:36:40.681 24395 24438 V chromium: [VERBOSE1:webmediaplayer_impl.cc(609)] SetVolume(1)
05-05 19:36:40.681 24395 24438 V chromium: [VERBOSE2:renderer_webmediaplayer_delegate.cc(107)] DidPause(2)
05-05 19:36:40.681 24395 24438 V chromium: [VERBOSE2:renderer_webmediaplayer_delegate.cc(129)] SetIdle(2, 1)
05-05 19:36:40.681 24395 24438 V chromium: [VERBOSE1:webmediaplayer_impl.cc(439)] Play
05-05 19:36:40.681 24395 24438 V chromium: [VERBOSE2:renderer_webmediaplayer_delegate.cc(129)] SetIdle(2, 0)
05-05 19:36:40.682 24395 24438 V chromium: [VERBOSE2:renderer_webmediaplayer_delegate.cc(85)] DidPlay(2, 1, 1, 0)
05-05 19:36:40.682 24395 24438 V chromium: [VERBOSE2:renderer_webmediaplayer_delegate.cc(129)] SetIdle(2, 0)
05-05 19:36:40.687 24395 24438 V chromium: [VERBOSE3:renderer_webmediaplayer_delegate.cc(294)] UpdateTask
05-05 19:36:40.688 24395 24438 V chromium: [VERBOSE1:webmediaplayer_impl.cc(609)] SetVolume(1)
05-05 19:36:51.246 24395 24438 V chromium: [VERBOSE1:mp4_stream_parser.cc(434)] video_track_id=1 config=codec: h264 format: 2 profile: h264 high coded size: [3840,1636] visible rect: [0,0,3840,1636] natural size: [3842,1636] has extra data? false encrypted? true
05-05 19:36:51.247 24395 24438 V chromium: [VERBOSE1:mp4_stream_parser.cc(497)] liveness: 1
05-05 19:36:51.835   552   664 E WVCdm   : WvContentDecryptionModule::Decrypt: unable to find session
05-05 19:36:51.835   552   664 E WVCdm   : Decrypt error result in session sid21 during unencrypted block: 5
05-05 19:36:51.836 24395 24446 D cr_MediaCodecBridge: [MediaCodecBridge.java:442] Failed to queue secure input buffer: CryptoException.ERROR_NO_KEY

Comment 1 by xhw...@chromium.org, May 6 2017

Cc: joeyparrish@chromium.org
I can repro on Linux Chrome M58. It seems we don't have the decryption key:

DecryptingVideoDecoder: no key for key ID 4D4B0CA25AC158F0B9C1983C517EE2B5

Note that this key ID doesn't show up in the log above.

+joeyparrish: Do you know what's special with this video? Is it L1?

Comment 2 by storeytr...@gmail.com, May 7 2017

token
36 bytes View Download

Comment 3 by joeyparrish@chromium.org, May 8 2017 

I believe this has already been fixed in the nightly build:

https://nightly-dot-shaka-player-demo.appspot.com/

The bug was originally filed on github here:

https://github.com/google/shaka-player/issues/761

And fixed in this commit:

https://github.com/google/shaka-player/commit/1f8b88430a97c5a5612d507ce784cf1b30688bbf

We will be releasing this fix in v2.1.1 soon.  Hopefully this week.

Comment 4 by xhw...@chromium.org, May 8 2017 

OOC, how the player is detecting this in the fix? Checking whether HW_SECURE_DECODE is supported?

Comment 5 by joeyparrish@chromium.org, May 8 2017 

No, this has nothing to do with L1 or any particular robustness, at least not directly.

In this case, the server only returns SD & HD keys.  We use key status to determine which streams are playable, so if there are no UHD keys in the license, we should not attempt to play UHD.

The bug was that we did not correctly handle a lack of key status.  Since the UHD keys are not in the license, there is no entry in the key status table for the UHD key IDs.  This should be treated the same as those entries having an unusable status.

If this had been an issue with unenforceable policies (such as HDCP on Linux), the keys would have been present, but unusable, and the bug would not have been triggered.

Comment 6 by xhw...@chromium.org, May 8 2017 

Thanks for the interesting details!

Does this mean we always fetch the license up front, and fetch different streams based on what is playable? Thanks!

Comment 7 by joeyparrish@chromium.org, May 8 2017 

We fetch the license and streams in parallel.  If we know that the streams use different key IDs, we begin with the assumption that the key ID of the lowest-resolution streams will be available in the license.  We restrict ourselves to just those streams until the license is available and we know which keys we have.

This is the only safe approach without foreknowledge of what will be in the license.  More tightly-integrated apps could know this in advance and pull HD or UHD streams if the bandwidth was available and they knew they would have the keys.

Comment 8 by xhw...@chromium.org, May 8 2017 

Thanks!

I'll verify this "bug" after the new shaka player is pushed.

Comment 9 by joeyparrish@chromium.org, May 8 2017 

You can verify already in the nightly build: https://nightly-dot-shaka-player-demo.appspot.com/demo/

Comment 10 by xhw...@chromium.org, May 9 2017

Status: Fixed (was: Assigned)
Cool, just tried it on Mac M58 and it's playing fine.
►

Sign in to add a comment