videojs / video.js

Video.js - open source HTML5 video player
https://videojs.com
Other
38k stars 7.45k forks source link

HLS streamming stops with corruption in safari with short playlists #8041

Closed strbass28 closed 1 year ago

strbass28 commented 1 year ago

Description

I'm generating a playlist in real time that is being requested by video-js immediately after generation has started. When video-js does it's first request there is always at least a single m4s segment in the playlist. Most of the time there is just one.

In both mobile and desktop safari the behavior looks to be to play the single segment and then to report "The media playback was aborted due to a corruption problem or because the media used features your browser did not support." . This is different then chrome, firefox, and edge where it continues to request forever with playback continuing smoothly when more segments are added to the playlist.

The override method doesn't look to make a difference in safari.

Also, If I load the playlist in safari without video-js I see the same behavior.

My playlist looks as follows when the first request happens,

EXTM3U

EXT-X-VERSION:7

EXT-X-ALLOW-CACHE:NO

EXT-X-TARGETDURATION:2

EXT-X-MEDIA-SEQUENCE:0

EXT-X-PLAYLIST-TYPE:EVENT

EXT-X-DISCONTINUITY

EXT-X-START:TIME-OFFSET=0

EXT-X-INDEPENDENT-SEGMENTS

EXT-X-MAP:URI="init.mp4"

EXTINF:1.879511,

index0.m4s

Network requests look as follows, index.m3u8 request(getting back the contents above) init.mp4 request index0.m4s request(in red, not sure what that means) index0.m4s request with video segment returned, index.m3u8 request(with either same response or more segments added) nothing else.

In that time the video plays for a second or so and then reports a corruption and stops playing.

If the first m3u8 playlist has several segments in it then Safari playback will continue normally.

Here's a playlist with one segment. You can see safari quit and chrome continue trying. I would think continuing is the correct behavior. http://3.86.76.131/video-js/demo2.html

Reduced test case

http://3.86.76.131/video-js/demo2.html

Steps to reproduce

  1. using safari, load a playlist with a single segment 2.See it stop with a corruption message

Errors

No response

What version of Video.js are you using?

7.20.3

Video.js plugins used.

No response

What browser(s) including version(s) does this occur with?

Safari 16.1

What OS(es) and version(s) does this occur with?

OSX,IOS

gkatsev commented 1 year ago

I believe that a single segment playlist is technically not valid HLS. By default, playback is done natively on Safari with HLS, though, you can overrideNative to use the Video.js playback engine.

I would recommend also running your stream through Apple's mediastreamvalidator to see if it notices any issues. If it flags thing, I would recommend fixing things.

strbass28 commented 1 year ago

Not sure where it says a single playlist isn't valid HLS. Started going through the spec and it looks to me like a playlist is just a subset type of a manifest. In anycase, I get the same behavior if I create a manifest that references the playlist.

Apples mediaservervalidator doesn't complain about my stream and continues to try and load it. Here is output stream without the end tag in the m3u6 mediastreamvalidator -V http:///shortVid/index.m3u8 mediastreamvalidator: mediastreamvalidator: Version 1.17 (593.5-220531)

Validate http:///shortVid/index.m3u8, fetch http [/shortVid/index.m3u8] Started root playlist download [/shortVid/index.m3u8] Started media playlist download [/shortVid/index.m3u8] Received media playlist response [/shortVid/index.m3u8] SequenceNum: 0 Size: 847 bytes Duration: 0.0000 sec Bitrate: inf [/shortVid/index.m3u8] SequenceNum: 0 Size: 1049014 bytes Duration: 1.9970 sec Bitrate: 525294.9424 [/shortVid/index.m3u8] All media files delivered, waiting until next playlist fetch [/shortVid/index.m3u8] Received media playlist response [/shortVid/index.m3u8] All media files delivered, waiting until next playlist fetch ...repeats forever.

Where as safari just gives up after the first request.

changing the override to true for safari has no effect. It still makes the mu38 request, gets the init.mp4, gets the first segment, requests the m3u8 playlist again that contains a bunch more index files, but never requests more segments then are in the original m3u8 request.

So is safari just broken? Hopefully i'm just doing something wrong.

video-archivist-bot commented 1 year ago

Hey! We've detected some video files in a comment on this issue. If you'd like to permanently archive these videos and tie them to this project, a maintainer of the project can reply to this issue with the following commands:

gkatsev commented 1 year ago

Not a single playlist, but rather a playlist with a single segment. Since your playlist doesn't have an END-LIST tag it'll keep forever. I believe there's a flag for mediastreamvalidator to wait a few minutes and then validate just that amount.

strbass28 commented 1 year ago

safari and video-js should continue to requesting the playlist like mediaservervalidator does. Instead it requests it twice and stops requesting. To me this looks like a bug that breaks live streaming in safari.

strbass28 commented 1 year ago

Safari doesn't like the #EXT-X-DISCONTINUITY in my m3u8 file. Remove that and safari continues to request when it runs out of segments. Looks like I was wrong to include that. This issue can be closed.