Re: [Hls-interest] Playlist delta updates - clarification requested

[Rob Walch <[e-mail]>]

Hi Will,

On Fri, Mar 18, 2022 at 2:38 PM Law, Will <wilaw=[e-mail]> wrote:
> Playlist delta updates are a really useful feature. As we look to implement them, I had three questions:
>  
> 1. The spec says that can-skip-until attribute defines a skip boundary that “..  MUST be at least six times the Target Duration”. In the developer docs <https://developer.apple.com/documentation/http_live_streaming/enabling_low-latency_http_live_streaming_hls> we are given a sample playlist as shown below. The target duration is 4s but the skip boundary is only 12s. Should it 24s?

If the example is to follow the spec strictly, then yes it should.

> 2. If the answer to [1] is yes, then would the delta playlist as shown have add additional segments such that it described at least the last 24s of segments? Currently it only describes 4 complete segments at 4s each and one partially complete segment of 1.3s for a total of 17.3s.

CAN-SKIP-UNTIL should be 24 or at least six times the TARGETDURATION of 4. One of the reasons for this is so that there are no partial segments beyond the skip boundary:

   EXT-X-PART tags SHOULD be removed from the Playlist after they are
   greater than three Target Durations from the end of the Playlist.


> 3. What is the rule about how many segments must be described to meet the skip boundary declaration? Is it complete segments or does it take into consideration the partial build of the last segment? Let me illustrate this question with a hypothetical example. Imagine target duration is set to 5s due to some variability in encoding, but most segments are closer to 4s and skip boundary is set to 30s. As we deliver the first part of a new segments, should we list the last 7 segments (for a total of 4x7 = 28s) or 8 segments (32s) ? The rule to describe at least a skip-boundary worth of time suggests we should list the last 8 segments and then replace the rest with the #EXT-X-SKIP:SKIPPED-SEGMENTS tag. However if we went with 7 complete segments, then 2s in to the next segment we would actually be meeting our requirement of 30s. This would mean the playlist would suddenly switch to a different SKIPPED-SEGMENTS value since we could skip one more segment. This toggling of SKIPPED-SEGMENTS value would be undesirable for players and hence I think the unwritten rule should be that the delta update should describe at least CEIL(Skip-boundary/targetduration) complete segments and ignore the time impact of any partially delivered segments. Is this in fact the correct interpretation?

The expectation is that the skip boundary would be large enough to include all partial segments in the delta playlist update.

   A server produces a Playlist Delta Update (Section 6.2.5.1 <https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis#section-6.2.5.1>), by
   replacing tags earlier than the Skip Boundary with an EXT-X-SKIP tag.

   When replacing Media Segments, the EXT-X-SKIP tag replaces the
   segment URI lines and all Media Segment Tags tags that are applied to
   those segments. 

To avoid a change of SKIPPED-SEGMENTS on part update, we can clarify in this section that the skip tag replaces tags further from the last full segment than the skip boundary (changes in red):

   The Playlist Delta Update is a version of the Playlist in which Media
   Segments that are further from the end of the last (Parent) Media Segment in the the Playlist than the Skip
   Boundary (Section 4.4.3.8 <https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis#section-4.4.3.8>), as well as their associated tags, are
   replaced by an EXT-X-SKIP tag (Section 4.4.5.2 <https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis#section-4.4.5.2>).


Regards,

Rob Walch
Apple Inc.