videojs
After changing from an HLS "live" source to an HLS "VOD" source, the player seeks before the first play
Description
When a Video.js player is created and the source is set to an HLS "Live" m3u8 playlist (i.e.
one without a #EXT-X-ENDLIST statement), then changed to a HLS "VOD" m3u8 playlist, and
then played, the player seeks to 0 and then plays.
Sources
- HLS Live m3u8 playlist: https://playertest.longtailvideo.com/adaptive/wowzaid3/playlist.m3u8
- HLS VOD m3u8 playlist: https://devstreaming-cdn.apple.com/videos/streaming/examples/bipbop_4x3/bipbop_4x3_variant.m3u8
Steps to reproduce
- Open this reduced test case in Chrome for desktop: https://codepen.io/mluedke/pen/GBMLVb
- Open devtools and switch to the "console" tab.
- Click the "Change to VOD Stream" button (before clicking play or doing anything with the player).
- Click play.
- Observe that there is a logging statement in the console that says "seeked 0" that indicates that a seek happened. There may also be short stutter in the video while the player seeks.
Results
The player seeks on first play rather than just playing.
Expected
I expect that the player will just play at the 0 position without trying to seek at all.
Error output
No error output, just an erroneous seek.
Additional Information
Stepping through the source code with a debugger shows that the seek is caused by a leftover event listener that's registered when the player's source changes.
When the first source is set using the live stream source URL, an instance of
MasterPlaylistController is created, and an event listener is registered with the
player for the canplay event. Then, when the source is changed again after clicking the
"Change to VOD Stream" button (in the reduced test case provided above), another instance of
MasterPlaylistController is created, but the old instance, the one associated with the "live"
stream source, still remains. Therefore, when you click "play" and the canplay event fires, the
setupFirstPlay function runs with the old MasterPlaylistController and it attempts to "seek to
the live point", meaning it tries to seek to the end of the seekable range, which in this instance
happens to be 0.
Additionally, in a non-public project in which I am using Video.js and HLS streams, for
some reason (possibly the playlist I'm using?) the player returns an actual non-zero value
for that seekable.end(0) value so that after pressing play, the player skips to the end
of the video (because the seekable "end" value is greater than the duration of the VOD
video), which is even worse than what's demonstrated here where it least begins playing
at 0. Unfortunately, I couldn't find a public HLS stream that replicates this.
videojs-contrib-hls version
Occurs with videojs-contrib-hls 1.2.1
videojs version
video.js 7.2.0
Browsers
- This was specifically tested on Chrome Version 67.0.3396.99 (Official Build) (64-bit), but since this is a logical issue in the code, it's likely occurring on other browsers (but could not reproduce in Safari).
Platforms
- macOS 10.13.4
Other Plugins
None
Other JavaScript
None
