video.currentTime freezes when no data is available for MediaSource starting with Chrome 52
Reported by
a.ne...@atlas.cz,
Jun 8 2016
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Use MSE to render live data in a video element (use a MediaSource object and addSourceBuffer method). 2. Stop the live stream for some time (20 seconds for example) - this emulates a live source not beeing able to produce data for a moment. 3. Continue live streaming with *correct* (i.e. live) timestamps. What is the expected behavior? The current stable release (51) continues to advance the currentTime property, so after the live source has some data again, video rendering is resumed normally, everythins works very well. What went wrong? Starting from the beta channel (52) (also confirmed for development and Canary channel), the currentTime property freezes in this case. So when new live data arrives, it is not rendered, and video element has to wait (because currentTime has not been advancing with the live source). Did this work before? Yes It works fine in 51 (stable release). Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? N/A Chrome version: 52 Channel: beta OS Version: 7 Flash Version: As this is a big breaking change in the behaviour of Video element and MSE in Chrome (from 51 to 52), is there a chance to have the previous behaviour restored?
,
Jun 9 2016
Hi msrchandra, thanks for your comment. Did you read the bug description? This bug (or at least a big breaking change from 51 to 52) happens when you render *live* data with MSE and there is a moment when data is unavailable during live streaming. So it is not that simple as providing an URL. On the other hand, it is not hard to reproduce: while rendering live data, the live source must be made unavailable for a moment (see my original description). Alex
,
Jun 10 2016
Thank you for providing more feedback. Adding requester "msrchandra@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 10 2016
,
Jun 16 2016
Just ran across this while looking into MSE issues and figure it might be worth cross posting to this issue - https://bugs.chromium.org/p/chromium/issues/detail?id=607295 - Not entirely sure they are related, but it may provide some breadcrumbs.
,
Jun 29 2016
a.nemec@atlas.cz, I tried with MSE streaming site(e.g shaka-player-demo.appspot.com, load Asset: Car, OR any YouTube sites), while video is playing, I unplugged network cable, wait for some seconds, then re-plug network cable. The live streaming not resume (after use up all buffered content). I think this is controlled by live stream site. There is no behavior difference in Chrome 51 or Chrome 52. Please provide the live stream site that you use so we can keep investigate. thanks
,
Jul 20 2016
no response for >3 weeks. close this bug.
,
Jul 21 2016
Ok, fortunately we could adapt our html 5 app to work around this breaking change. I tried to explain the breaking change as good as I can, but all the replies show, that nobody was able to understand it. (Note to yini..@chromium.org): Please re-read the original description if you are interested. This behaviour takes place when the live source does not have any data available for sending for some time and resumes sending afterwards WITHOUT the connection being closed. This happens for example, when you stream through a proxy etc. So disconnecting cables when you access youtube video directly is not the way you can reproduce ;). Alex |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by msrchandra@chromium.org
, Jun 9 2016Labels: Needs-Feedback