-
Notifications
You must be signed in to change notification settings - Fork 0
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
Support for low-latency media playlist #33
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is good in general, so I only have some smaller comments on the code.
There is one thing missing, though, and that is the circular buffer handling with a window. I think there should be a mechanism to automatically hide/remove the partial segments when they are too old.
It may also be good to have a method on the MediaPlaylist for adding a partial segment.
Hi @tobbee, this PR now includes all related changes to support low-latency streaming. It has been integrated into ll-hls-server and tested. One major change was to rewrite the logic for 'winsize'. In the previous code, it is possible to decode a media playlist with more than 'winsize' number of segments. This kind of media playlist will only output the first 'winsize' number of segments when encoding. Please feel free to leave your opinion. |
34dd1bc
to
8040ad0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good work Kun. I have some small comments.
The major one is on how we should handle partial segments. I think we should keep them for the last three segments, which does not seem to be the case right now.
I also wonder why you want to increase the Go version to 1.22?
@@ -790,6 +882,22 @@ func (p *MediaPlaylist) Encode() *bytes.Buffer { | |||
p.buf.WriteString(seg.ProgramDateTime.Format(DATETIME)) | |||
p.buf.WriteRune('\n') | |||
} | |||
// handle completed partial segments | |||
if p.HasPartialSegments() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding was that we should typically keep the partial segments for the last three segments. To me, this looks as if you remove them for all full segments. I think that is too aggressive, but I may be wrong. What's your take on keeping them for three segments?
targetDurLocked bool // target duration is locked and cannot be changed | ||
independentSegments bool // Global tag for EXT-X-INDEPENDENT-SEGMENTS | ||
PartTargetDuration float64 // EXT-X-PART-INF:PART-TARGET | ||
PartialSegments []*PartialSegment // List of partial segments in the playlist. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we make the PartialSegment part of the Segment instead?
I think that makes sense, although old segments should not keep that data.
To check if partial segments should be kept, I will try to compare its sequence number with the latest full segment number. We are keeping partial segments in a separate list so to not add a new flag in |
The last commit added support for "#EXT-X-SKIP:SKIPPED-SEGMENTS" tag. HLS server should call |
|
This PR will try to add support for low-latency-related tags.