-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chrome PTS bug - Playback never starts with FF 46 and Edge #377
Comments
Thanks for the report. We'll take a look. |
I tested this stream in some other browsers and MPEG-DASH players. It looks like there is likely a problem with the manifest and maybe bugs in Firefox and/or Shaka.
@jyavenard: Here is my about:media from Firefox Nightly 48. Why might Firefox fail to play this stream in Shaka but succeed in DASH.js and Bitdash when Edge and IE11 fail everywhere?
|
The first segment has a baseMediaDecodeTime of 0 seconds, but the first sample There appears to be a bug in Chrome which causes buffered ranges to use DTS instead of PTS (see #338 and see https://bugs.chromium.org/p/chromium/issues/detail?id=398130). And, in addition to this, the manifest specifies that the first segment starts at t=0 when it should specify that it starts at t=0.2. So, this content works on Chrome because the two issues cancel each other out. Chrome should report buffered ranges using PTS (see https://www.w3.org/TR/media-source/#track-buffers), and DASH manifests should specify segment start times using PTS too. |
That video stream has a gap of 200ms at the start. Firefox only skip over gaps that are less than 150ms. The buffered range starts at 0.2s. Dash.js will seek to the video.buffered.start(0) and playback will start. I guess Shaka doesn't. It probably should |
Shaka will jump the initial gap in the buffer if that gap is specified in the manifest, i.e., if the manifest specifies that the first segment starts at t=0.2, Shaka will start playback at t=0.2. However, Shaka does not jump any unexpected gaps in the buffer (by way of inspecting video.buffered post appendBuffer). We'd like to avoid doing this... but we may need to in order to work around these DTS/PTS issues and to handle actual missing segments (see #180). |
I've seen so many invalid manifests and incorrectly muxed data (which typically do not start at time=0) that it would be rather crazy to always trust the manifest. As chrome incorrectly reports the buffered range using the dts (and those always start at 0 by definition) all videos appear to have a buffered range starting at 0, it probably means that with shaka it's fine for now. When that bug is fixed, problems will start. It's been beyond frustrating to have received countless bug reports that a stream works with chrome but not firefox, when chome is doing the wrong thing. Similar with unexpected gap in the data. |
Does this still repro in Edge 16 (or 17 preview)? |
Tested on Edge17 preview, The video link that @FedeOmoto has reported works with no issues. More tests on Edge 17 preview: ✅ Shaka: works and tested, supports 4K! here. ✅ Dash.js: works and tested here. ✅ Bitdash: works and tested here. Only problem would be if you have unsupported encryption which is unrelated to the library. I think it is safe to close this issue! |
I believe the Chrome DTS/PTS bug has now been fixed, so I'm closing this bug. If you still have issues with the latest stable release of Chrome, please file a new issue. Thanks! |
Hi!
Using Shaka Player v2.0.0-beta2, this stream never starts: http://wzstrm.arnet.com.ar:1935/investorsvod/earnings_release_1q16.mp4/manifest.mpd
In both FF and Edge, we see that it downloads a lot of video chunks until it stops loading.
It works OK with Chrome.
The text was updated successfully, but these errors were encountered: