stream.hls: add --hls-segment-queue-threshold #5478
Conversation
There was a problem hiding this comment.
Not sure if the name of the CLI-argument and session-option makes sense and if there's a better one that's easier to understand.
Hmm, I agree with you that I'm not sure if the naming makes sense either but I also can't think of something better which accurately describes what is happening. I think your longer explanation in the argparser does a good job of explaining what is occurring and realistically I don't see that many users modifying this setting themselves without some knowledge of what is going on so it should be okay. 👍
|
@bastimeyer the 6.0.1 one eventually failed with this error
the m3u8 of youtube streams using ultra low latency mode seem to have set a target duration of 1 the one running this PR using |
|
Could you please link one of those YT live streams? |
sure, i used this one https://www.youtube.com/watch?v=mgBKCSJZtdc |
That's some very aggressive playlist polling. The current HLS spec is not designed for this, hence the addition of actual low-latency streams in the latest HLS spec revisions that have not been finalized yet. The default value of 3 should be fine though IMO. I'm also thinking about adding a lower boundary regardless the targetduration, so nonsense value like this can get ignored. Maybe something like 5 seconds. |
Allow users to customize the segment queue timing threshold which checks whether to stop the stream early if no new segments were queued after the playlist's target-duration multiplied by the queue-threshold-factor has passed.
Increase the default value from 2 to 3, so that the default configuration doesn't unnecessarily cause issues in certain live streams where the connection of the broadcaster is unstable and the streaming provider doesn't or can't queue new segments. Try to keep this value reasonably low, so we can still stop streams early when the `EXT-X-ENDLIST` tag is missing.
Wait for at least 5 seconds before stopping early, regardless of the playlist's targetduration and hls-segment-queue-threshold value
bastimeyer
force-pushed
the
stream/hls/segment-queue-threshold
branch
from
a3add92 to
7e7d7b4
Compare
Resolves #5476
Descriptions in the commit messages.
Second commit increases the value from 2 to 3, which is a bit more lenient, so unstable live streams don't cause unnecessary interruptions. This comes at the cost of stable live streams without an endlist tag being stopped a bit later.
Not sure if the name of the CLI-argument and session-option makes sense and if there's a better one that's easier to understand.
As a reminder:
https://datatracker.ietf.org/doc/html/rfc8216#section-4.3.3.1