Re: [Hls-interest] Clarification on client and origin behavior with byte-range addressed LL-HLS

FWIW, Will, my expectation from an HTTP server has always been [b].

-acbegen

On Mon, Sep 25, 2023 at 6:37 PM Law, Will <wilaw=40akamai.com@dmarc.ietf.org>
wrote:

> Hello
>
>
>
> I’m looking for some clarification on intended client and origin behavior
> when playing back LL-HLS with byte-range addressing.
>
>
>
> # This is Playlist update 3
>
> #EXTINF:4.08,
>
> fs270.mp4
>
> #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE="20000@0
> ",INDEPENDENT=YES
>
> #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE="23000@20000"
>
> #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE="18000@43000
> ",INDEPENDENT=YES
>
> #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE="19000@61000"
>
> #EXTINF:4.08,
>
> fs271.mp4
>
> #EXT-X-PART:DURATION=1.02,URI="fs272.mp4",BYTERANGE="21000@0
> ",INDEPENDENT=YES
>
> #EXT-X-PRELOAD-HINT:TYPE=PART,URI="fs272.mp4",BYTERANGE-START=21000
>
>
>
> Given the snippet above, how should the player load the hinted part? It
> knows it starts at an offset of 21000 but it does not know the end. Per the
> spec
> https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis#section-4.4.5.3,
> if the last-byte-pos is unknown, then the player should use RFC8673 and a
> last-byte-pos value of 9007199254740991. Seeing an incoming range request
> of range: 21000-9007199254740991, what should the origin do? Does it
>
>    1. Serve bytes from 21000 to the end of the part
>    2. Serve bytes from 21000 to the end of the segment
>    3. Do something else
>
>
>
> If [a], that would be a departure from standard HTTP range request
> semantics. If [b], now the player receives all the remaining parts in that
> segment, instead of just the hinted part.
>
>
>
> Cheers
>
> Will
>
>
>
>
> --
> Hls-interest mailing list
> Hls-interest@ietf.org
> https://www.ietf.org/mailman/listinfo/hls-interest
>