Stream crashing with frequently changing error messaging

[matt-iakhno]

Description

Various different errors from live m3u8 stream, all resulting in player crashing. The same behavior is happening in Chrome, Firefox and Edge.

Link to "reduced test case" to reproduce issue: https://videojs-http-streaming.netlify.app/?debug=true&autoplay=false&muted=false&minified=false&liveui=false&partial=false&url=https%3A%2F%2Fe3e2p5m2.ssl.hwcdn.net%2Fhls%2Fmain.m3u8&type=application%2Fx-mpegurl&keysystems=&buffer-water=false&override-native=true

Unfortunately the segment/time the crash happens at is random - sometimes it takes 5 minutes, sometimes I've seen it take as long as 45 minutes or so. But eventually it will crash. When it crashes, I've seen the following errors in console (again with no particular rhyme or reason as to when one shows up, and which one it is):

1. VIDEOJS: ERROR: (CODE:3 MEDIA_ERR_DECODE) The media playback was aborted due to a corruption problem or because the media used features your browser did not support.

2. video append of 2910574b failed for segment Make Webpack work without issue #4 in playlist 0-/cl/b6f7cafc-da87-41d1-b4ab-fe680b45265d/1920x1080_5483509_0.m3u8

3. VIDEOJS: WARN: Problem encountered with playlist 4-/hls/720phi/playlist.m3u8. Only audio found in segment when we expected video. We can't switch to audio only from a stream that had video. To get rid of this message, please add codec information to the manifest. Switching to playlist 5-/hls/720plo/playlist.m3u8

4. VIDEOJS: WARN: Problem encountered with playlist 1-/hls/144p/playlist.m3u8. Excessive main segment downloading detected. Switching to playlist 5-/hls/720plo/playlist.m3u8

5. VIDEOJS: WARN: Prroblem encountered with playlist 5-/hls/720plo/playlist.m3u8. Aborted early because there isn't enough bandwidth to complete the request without rebuffering. Switching to playlist 2-/hls/360p/playlist.m3u8

Sources

Source stream - https://e3e2p5m2.ssl.hwcdn.net/hls/main.m3u8

Steps to reproduce

1. Open the reduced test case in a browser tab.
2. Leave it open for up to an hour, visiting occasionally to see if the stream crashed.

Results

Expected

The HLS seems to be well constructed. Each bandwidth segment has CODECS defined ("avc1.4D0028,mp4a.40.2"), values for BANDWIDTH and AVERAGE-BANDWIDTH, resolution & framerate. The expected result is that the stream continues to play.

I tried testing this stream in a couple of other commercial players (namely JW Player & Kaltura) and did not experience any issues. We have also tested this playout on Android, iOS & Apple TV and it's playing everywhere with no crashing.

Error output

Described above.

videojs-http-streaming version

Whatever version https://videojs-http-streaming.netlify.app/ is using

videojs version

Whatever version https://videojs-http-streaming.netlify.app/ is using

Browsers

Chrome Version 87.0.4280.88

Platforms

Windows

Other Plugins

Whatever version https://videojs-http-streaming.netlify.app/ is using

Other JavaScript

Whatever version https://videojs-http-streaming.netlify.app/ is using

[liyeting121]

I have the same problem in chrome 60

[rfunduk]

This seems to be resulting in a playback failure rate of about 10% for us via Mux 😢 Affects pretty much all platforms/browsers.

Can this issue be acknowledged at least? Is more information needed?

[gkatsev]

I've now run the stream linked above for over an hour and haven't seen the issue on https://videojs-http-streaming.netlify.app/. I believe that it may have been fixed via videojs/mux.js#378.

[gkatsev]

Now at two hours. I think I'm going to call this as fixed. I believe the fix is available in the current latest of Video.js, v7.11.8, but it's definitely in Video.js 7.12.1, which is currently in pre-release.