-
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
Hls.js going after old ts segments after Stop/Resume. #6854
Comments
What's the behavior like with changes in #6853? Branch build: https://bugfix-frag-retry-no-alterna.hls-js-4zn.pages.dev/demo/ |
With #6855 hls.js will wait for expired playlists to be refreshed before requesting segments. This should resolve the issue. Please let me know how it works for you: https://bugfix-live-resume-wait-for.hls-js-4zn.pages.dev/demo/ |
@robwalch I tried #6855 and I am seeing the same behavior as #6853 .. it is still going after old ts segments afrer resume. LOGS [log] > loadSource:https://localstreaming.vbrick.com:3443/5b444d9f-dd24-4bc0-977a-faee1983d68e.m3u8?reorderpackets=true hls.mjs:30060 [warn] > [latency-controller]: Stall detected, adjusting target latency [log] > [level-controller]: Loading level index 0 with https://localstreaming.vbrick.com:3443/5b444d9f-dd24-4bc0-977a-faee1983d68e-362p-688kbps.m3u8 [log] > startLoad(-1) [error] > 404 while loading https://localstreaming.vbrick.com:3443/live-streaming/3062706b-ad1d-40d3-aaa8-d44db99418d7/5b444d9f-dd24-4bc0-977a-faee1983d68e/5b444d9f-dd24-4bc0-977a-faee1983d68e-362p-688kbps-0.ts [log] > [stream-controller]: FRAG_LOADING->IDLE [content-steering]: Could not resolve fragLoadError ("HTTP Error 404 Not Found") with content-steering for Pathway: . levels: 1 priorities: ["."] penalized: {".":165028.70000004768} [log] > [stream-controller]: FRAG_LOADING->IDLE hls.mjs:29048 [error] > 404 while loading https://localstreaming.vbrick.com:3443/live-streaming/3062706b-ad1d-40d3-aa…0-977a-faee1983d68e/5b444d9f-dd24-4bc0-977a-faee1983d68e-362p-688kbps-3.ts hls.mjs:29048 [error] > 404 while loading https://localstreaming.vbrick.com:3443/live-streaming/3062706b-ad1d-40d3-aa…0-977a-faee1983d68e/5b444d9f-dd24-4bc0-977a-faee1983d68e-362p-688kbps-5.ts hls.mjs:29048 [error] > 404 while loading https://localstreaming.vbrick.com:3443/5b444d9f-dd24-4bc0-977a-faee1983d68e-362p-688kbps.m3u8 [log] > [level-controller]: Loading level index 0 with https://localstreaming.vbrick.com:3443/5b444d9f-dd24-4bc0-977a-faee1983d68e-362p-688kbps.m3u8 [log] > [level-controller]: Loading level index 0 with https://localstreaming.vbrick.com:3443/5b444d9f-dd24-4bc0-977a-faee1983d68e-362p-688kbps.m3u8 |
The playlist updates in your logs look rather abnormal after restarting the the stream. At the start the playlist grows to 60 seconds in length (so far so good).
But once you restart, besides the fragment 404s (which should be available for for 90 seconds (its length is 60 plus 3x target duration) from the last time is was retrieved, the playlist itself 404s and then when it does update, it contains only one segment, then two with a combined duration of 80 seconds (instead of the expected ~20):
I just pushed some additional changes that will enhance the logs that will help tell why your segments may not be considered stale after these changes: 30c05b3. If you could, please give it another run and share your logs again. Thank you. |
Here is the logs from latest commit. I have also attached HAR file from the network tab. Logs hls.mjs:30064 [warn] > [latency-controller]: Stall detected, adjusting target latency [log] > [stream-controller]: Buffered main sn: 2 of level 0 (frag:[10.000-20.011] > buffer:[0.000-20.000]) [log] > startLoad(-1) hls.mjs:29052 [error] > 404 while loading https://localstreaming.vbrick.com:3443/live-streaming/9e3a83dc-732a-4f70-9f…9-b625-94ff791a7197/3203fab8-c858-4c69-b625-94ff791a7197-362p-688kbps-1.ts hls.mjs:20673 [warn] > [content-steering]: Could not resolve fragLoadError ("HTTP Error 404 Not Found") with content-steering for Pathway: . levels: 1 priorities: ["."] penalized: {".":131434.30000007153} [log] > [stream-controller]: FRAG_LOADING->IDLE [log] > [stream-controller]: FRAG_LOADING->IDLE hls.mjs:29052 [error] > 404 while loading https://localstreaming.vbrick.com:3443/live-streaming/9e3a83dc-732a-4f70-9f…9-b625-94ff791a7197/3203fab8-c858-4c69-b625-94ff791a7197-362p-688kbps-3.ts hls.mjs:20673 [warn] > [content-steering]: Could not resolve fragLoadError ("HTTP Error 404 Not Found") with content-steering for Pathway: . levels: 1 priorities: ["."] penalized: {".":131434.30000007153} hls.mjs:29052 [error] > 404 while loading https://localstreaming.vbrick.com:3443/3203fab8-c858-4c69-b625-94ff791a7197-362p-688kbps.m3u8 hls.mjs:32983 [warn] > [playlist-loader]: A network error (status 404) occurred while loading level: 0 id: 0 hls.mjs:32983 [warn] > [playlist-loader]: A network error (status 404) occurred while loading level: 0 id: 0 [log] > Video: Initial PTS/DTS adjusted: 30000/30000, delta: 50000 ms [log] > [buffer-controller]: changing video sourceBuffer type to video/mp4;codecs=avc1.42c01e hls.mjs:30888 [warn] > [gap-controller]: Playback stalling at @89.943189 due to low buffer ({"len":0.056809999999998695,"start":80.005,"end":89.999999}) |
The segments are 404ing too early. Segments removed from a live HLS playlist should remain available for the duration of the playlist plus the duration of the segment. With #6855 HLS.js will only ignore segments in the playlist if it was loaded more than the total duration plus three target durations (so ~60 seconds in this case). The last response was only 34.7 seconds ago ("age") so the segments should still be available:
|
Made one more update to reduce the expected availability to playlist duration + target duration (from duration + 3 target durations): e9fd578 |
@robwalch understood .. I took the latest build this morning and tested it .. it is working the way you mentioned. I need to talk to my backend team to fix the clean up of playlist. Thanks for looking into it. May I know when the fix will be available? |
The fix will be available in pre-release with v1.6.0-beta.2 coming within the next week. v1.6.0 will be in beta until the start of 2025. |
You can workaround this issue in v1.5 by removing |
What version of Hls.js are you using?
1.5.7
What browser (including version) are you using?
Chrome Version 131.0.6778.70
What OS (including version) are you using?
Windows 11
Test stream
No response
Configuration
Additional player setup steps
No response
Checklist
Steps to reproduce
we have stop/resume feature in our hls.js player for Live Playback.
When the user stops the playback, we call stopLoad() and detachMedia(). On resume, we call startLoad() followed by attachMedia().
The issue I’m encountering is that after resuming, hls.js sends a level playlist request, but it gets canceled, and the player starts requesting old .ts segments instead.
I've attached a screenshot with color-coded blocks:
we have clean up process in our multicast playback which removes old ts segments. That's why you will see 404s for the old after user resumes the playback.
we do have higher frag retry count and once retry exhausts, we try to recover one more time by calling stopLoad and startLoad. At this time, Hls.js gets the refreshed playlist and start fetching new segments but It never plays the Video.
In our other playback modality like Play from a cache serve, we don't cleanup old ts segments that often. So, Hls.js requests one or two old ts segments and it gets 200 response but by that time it gets a refreshed Level playlist and all plays fine.
Expected behaviour
If TS segments have already been loaded and the stopLoad() method is called, then upon calling startLoad() again, hls.js should not request the previously fetched TS segments, as they were already successfully retrieved.
What actually happened?
After calling stopLoad() followed by startLoad(), Hls.js requests old TS segments. When these requests result in 404 errors, it cancels the level playlist call. Once the TS segment retries are exhausted, we attempt to recover playback by calling stopLoad() and startLoad() again. While the player receives the refreshed playlist and begins fetching new segments, it gets stuck and fails to play the stream.
Console output
Chrome media internals output
No response
The text was updated successfully, but these errors were encountered: