Bug in video stream playback on Mac & Windows |
|||||||
Issue description
Chrome Version : 60.0.3112.90
OS Version: OS X 10.12.6 and MS Windows 10
URLs (if applicable) : (none)
Other browsers tested: IE 11 and Edge on Windows 10; Safari and Firefox on macOS
Add OK or FAIL after other browsers where you have tested this issue:
Safari 10.1.1: OK
Firefox 55.0.2: OK
IE 11: OK
Edge: OK
1. Go to one of the online video players that use HLS.js to play HLS streams. Tested were:
http://players.akamai.com/hls/
http://streambox.fr/mse/hls.js-0.7.11/demo/
http://demo.jwplayer.com/developer-tools/http-stream-tester/
2. Enter the URL http://acdn-vs.thuuz.com/2mina.m3u8 as the stream to play. If it doesn't start playing automatically, start it manually quickly. (A delay may cause it not to occur.)
3. Observe that about 3 seconds into play, the video pauses for 0.5 to 1.5 seconds then resumes. Each attempt can have slightly different results, and on occasion it doesn't happen at all.
What is the expected result? Video to play smoothly.
What happens instead of that? Video "hiccups" (pauses briefly) a few seconds into it. In some streams it does it more than once.
Additional details:
It is helpful to have DevTools open and in the Console so you can see HLS.js struggling at the point it pauses. (Two of the players above have HLS.js's debug output enabled.)
This issue only happens if browser caching is enabled. If you disable it in DevTools the video plays smoothly every time.
Under Windows 10, the issue never occurs in IE 11 or Edge but it *sometimes* does in Chrome (more rarely than under Mac).
The issue could be strictly in HLS.js's implementation under Chrome, but it is interesting / relevant that it only happens if Chrome's caching is enabled.
The issue does not happen every single time, but on macOS it is >50%. Timing in starting playback can affect the outcome. If HLS.js has time to pre-fetch some segments and get past the trouble spot before playback begins, the hiccup will not occur.
,
Sep 27 2017
,
Sep 29 2017
,
Oct 3 2017
,
Oct 4 2017
Will take a look. I'd guess there a gap in the buffered timeline somehow. Does this play fine in normal HLS players? I.e., Safari, Android?
,
Oct 4 2017
OIC you indicate it doesn't happen elsewhere.
,
Oct 4 2017
,
Oct 17 2017
Not able to repro any issues with HLS.js nightly on Windows or Linux with Canary: http://storage.googleapis.com/dalecurtis/shaka/hls.html?src=http://acdn-vs.thuuz.com/2mina.m3u8 Will test on OSX tomorrow. dwebb@ are you still seeing this?
,
Oct 17 2017
I still see the problem on Chrome/Mac using the players.akamai.com and streambox.fr sites. Is there a new version of Chrome you'd like me to test? I'm using version 61.0.3163.100.
,
Oct 17 2017
Well, if there's an issue with those JS sites and not my link in c#8, there's probably not much we can do there. The streambox one is particularly old and I have no idea about the akamai one. If you can reproduce with the link in c#8 that'd be more interesting since it's a fully up to date HLS.js instance.
,
Oct 17 2017
61 is fine if it doesn't repro, if it does it's worth checking Chrome Canary to see if you can reproduce the issue.
,
Oct 18 2017
I'm not able to repro the problem with your link in c#8. Looks smooth every time, and I'm tried it about a dozen times.
,
Oct 18 2017
Okay, going to mark this as WontFix then. Presumably it was an HLS.js bug. Feel free to reopen if you see it again. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by shrike@chromium.org
, Sep 15 2017