-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Video will not play if 404 on first fragment #5153
Comments
The logs do not show any attempt made to seek. Please include logs from v1.2.9 that cover the description under "What actually happened?" The player is setup to retry fragment loading. It does and when all attempts fail and there is no other level to switch to, the error is escalated to fatal. You would need to seek before that point. In the latest release, the player may not retry on 4xx errors since most often the result will be the same. The HLS spec recommends a GAP tag for segments that should not be loaded. With support for GAP tags the player would attempt a switch or jump gaps. |
Sorry, the first log I tried to attach exceeded the character limit, so it wouldn't let me post it, so I reloaded the page and copied the fresh log. I'll see if I can post another log showing attempts to seek after work. The player is set to try to recover from media errors, even fatal ones. This works when the failed segment is in the middle of the playlist, but when it's the first segment, it never tries to load any other segments. The |
There's no in-player recovery from fatal errors. You can instantiate a new player instance and reload the stream - maybe with a new
If the segment 404s it is not available. Ideally you would not publish segments in the playlist that are not available. A GAP tag is a way to tell clients not to load something that you know is incomplete or unavailable. Each GAP tag only applies to one segment. |
Please do so with the latest version. Including seek attempts and all logs up to fatal error or end will help us see what is actually happening, where there are bugs, and where we could make improvements.
The gap controller can skip up to 2 seconds to begin playback if media is buffered. It will not skip large gaps if playback hasn't started and playback cannot start if the first segment cannot be loaded. |
Technically, it's not the player, but the demo page does have logic to try to recover from certain "fatal" errors. I'll have to try the startPosition setting. That sounds like it should do the trick.
That's what I thought. I understand that obviously if I KNOW the segment isn't available, I shouldn't be telling clients to use it, but unfortunately things can get messed up, and I want the client to be able to handle basic errors like this as gracefully as possible.
If I'm understanding you correctly, it sounds like the behavior I'm seeing is intentional. The gap controller intentionally limits the initial gap to 2 seconds, while allowing longer gaps in the middle of playback. So if my 10 second initial segment is missing, the player deliberately refuses to skip the gap, whereas it would skip the gap if it occurred in the middle of the stream? Why does it enforce this restriction? |
Edited description with new log, where I tried to seek, as well as hit the "Recover media-error" button a few times. |
Setting |
Thanks for the logs. The player is retrying up to hls.js/src/controller/base-stream-controller.ts Line 1350 in 5265365
I can reproduce and finally get the fatal error after the last attempt fails (by network blocking the first segment in a single variant playlist, I get all the same logs up to this point and then a final fatal error that stops the player):
This is expected. To handle the loading error quickly and shift loading to a new time, use
HLS.js ignores |
I've discovered that I actually need to set both |
Let me know if #6171 resolves the issue for you. I think the option of skipping segments that fail to reload should be behind a config option. See the PR description and please provide feedback. |
#6171 seems to fix the issue. The video player now has the correct length and allows to play the segments that are present. I agree that the auto-skipping should be a config option, as that will be desirable for some use cases but not all of them. |
What version of Hls.js are you using?
master
What browser (including version) are you using?
Firefox 108.0.1 and Chromium 108.0.5359.124
What OS (including version) are you using?
Manjaro
Test stream
No response
Configuration
Additional player setup steps
Sorry for the lack of test stream; I'm seeing this on some surveillance footage of my house, which I don't really want to make externally accessible. I tried to find a test stream that uses separate TS files for each segment, but couldn't find any. If anyone knows of one, you should be able to just edit the first entry of the manifest to have an incorrect filename so it gives a 404, and then this error should pop up.
I also can't actually test it with the regular netlify-hosted demos, because my stream is only served over HTTP, not HTTPS, and even with CORS, the browser doesn't allow accessing HTTP content from an HTTPS page. But I checked out both
master
and1.2.9
and ran the demo app locally over HTTP, and verified the behavior is the same.The stream was created with this command:
ffmpeg -loglevel warning -rtsp_transport tcp -i rtsp://MY_CAMERA:554/ -strftime 1 -c copy -flags +cgop -g 30 -hls_time 10 -hls_list_size 60480 -hls_flags append_list+delete_segments /var/recordings/1/1/combined.m3u8
Checklist
Steps to reproduce
Expected behaviour
Player should play the first working segment, or at least allow to seek to a working segment. This is how it works if the missing segment is in the MIDDLE of the playlist, but not when it's the first segment.
What actually happened?
Player will not play anything at all. On Firefox, it shows the video as being 0 seconds. Chromium shows the correct time, and allows to TRY to seek, but no matter where you seek to, it won't play.
Console output
Chrome media internals output
No response
The text was updated successfully, but these errors were encountered: