Re: [Hls-interest] Reducing latency when TARGETDURATION is conservative

[Roger Pantos <[e-mail]>]

Hello Luke,

> On Apr 6, 2021, at 1:19 PM, Luke Curley <[e-mail]> wrote:
> 
> Hey folks,
> 
> We're trying to reduce HLS latency for iOS users (AVPlayer) but we're running into a few issues. 
> 
> We don't transcode all streams, so the broadcaster is often responsible for setting the size of GOPs. While most broadcasting software will use a fixed GOP interval, like 2s for OBS, it's not a guarantee. We set a conservative value of 6s for TARGETDURATION just in case.
> 
> From our testing, 2s segments and 6s TARGETDURATION results in 18s+ latency with AVPlayer. The player seems to choose 3 * TARGETDURATION as the initial latency, which is quite excessive for our use-case.
> 
> The latest HLS RFC adds the HOLD-BACK attribute <https://tools.ietf.org/html/draft-pantos-hls-rfc8216bis-08#section-4.4.3.8>, allowing the server to choose the initial latency. Unfortunately, this attribute "MUST be at least three times the Target Duration" so it only confirms the AVPlayer behavior. I think this requirement could be relaxed without any negative impact.
> 
> There's still quite a lot of work remaining on our end to support LL-HLS. It would be great if we could reduce HLS latency while working on adding full LL-HLS support (ex. sub-segments, HTTP/2, etc).

The are some good reasons why we chose 3 * target duration as the limit for how close to play to live in a (regular-latency) HLS stream. There are a number of edge cases around joining and switching bit rates (once you’ve put your stake in the ground about how far from live you want to play). But in general, you can think of it like this: consider a stream in which all segments are the same duration as the target duration. On a continuous basis, the client must discover new segments and load those segments, subject to network variability. When joining or switching (video) streams, it must also chew through the segment to find an IDR; it’s not always at the start of the segment.

Regular HLS uses a polling mechanism to discover new segments. In the best case it discovers the new segment shortly after it is published, but in the worst case new segment discovery can be delayed by up to a target duration. It gets even worse if a caching proxy (like a CDN) is involved. Similarly, the worst case for segment download is when the segment bit rate is nearly equivalent to the network bandwidth. In that case it takes about a target duration to download the segment. 

The good news is that LL-HLS replaces polling with an event-based discovery mechanism for new (partial) segments. Blocking segment requests eliminate an extra round trip time from segment download. And the in-playlist identification of partial segments containing IDRs allows the client to make some new optimizations. These and other optimizations allow a LL-HLS player to pick a point closer to the live edge and still play reliably.

In your case, while you are working on your LL-HLS implementation, I would suggest reducing your regular EXT-X-TARGETDURATION value. (I would also encourage you to require your upstream broadcasters to commit to a GOP interval that they communicate to you.) The TARGETDURATION can be as low as the closest integer to the regular GOP duration. 

Note that it’s legal to create a segment without an IDR (as long as your playlists do not advertise EXT-X-INDEPENDENT-SEGMENTS). It’s not recommended, but in exceptional circumstances an occasional segment without an IDR will be tolerated. So you can split unusually long GOPs into multiple segments to comply with a less-conservative TARGETDURATION.


regards,

Roger Pantos
Apple Inc.