Added low-latency elements

[JeWe37]

Continuation of #74. This fixes your comments, with the exception of the one regarding byte ranges. The reason is that it isn't really feasible to share the implementation. The from_str method needs to be given the exact string with the byterange, but the parser would first have to parse the byterange in order to know where it ends. Thus something like is done here isn't possible.

I haven't thoroughly verified this against the HLS spec myself, should that still be done?

[rutgersc]

with the exception of the one regarding byte ranges. The reason is that it isn't really feasible to share the implementation. The from_str method needs to be given the exact string with the byterange, but the parser would first have to parse the byterange in order to know where it ends.

Both use a string as input, so I would think that should work. Left a comment.

I haven't thoroughly verified this against the HLS spec myself, should that still be done?

I haven't either, and after a quick look it looks like things are still changing quite a bit. Despite this, the added attributes seem mostly fine I think?

[ystreet]

I've been trying this out and one thing I've noticed is that there doesn't seem to be a way to construct a playlist like https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis#section-9.11 as the the EXT-X-PART are all placed before the segment.

...
#EXT-X-DISCONTINUITY
#EXT-X-PART:DURATION=2.00004,INDEPENDENT=YES,URI="midRoll273.0.mp4"
#EXT-X-PART:DURATION=2.00004,URI="midRoll273.1.mp4"
#EXTINF:4.00008,
midRoll273.mp4
#EXT-X-PART:DURATION=2.00004,INDEPENDENT=YES,URI="midRoll274.0.mp4"
#EXT-X-PRELOAD-HINT:TYPE=PART,URI="midRoll274.1.mp4"
#EXT-X-RENDITION-REPORT:URI="/1M/LL-HLS.m3u8",LAST-MSN=274,LAST-PART=1

One would need to be able to either add EXT-X-PART after the segment uri (probably doesn't work as parts would not be written until the first segment is constructed), or have a parts field on the MediaPlaylist itself for the parts that will correspond to the next segment produced.

[JeWe37]

I've been trying this out and one thing I've noticed is that there doesn't seem to be a way to construct a playlist like https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis#section-9.11 as the the EXT-X-PART are all placed before the segment.

...
#EXT-X-DISCONTINUITY
#EXT-X-PART:DURATION=2.00004,INDEPENDENT=YES,URI="midRoll273.0.mp4"
#EXT-X-PART:DURATION=2.00004,URI="midRoll273.1.mp4"
#EXTINF:4.00008,
midRoll273.mp4
#EXT-X-PART:DURATION=2.00004,INDEPENDENT=YES,URI="midRoll274.0.mp4"
#EXT-X-PRELOAD-HINT:TYPE=PART,URI="midRoll274.1.mp4"
#EXT-X-RENDITION-REPORT:URI="/1M/LL-HLS.m3u8",LAST-MSN=274,LAST-PART=1

One would need to be able to either add EXT-X-PART after the segment uri (probably doesn't work as parts would not be written until the first segment is constructed), or have a parts field on the MediaPlaylist itself for the parts that will correspond to the next segment produced.

Perhaps the easiest way to deal with this is making the segment uri an Option, that way it can only be printed when required. The parser would need to be adjusted accordingly though. I will look into it some time.

[ystreet]

I've done some slight modifications to this branch in https://github.com/ystreet/m3u8-rs/tree/ll-hls to make it produce something that seems to be closer to the draft RFC. I do think some of the changes I've made (and some pre-existing) are not quite easy to grasp what the valid combination of tags might be.

[JeWe37]

From what I understand what you mean is that the way you've implemented this invalid playlists could be generated? I suppose having neither parts nor the segment uri would have to be made erroneous and having an incomplete(no uri) segment anywhere but at the end of the playlist too. The former one could probably capture in the type system with an enum, the latter may be hard.

I think the parser also needs to be adjusted though anyway, I will see when I get around to working on this again.

[ystreet]

Yes, semantically invalid playlists can be generated, syntactically they would be fine though.

[JuanMorenoS]

Hi Guys!
I’m resuming work on implementing low latency HLS with Rust :) So I’m going to restart this project. For now, I’ve found some minor errors in my first implementation (based on this branch). Should I upload it to my fork? Or should I make a fork of this fork? 😊