Skip to content
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

Failing live playlist update when lowLatencyMode = false #3566

Closed
3 of 5 tasks
kanongil opened this issue Mar 4, 2021 · 3 comments · Fixed by #3792
Closed
3 of 5 tasks

Failing live playlist update when lowLatencyMode = false #3566

kanongil opened this issue Mar 4, 2021 · 3 comments · Fixed by #3792

Comments

@kanongil
Copy link
Contributor

kanongil commented Mar 4, 2021

When using a LL-HLS stream and lowLatencyMode: false, hls.js will request part 0 from a future segment. The server can return an error, since it is likely more than 3 parts into the future.

Note that the stream will actually play, since hls.js has some recovery logic, but it means that 3 requests are made for each live playlist update.

What version of Hls.js are you using?

master / c5698be.

What browser and OS are you using?

Test stream:

https://stream.sob.m-dn.net/live/sb1-ll/index.m3u8

Checklist

  • The stream has correct Access-Control-Allow-Origin headers (CORS)
  • There are no network errors such as 404s in the browser console when trying to play the stream

Steps to reproduce

  1. Play LL-HLS in demo player with lowLatencyMode: false.

Expected behavior

Request future index update using _HLS_msn=<next-msn> param, or use regular part updates from lowLatencyMode: true logic.

Actual behavior

Request future index update using _HLS_msn=<next-msn & _HLS_part=0 params, resulting in 503s and multiple requests.

Console output

xhr-loader.ts:121 GET https://stream.sob.m-dn.net/live/sb1-ll/v8Ew9fFqC0AEwfHoR5PS1cF/stream.m3u8?_HLS_msn=307769&_HLS_part=0 503
xhr-loader.ts:184 [error] > 503 while loading https://stream.sob.m-dn.net/live/sb1-ll/v8Ew9fFqC0AEwfHoR5PS1cF/stream.m3u8?_HLS_msn=307769&_HLS_part=0
playlist-loader.ts:600 [warn] > [playlist-loader]: A network error occurred while loading level level: 3 id: 0 group-id: "null"
base-playlist-controller.ts:231 [warn] > [level-controller]: retry playlist loading #1 in 2000 ms after "levelLoadError"
main.js:718 Error event: {type: "networkError", details: "levelLoadError", fatal: false, url: "https://stream.sob.m-dn.net/live/sb1-ll/v8Ew9fFqC0…HoR5PS1cF/stream.m3u8?_HLS_msn=307769&_HLS_part=0", loader: XhrLoader, …}
@robwalch
Copy link
Collaborator

robwalch commented Mar 5, 2021

The request you are referring to is a blocking playlist request, not a part request. Blocking playlist requests for part 0 are used even when lowLatencyMode: false is set.

I'm unable to reproduce in the lastest release (v1.0.0-rc.3) with Apple's CMAF stream:

https://hls-js-783b9d6a-cfe1-4fe0-babe-ddf2cab3adbe.netlify.app/demo/?src=https%3A%2F%2Fll-hls-test.apple.com%2Fcmaf%2Fmaster.m3u8&demoConfig=eyJlbmFibGVTdHJlYW1pbmciOnRydWUsImF1dG9SZWNvdmVyRXJyb3IiOnRydWUsInN0b3BPblN0YWxsIjpmYWxzZSwiZHVtcGZNUDQiOmZhbHNlLCJsZXZlbENhcHBpbmciOi0xLCJsaW1pdE1ldHJpY3MiOi0xfQ==

There are no part requests made and playlist requests work as expected.

Would you prefer that hls.js not use directives or blocking playlist requests when lowLatencyMode: false is set?

@robwalch robwalch added this to To do in Low-Latency HLS (LL-HLS) via automation Mar 5, 2021
@kanongil
Copy link
Contributor Author

kanongil commented Mar 6, 2021

Sorry about the confusion. I am talking about playlist update, where hls.js requests one containing a future part using a blocking request.

I am not talking about how Apple's server happens to handle this, but how it should be handled to comply with the spec. As I stated, the current logic can expect error responses, since the server is not expected to handle such part update requests more than 3 seconds into the future (for <= 1s parts): https://tools.ietf.org/html/draft-pantos-hls-rfc8216bis-08#section-6.2.5.2

If the _HLS_msn is greater than the Media Sequence Number of the last
Media Segment in the current Playlist plus two, or if the _HLS_part
exceeds the last Partial Segment in the current Playlist by the
Advance Part Limit, then the server SHOULD immediately return Bad
Request, such as HTTP 400. The Advance Part Limit is three divided
by the Part Target Duration if the Part Target Duration is less than
one second, or three otherwise.

It appears that my server is responding wrong (503 when 400 is expected), but hls.js should not have made the request regardless.

I would expect hls.js to still do blocking updates (since the playlist advertises CAN-BLOCK-RELOAD=YES). Either using the normal low latency update logic, advancing 1 part at a time, or preferably at a lower cadence advancing "Advance Part Limit" at a time.

Another possibility is to do the update requests without the _HLS_part, as if it was a non-low-latency stream with blocking support. However, this is not a spec compliant downgrade, and would need a test to ensure server support.

@robwalch
Copy link
Collaborator

robwalch commented Apr 16, 2021

Hi @kanongil,

I'd like your opinion on the fix for this issue in #3792

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging a pull request may close this issue.

2 participants