Skip to content
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

Auto-played demuxed stream fails to play and infinitely stalls #1084

Closed
evanfarina opened this issue Mar 1, 2021 · 1 comment · Fixed by #1085
Closed

Auto-played demuxed stream fails to play and infinitely stalls #1084

evanfarina opened this issue Mar 1, 2021 · 1 comment · Fixed by #1085

Comments

@evanfarina
Copy link
Contributor

Description

The stream in question contains demuxed audio and video streams and there is a small timeline difference of around 1 second between the audio and video streams (see attached screenshot). The stream fails to play with auto-play enabled but plays correctly when auto-play is disabled and the stream is started by user interaction. See this demo to reproduce the issue.

Sources

https://livectorprodmedia12-usea.licdn.com/0c13be2a-1820-4837-8318-29b9e6187219/L4D5ded7c97c980f000-livemanifest.ism/manifest(format=m3u8-aapl)

Steps to reproduce

Explain in detail the exact steps necessary to reproduce the issue.

  1. Visit the http-streaming demo page
  2. Enter the source: https://livectorprodmedia12-usea.licdn.com/0c13be2a-1820-4837-8318-29b9e6187219/L4D5ded7c97c980f000-livemanifest.ism/manifest(format=m3u8-aapl)
  3. Check the AutoPlay checkbox
  4. Click the "load" button to load the source with the above settings

Results

Expected

The stream should play like any other demuxed stream.

Error output

No error output, no failed network requests, nothing obvious found in verbose video.js log output

Additional Information

I've spent some time digging into this myself and have the below notes. I believe the issue is a race condition, though I haven't gotten to the bottom of the issue yet.

Call stack from AutoPlay case:

  1. setupMasterPlaylistLoaderListeners_ is called
  2. setupFirstPlay is called
  3. MasterPlaylistController.load() called
  4. mainSegmentLoader_.load() is called, and succeeds
  5. audioSegmentLoader_.load() is called, but returns early because this.playlist is undefined (due to race condition, though I don't believe this is an issue as working demuxed follow this same path)
  6. race media-groups.AUDIO.loadedplaylist event is handled, audio playlist is setup
  7. race media-groups.AUDIO.loadedmetadata event is handled, audio playlist is setup

In the manual-play case, #6 and #7 happen before #3 and therefore the playlist plays. NOTE - Working demuxed sources follow the same path as the above and play fine. There is something happening after #6 and #7 that allows other sources to play, but I haven't figured out what that 'something' is yet.

videojs-http-streaming version

Latest in repo

image

@gesinger
Copy link
Contributor

gesinger commented Mar 1, 2021

Thank you for the detailed issue and source @evanfarina !

Why not using autoplay still plays the video

Our gap skipper is skipping the gap. From the debug logs:

VIDEOJS: DEBUG: VHS: PlaybackWatcher > skipTheGap_: currentTime: 0 scheduled currentTime: 0 nextRange start: 1.147888

This is because the playback-watcher sees a waiting event from the tech (from the video element) after there's buffered contents (since it's unlikely a user hits play before some of the content is buffered).

Why using autoplay doesn't play the video

The waiting event happens too quickly, before any content is buffered, so playback-watcher has no gap to skip.

What we can probably do

Although it would be best for the content not to have a gap at the start, playback-watcher should be able to handle this scenario. Right now, the playback monitoring only starts on canplay:

const canPlayHandler = () => this.monitorCurrentTime_();

This should probably start monitoring on play as well. I added that listener and it fixed the autoplay behavior.

We should do a bit more testing and thinking, but this, or something like it, is probably the approach we'll take.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants