MSE: Playing encrypted media after unencrypted crashes tab.
Reported by
gsin...@brightcove.com,
Oct 15
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 Steps to reproduce the problem: 1. Run a local server with the example page 2. Try to play the video What is the expected behavior? Video plays through to end What went wrong? Tab crashes when starting to play encrypted content Did this work before? N/A Does this work in other browsers? Yes Chrome version: 69.0.3497.100 Channel: stable OS Version: OS X 10.11.6 Flash Version: When using media source extensions, playing encrypted media after playing unencrypted media will crash the tab. The tab doesn't crash when played in the reverse order (encrypted first, followed by unencrypted). This can also be resolved by pausing the content during the unencrypted portion and resuming after waiting for a bit (though we haven't found a way to deterministically reproduce this workaround). We first noticed this using our player (video.js with VHS for streaming DASH and HLS), and replicated the issue using the Dash.js player. I've included a reduced test case to demonstrate the issue (without the use of a full featured player). If you host the page on a local server, it will show the error. You can reverse the order of the segments to get a working page, by changing the line: const segments = notWorkingSegmentsToAppend; to: const segments = workingSegmentsToAppend; Although using the notWorkingSegmentsToAppend case crashes the tab in Chrome, the same page works when playing back in Firefox. The encrypted content was retrieved from the Shaka Player demo: https://shaka-player-demo.appspot.com/demo/, asset "Angel One (multicodec, multilingual, ClearKey server)," where we downloaded just a couple of video segments and the init segment. The unencrypted content is for the unencrypted variant of that asset "Angel One (multicodec, multilingual). On the example page an offset is included between the two pieces of content. We also tested on Google Chrome Canary Version 71.0.3578.0 (Official Build) canary (64-bit) and there PIPELINE_ERROR_DECODE is thrown in chrome://media-internals/, but the tab doesn't crash. Thank you.
,
Oct 16
As an additional note, we created a question ticket on shaka-player's GitHub page, as we noticed that the shaka-player doesn't exhibit this issue for content that starts with unencrypted and moves to encrypted. The question is posted here: https://github.com/google/shaka-player/issues/1619 In order to circumvent the issue, they create and set media keys in advance of appending any content, even if the starting content is not encrypted. This allows for smooth playback on Chrome, and works for the content in the example page as well.
,
Oct 26
Thanks for filling the issue... Tried to reproduce the issue on reported chrome version 69.0.3497.100 and latest chrome 70.0.3538.77 using Mac 10.14.0. Steps: --------- 0. Launched reported chrome and download given file 1. Ran the local server with the example page 2. Tried to play the video As we have observed blank page and 404 in the terminal as per attached screenshot. @Reporter: Could you please check the attached screen cast and please let us know if anything missed from our end and Could you please upgrade to latest chrome stable 70.0.3538.67, you can download latest chrome builds here:" https://www.chromium.org/getting-involved/dev-channel ". Let us know whether issue still persists. Thanks..!
,
Nov 2
Thanks for the update. I tried using the sample again last week, and briefly saw the 404 message in the terminal, but the page still loaded and played the video, stopping playback at 3 seconds (I was on a newer version of Chrome than the original time when the Chrome tab crashed). I updated Chrome again today and followed the same steps (now on Chrome 70.0.3538.77, Mac 10.11.6), and see the same behavior, the video playing until 3 seconds before stopping. However, I no longer see the 404 message in the terminal.
,
Nov 2
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 9
Thanks for the feedback... As per comment #4, retired the issue on reported chrome 69.0.3497.100 and latest chrome 70.0.3538.77 using Mac 10.14.0 and 10.13.6. Attaching screenshot for reference. Steps: ----- 1. Launched reported chrome and download given file 2. Ran the local server with the example page As we have observed blank page and 404 in the terminal as per attached screenshot. As this issue isn't getting reproduced from our end. hence, adding label "TE-NeedsTriageHelp" and requesting someone from respective team to help in further triaging it. Thanks! |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by viswa.karala@chromium.org
, Oct 15