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

[Luke Curley <[e-mail]>]

Hey Cullen,

On Tue, Mar 26, 2024 at 3:00 PM Cullen Jennings <[e-mail]> wrote:

> > On Mar 25, 2024, at 3:57 PM, Luke Curley <[e-mail]> wrote:
> >
> > Hey Cullen, thank you very much for writing down the proposed flow.
> >
> > The problem with this approach is that while there is head-of-line
> blocking on startup (via FETCH), there is no head-of-line blocking during
> the steady state (via SUBSCRIBE).
>
> Uh, what I wrote had nothing about fetch data being delivered on a single
> stream but I’m not clear what you want when filling the last 15 second of
> the buffer, if a group would block , do you want the next one sent in
> parallel slowing down the first or do you want the early stuff to arrive
> first.  I think either is pretty easy, I just don’t understand the goal of
> the use case.


You're right that "head-of-line blocking" is the wrong term here. What I
meant was:

The problem with this approach is that there are *ascending groups* on
startup (via FETCH), but there *descending groups* during the steady state
(via SUBSCRIBE).

As in, the publisher will send groups 0,1,2 via FETCH, but will send groups
2,1,0 via SUBSCRIBE.


> > Any congestion will cause the player buffer to shrink, and unfortunately
> it will be filled in reverse group order.
>
> What order do you want it filling in? I’m not seeing why what I proposed
> below would have it in reverse order.


I think the disconnect is that some viewers will want to skip content,
while other viewers will want to buffer content, depending on their target
latency. As it stands, we have to pick one of the two when creating each
object and encoding the send order, which then gets used by SUBSCRIBE.

Basically, like Will said, we either need:
1. A flag for SUBSCRIBE to ignore the send order (order=ASC).
2. FETCH to support future groups (since it uses order=ASC).

In either scenario, the lines between FETCH and SUBSCRIBE are extremely
blurred.