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

[Luke Curley <[e-mail]>]

On Mon, Mar 25, 2024 at 4:21 AM Ted Hardie <[e-mail]> wrote:

> Just so I understand the use case, is the choice of 15 seconds because of
> a control presumed to be on the player (a "go back N seconds"/"go forward N
> seconds" control)?
>
> I ask this because the ease of delivering this functionality depends a lot
> on whether the catalog producer has provided a mapping.  For a catalog with
> no mapping between groups and timings, this pretty much has to be done via
> a heuristic; for one with a well-described mapping, it should be trivial to
> extract.  If that is the case, I think it might make sense to say that the
> MoQT protocol provides the ability to request group ids/object ids earlier
> than live edge, but that mapping those to timing is not a function of the
> transport.   Any publisher that wants to provide that functionality has to
> do so in the catalog or with a timing track (and in a lot of cases, it will
> know whether or not the app has that type of control).
>
> If that were the case, then the only thing MoQT needs to do is to tell you
> the group number/object number of the live edge (as seen by the relay
> you're on).  The mechanics from that point are client driven.
>

There's a world where we add`timestamp` to the MoQT layer so the relay
becomes aware of the mapping. However, I think we keep it simple and let
the application deal with timestamps via a catalog or timeline tracks. But
I do think this is worth considering as we continue to discuss stuff like
TTLs and latency budgets, since they should be in time units.



> From my perspective, the next question is then whether you expect the
> client to have a playout buffer that allows it to handle re-ordering up to
> the 15 second mark.  If that is the case, then the subscribe with a group
> number/group id target makes sense to me, because the cache can start
> delivering whatever it has (including the live edge) and fill in the buffer
> as it gets older data, knowing that it is up to the client to hold that and
> start playback when it has the data it wants to send to the decoder.
>
> If you don't expect the playout buffer to be that large, then I think you
> do need to get the group/objects in order.  That requires either the relay
> to buffer until it can do that or something like what Cullen put forward,
> since that allows the client to drive the process in a way that gets the
> data in a specific order without going all the way to using fetch for the
> parts after the live edge.
>


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.