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

["Law, Will" <[e-mail]>]

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