MPEG DASH assset is not getting an Ended Event from the browser when using chrome, native ended event is occurring in other browsers
Reported by
amsclien...@gmail.com,
Nov 30 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36 Example URL: manifest: https://gdwproductionmedia.streaming.mediaservices.windows.net/b29d4f2f-3682-4124-8340-92b1cc4ee4a9/c1271606-cbf9-4d06-8a7c-ab9c27f5a258.ism/manifest(format=mpd-time-csf) Steps to reproduce the problem: 1. Navigate to DASH JS client demo page in chrome http://dashif.org/reference/players/javascript/v2.3.0/samples/dash-if-reference-player/index.html 2. load the following manifest: https://gdwproductionmedia.streaming.mediaservices.windows.net/b29d4f2f-3682-4124-8340-92b1cc4ee4a9/c1271606-cbf9-4d06-8a7c-ab9c27f5a258.ism/manifest(format=mpd-time-csf) 3. seek to the end (or watch the entire video), ended event does not get triggered, the event is triggered in Edge/IE et cetera 4. you can see the events by opening the JavaScript Console (all the events are getting written to the console by default) What is the expected behavior? Ended event should be triggered What went wrong? No ended event, this is bad for users who are trying to implement some kind of logic at the end of a video because the ended event is never occurring. Did this work before? N/A Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? Yes Chrome version: 54.0.2840.99 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 23.0 r0 You can repro this using other Dash players as well, I just used DASH JS as an example
,
Nov 30 2016
,
Dec 2 2016
Able to reproduce the issue on Win 10,Mac 10.11.6 and Ubuntu 14.04 using stable 54.0.2840.98/99/100 and on latest canary 57.0.2938.0. This is a non-regression issue seen from 35.0.1916.0. Note: Firefox and Edge are working fine.
,
Dec 2 2016
Chris, please take a look at this. It sounds similar to other 'ended' event bugs already in your arena. Without looking myself, I'm uncertain if this is MSE specific or more general at the moment, so leaving the labels as-is.
,
Dec 13 2016
Found the root cause. We are generating "ended" signal internally, and this causes us to set currentTime = duration. https://cs.chromium.org/chromium/src/media/blink/webmediaplayer_impl.cc?rcl=0&l=718 The problem is currentTime is set to a duration slightly off from what's returned by MSE demuxer. We expect that duration should match everywhere (MSE demuxer updates pipeline when things change), BUT, in the case of user-specified-durations, MSE returns the double the user specified rather than returning the less precise time from TimeDelta::InSecondsF(). https://cs.chromium.org/chromium/src/media/filters/chunk_demuxer.cc?rcl=0&l=879 In this case, currentTime = 1049.407999, while duration = 1049.4079999999999. I'll have a fix out shortly.
,
Dec 16 2016
out of curiosity, how is this a user-specified-duration? Are you referring to the duration calculated by the player based on the DASH manifest?
,
Dec 16 2016
I don't know the dash.js code, but somewhere they're setting MediaSource.duration = 1049.4079999999999. I assume this comes from the dash manifest? Either way, they're fine to do that. The bug is Chrome.
,
Jan 10 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b92d50681a244d9cf988ea32fcdb6ea7cd096be2 commit b92d50681a244d9cf988ea32fcdb6ea7cd096be2 Author: chcunningham <chcunningham@chromium.org> Date: Tue Jan 10 21:50:22 2017 MSE: Fix logic bugs with high precision duration Upon end of stream, chunk demuxer should decrease the duration to match the highest buffered end time. This was not happening for user-set durations which exceeded the highest buffered end time by less than a microsecond. Additionally, some style refactoring. For MSE, we pull duration directly from the demuxer, which stores the user set value with full precision. Moving this logic to WMPI from HTMLMediaElement ensures duration WMPI uses matches that of HTMLMediaElement. TEST=New layout test and manual testing of bug report steps BUG= 669997 Review-Url: https://codereview.chromium.org/2581533002 Cr-Commit-Position: refs/heads/master@{#442699} [modify] https://crrev.com/b92d50681a244d9cf988ea32fcdb6ea7cd096be2/media/blink/webmediaplayer_impl.cc [modify] https://crrev.com/b92d50681a244d9cf988ea32fcdb6ea7cd096be2/media/filters/chunk_demuxer.cc [add] https://crrev.com/b92d50681a244d9cf988ea32fcdb6ea7cd096be2/third_party/WebKit/LayoutTests/http/tests/media/media-source/mediasource-precise-duration.html [modify] https://crrev.com/b92d50681a244d9cf988ea32fcdb6ea7cd096be2/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp [modify] https://crrev.com/b92d50681a244d9cf988ea32fcdb6ea7cd096be2/third_party/WebKit/Source/core/html/shadow/MediaControlsOrientationLockDelegateTest.cpp
,
Jan 10 2017
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ligim...@chromium.org
, Nov 30 2016