Low-Latency with Byte-Range Based Segment Share between DASH and HLS

[technogeek00]

During the initial low-latency standardization talks there was desire to share segments between LL-DASH and HLS-LL but DASH had taken the path of utilizing chunk transfer encoding and HLS had taken the path of independent chunk (part in the spec parlance) description. Through conversation the concept of EXT-X-PRELOAD-HINT was extended to allow for open ended byte-range requests and similarly EXT-X-PART was given an optional BYTERANGE attribute. This was intended to bring interoperability between specifications and was initially adopted and deployed as a successful interoperability point in both the DASH-HLS Interoperability Specification (CTA-5005-A) by various industry entities (Akamai Blog).

However, over the course of deployment and continued HLS specification iteration, the requirements of the EXT-X-PRELOAD-HINT tag and line speed delivery of parts confusion among implementers. Some interpreted the specification to mean the request would only transmit completed parts terminating the connection after so that an origin would have to be made aware of the part structures instead of treating the object as a single file. This requirement would be a significant departure from previous origin implementation capabilities and require either separate origins for DASH and HLS or the creation of new media aware origins across the ecosystem.

This was recently clarified on the HLS Interest list to confirm that the origin should continue sending until the end of the segment, not the end of the part. This means that both DASH and HLS clients can continue to share the origin, but it must be guaranteed that the entire chunk is sent at a time. We should double check that DASH recommends the encoder hold and send an entire chunk at a time for general operation, or DASH-HLS can specify this as only a requirement for interoperability.

[haudiobe]

2023/10/06 TF discussion

• Releasing sub-chunks is not prohibited, but the encoder needs to complete a chunk in order to create the prefix sample tables of the chunk. Hence, it is unclear what would be the the benefit, reason for this discussion. However, there may be cases that the the sample tables can be pre-determined (example audio is may create constant size samples/chunks).
• We believe that at this stage nothing needs to be done in DASH LL according to the discussion.
• Direct chunk addressing may not be most essential, but we continue to work on this.
• Please continue to verify the discussion here. If no comments are received we close the issue in a few weeks

[AUGxhub]

I doesn't find EXT-X-PRELOAD-HINT have any advance .
If turn the http chunk encoding on ,refer (https://en.wikipedia.org/wiki/Chunked_transfer_encoding), the transfer layer will just make it , no need do this on application layer.

We believe that at this stage nothing needs to be done in DASH LL according to the discussion. -> agree