[Bug][HLS] Player stucks after loading few chunks and doesn't download next

[wgorczyca]

Description

Video.js player stucks after loading few chunks and doesn't download next. For streaming I use wowza, same stream works fine on other players like plyr or flowplayer.

Sources

https://s1.aztv.pl/demo/demo.stream/playlist.m3u8

Steps to reproduce

Here is a codepen example presenting this issue codepen link. Issue doesn't occur for every stream from wowza, only for specific one like this from example.

Results

Expected

Stream played by videojs

Actual

Stream stucked, spinner spins

Error output

None

Additional Information

videojs-http-streaming version

videojs-http-streaming 1.10.6

videojs version

video.js 7.6.5

Browsers

Chrome Version 77.0.3865.90, Firefox Version 69.0.1

Platforms

Ubuntu 19.04, macOS 10.14.6(Mojave)

Other Plugins

None

Other JavaScript

None

[welcome]

👋 Thanks for opening your first issue here! 👋

If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.
To help make it easier for us to investigate your issue, please follow the contributing guidelines.

[mjneil]

@wgorczyca It looks like your audio and video timestamps are out of sync within the segments.

As the player downloads and appends, this is how the audio and video buffers look:

1: audio start 24.162 audio end 34.146 video start 0 video end 9.96
2: audio start 24.162 audio end 44.13 video start 0 video end 19.96
3: audio start 24.162 audio end 54.114 video start 0 video end 29.96
....

As you can see, the audio contained within a segment is at 20s into the future compared to the video. Its impossible to play just a single segment cause you either don't have the video or audio to match its counterpart.

[wgorczyca]

@mjneil Thanks you so much for investigation, I will try to contact wowza team because after what you've said it seems like wowza issue.

I'm wondering why it works on Chrome/Android and Safari/macOS & iOS. Is it because they support HLS natively?

One more thing that bothers me is how other players (ex. plyr, flowplayer) handle that scenario, because they are able to play this stream. Do you have any idea? Do you plan to support this edge case in this library?

[mjneil]

I'm wondering why it works on Chrome/Android and Safari/macOS & iOS. Is it because they support HLS natively?

Correct, both those platforms support native HLS playback.

One more thing that bothers me is how other players (ex. plyr, flowplayer) handle that scenario, because they are able to play this stream. Do you have any idea?

I'm not sure how other players are implemented, but their implementation must just handle this edge case better. I'd argue their ability to "play" the stream is better than ours, but not ideal. ~30s to start due to difference in audio and video, frequent stalling and skipping content.

Do you plan to support this edge case in this library?
Unless you or someone else decides to try and take it on themselves, I don't see this making the roadmap any time soon as it seems like it would be pretty significant work to provide a sub-par experience for a small edge case. I would recommend fixing things at the encoder level.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.