Re: [Moq] Scope of MOQ and ULL Streaming

[David Fernández <[e-mail]>]

"As you all know, codec folks publish a new codec standard once they
are about 50% better than the last one."

30% is the threshold considered in the evolution from HEVC (H.265) to
VVC (H.266).

I suspect that even an improvement of 20% could lead to adoption of a
new codec, or even less, considering other issues such as 'royalties'.

Regards,

David

From: "Ali C. Begen" <[e-mail]>
To: Bernard Aboba <[e-mail]>
Cc: Luke Curley <[e-mail]>, [e-mail],
"Shihang(Vincent)" <[e-mail]>, MOQ Mailing List
<[e-mail]>
Bcc:
Date: Wed, 8 Feb 2023 14:27:52 -0800
Subject: Re: [Moq] Scope of MOQ and ULL Streaming

> [BA] Yes, and it also implies that MoQ has to be a *lot* better than HLS/DASH to overcome it.  If HLS/DASH can be modified to achieve the same results (or even close to the same results) then MoQ will be DOA.

+1

> ...
>
>> The worst part about HLS/DASH is the latency. This is caused by head-of-line blocking (buffering) and the client being in charge (requesting playlists and segments).
>
> [BA] HoL blocking can be overcome using HTTP/3.   And it isn’t clear to me that the client being in charge necessarily implies high latency.

Agreed. Doing things on the server side has pros and cons but latency
is not necessarily one of the pros.

>> The Warp draft tackles these problems with QUIC prioritization (delivery order) and WebTransport push respectively.
>
>
> [BA] It isn’t clear to me why WARP with GoP/stream WebTransport has an inherent advantage over HTTP/3 using GoP/stream transport.  It’s QUIC underneath in both cases.
>
> That said, one could argue that RUSH’s frame/stream transport *does* have an advantage.  That is one of RUSH’s unique differentiators compared with RTMP, for example.

If there were some performance numbers put forward by the RUSH folks,
we would have a better idea. Without a code we can play with and no
reported results, your conclusion is just a guess and it is not
necessarily better or worse than mine.

Frankly speaking, there is a lot of commonality that we can focus on
between the two protocols for now and maybe by then there will be a
public/open-source implementation of RUSH to see the performance
differences.

>> The premise behind specifying a generic pub/sub protocol is that we can support non-media applications, so it's then more attractive for a CDN to support MoQ. However I'm terrified that we don't have any other applications in mind, and we're too eager to sacrifice media functionality in the pursuit of a bigger pie.
>
>
> [BA] To have a shot at wide deployment, MoQ needs a “killer application” that can’t be delivered nearly as well by modifying HLS or DASH.  The requirements document doesn’t really focus on what that is, nor does it fully enumerate all the requirements MoQ would need to satisfy to fully differentiate itself in that usage.

Agreed and because of that we are still repeating some of the
questions that were asked a year ago. It is not necessarily a bad
thing and every viewpoint may provide new insights into the problem at
hand, but I feel we are reinventing some of the things we had in the
early days of DASH/CMAF (with very minor changes and not necessarily
all good).

As you all know, codec folks publish a new codec standard once they
are about 50% better than the last one. We should debate how much we
need to be better than what we have today or what we are addressing
that was not addressed before. Then, we write the requirements for
that purpose and list the agreed assumptions.

-acbegen