Decryption of audio track fails if it is marked as using subsample encryption (Widevine/EME/MSE)
Reported by
san...@saares.eu,
Sep 2 2016
|
|||||||
Issue descriptionIf an audio segment fed to Chrome via MSE defines subsample encryption in the Sample Encryption box, decryption of the samples will fail. I provide below test content in DASH format and two players that can be used for playback. The issue seems to reproduce reliably with both players, so I am confident in calling this a Chrome, rather than player, issue. The players linked below are pre-configured with all relevant data for DRM, just hit the Load button. The GitHub page linked below contains more info for manual repro with other players. Chrome Version : 52.0.2743.116 (Official Build) m (32-bit) URLs (if applicable) : http://axinom-dash-v7.axtest.net/ OS version : Windows 10 build 1607 Audio/Video format (if applicable): DASH containing H264/H265/HE-AACv2. More info at https://github.com/Axinom/dash-test-vectors Behavior in Safari (if known): unknown Behavior in Firefox (if known): equivalent Behavior in Edge (if known): problem does not exist in Edge (although Edge has other problems with this data) Video issue, Audio issue, both, neither? Only audio - video track subsample decryption succeeds fine. Flash or HTML5? HTML5 (MSE/EME) What steps will reproduce the problem? (1) Go to http://axinom-dash-v7.axtest.net/ (2) Pick any of the two players linked (provided for comparison - issue repros with both) (3) From the dropdown menu, select either "Multi-DRM" (in Shaka player) or "v7 encrypted single-key (1080p)" (in dash.js player). (4) Hit Load. What is the expected result? Video and audio playback starts. What is the actual result? Playback fails to start. Dash.js outputs: [73718] Video Element Error: MEDIA_ERR_DECODE Shaka player outputs: InvalidStateError: Failed to execute 'appendBuffer' on 'SourceBuffer': The HTMLMediaElement.error attribute is not null. Any additional information (anything else which may help us debug the issue)? The audio samples are not actually subsample-encrypted in the sense that the clear portion of samples is 0 bytes long. The subsample encryption data is a no-op (the tooling always includes the subsample data, even if zero clear bytes are used in samples). This is in conformance with the Common Encryption specification. See link in above repro instructions for two players preconfigured to play this content; media files available over internet and also downloadable as archives from linked GitHub page; instructions for configuring license acquisition parameters (for testing with other players) are also found in linked GitHub page.
,
Sep 6 2016
KQ, PTAL.
,
Sep 7 2016
,
Sep 8 2016
I tried playing the content using dash-if player but it played successfully. sander@ can you confirm that it is not working for you? What is the failure symptom? It fails in Shaka player because the mp4 parser sees saio.offsets[0] as 609 (0x261) while the correct value should be 1481 (0x5c9). I checked the source content 0001.m4s and the value (byte offset 359) in the file is correct. It looks like the player modifies/corrupts the value (I dumped out the bytes in bool WebSourceBufferImpl::append where the data is already corrupted). There is a separate issue here: when 'senc' box is present, the current Chromium code still reads 'saio' box to get sample encryption data offset, which is unnecessary. I'll update Chromium code to fix this.
,
Sep 8 2016
Filed a separate bug for the Chromium issue at https://bugs.chromium.org/p/chromium/issues/detail?id=645283. Reassigned to joeyparrish@ to investigate the player issue.
,
Sep 9 2016
I do indeed see failure to play back with the DASH-IF player, as well. Details follow. dash.js on Chrome 53: * I select "v7 encrypted single-key (1080p)" and hitting Load. * Playback does not start; below items in log. Debug.js:108 [26494] Video Element Error: MEDIA_ERR_DECODE Debug.js:108 [26494] [object MediaError] Debug.js:108 [26498] Schedule controller stopping for video Debug.js:108 [26499] Schedule controller stopping for audio Debug.js:108 [26500] Schedule controller stopping for fragmentedText Debug.js:108 [26501] Native video element event: pause Debug.js:108 [26539] DRM: Session created. SessionID = 0777B839F97B2876F9DF1523F84C9BA0 * I note that a Widevine license is acquired by the player but only on the first load after opening the tab; after refreshing the page and retrying, no license acquisition occurs (existing one reused, presumably?). Seems odd to me but more of a symptom than a cause. Behavior with Chrome Canary (v55) is equivalent. I no longer see any license requests take place, though. Behavior with dash.js nightly build (http://mediapm.edgesuite.net/dash/public/nightly/samples/dash-if-reference-player/index.html) is equivalent. I no longer see any license requests take place, though. Sounds like the license requests taking place or not might be some data race in the player? Probably irrelevant to the failure to actually achieve playback. I was not able to play back this video using dash.js and Chrome in any situation.
,
Sep 9 2016
Ooops, I was looking at the wrong stream/file... You are right that both dash.js and shaka player do not work. There is a problem in the media file: 15/0001.m4s In saiz box, it indicates that the sample info size is 10 bytes, but it is actually 8 bytes. This is causing the media parser to fail. It will play successfully if the sample info size is correctly indicated in saiz box. sander@, please fix the content.
,
Sep 9 2016
,
Sep 12 2016
Thank you for tracking down the issue! I confirm your findings - the saiz value appears to be incorrect, indeed. I have reported this to the tooling vendor at https://github.com/gpac/gpac/issues/633 After correcting the saiz value, the content appears to play successfully in Chrome. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by joeyparrish@chromium.org
, Sep 6 2016