Re: [Moq] Flow to join 15 seconds before live

[Cullen Jennings <[e-mail]>]

This description below is really useful - thanks.  I will note that it identical to real time with some differences of 

MIN_BUFFER probably 0. TARGET_LATNCY is dynamically adjusted but often sits around 60 ms and MAX_BUFFER again might be dynamic but would often be more like 200 ms.  The main differences would be when the buffer was persistently under running, subscribe to a stream with a lower bit rate and when the buffer underuns, just skip frames until a enough information is received to create a valid frame. 

It would be great to add to this use case roughly have receiver side adaptive bit rate would work in cases where the link became slower than the track bitrate. 

> On Mar 25, 2024, at 1:12 PM, Luke Curley <[e-mail]> wrote:
> 
> Yeah, the player's goal is to build up to a 15s playback buffer so it can continue reliable playback even during severe congestion.
> 
> Note that the "buffer" is an ordered queue, not a reassembly buffer like is used in RTP. Playback will pause until the next frame is available (buffering) and only resume once the next MIN_BUFFER seconds are available. The time spent paused depends on the availability of this MIN_BUFFER, which is why it's paramount to prioritize old media. But like you suggested, I still want media to potentially arrive out of order so the network can be fully utilized (not true in HLS/DASH).
> 
> The 15s number we've been talking about is what I call TARGET_LATENCY. The idea is to start TARGET_LATENCY seconds behind the live playhead as a soft maximum size of the buffer. What's cool is that each time the player pauses, the TARGET_LATENCY effectively increases by the time spent paused as we fall further behind. Note again that playback will start well before TARGET_LATENCY has been received; it's the upper bound not the lower bound.
> 
> Finally there's a MAX_BUFFER which is based on memory available. When TARGET_LATENCY > MAX_BUFFER then you have the VOD use-case, which Ted I think you were alluding to in the last paragraph. The player needs to periodically FETCH/SUBSCRIBE with end=current+max_buffer.
> 
> For Twitch, we roughly had the numbers:
> MIN_BUFFER=1s
> TARGET_LATENCY=5s
> MAX_BUFFER=30s
> 
> But we would regularly see sessions with TARGET_LATENCY in the 15s range due to congestion on poor networks. In fact, we would tune this number based on the ISP to avoid unnecessary latency or buffering at the start of a session. 
> 
> Again, I want to emphasize that while the player strives to have 15s buffered, this buffer size will shrink during poor conditions unbeknownst to the viewer. If there's currently 2s remaining in the buffer after a deadzone or severe bout of congestion, the absolute worst thing we could do is prioritize media 15s in the future, as we'll pause playback if we don't receive the media 2s in the future. The same is true for VOD.