Re: [Moq] Scope of MOQ and ULL Streaming

["Ali C. Begen" <[e-mail]>]

> On Feb 8, 2023, at 3:21 PM, Bernard Aboba <[e-mail]> wrote:
> 
> On Feb 8, 2023, at 14:28, Ali C. Begen <[e-mail]> wrote:
>> 
>> 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.
> 
> [BA] I have an open source JavaScript implementation of frame/stream transport, as described on day 1 of the Interim.  It’s using headers closer to RTP than RUSH, but it would be easy to modify it to make it more “RUSH-like”.  If we could agree on what “performance numbers” might be relevant (I’m measuring frame RTTs, loss, reordering, etc. at the moment), perhaps we can make some progress. 

Yes, and we will start with that as soon as we can and indeed “performance numbers” is part of the requirements discussion I mentioned below.

> 
>> 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). 
> 
> [BA] Yes, that was my feeling as well.  When I talk to people about MoQ they understand the need for a successor to RTMP, but they are puzzled as to why it is necessary to reinvent HLS/DASH.  

I will post the link again: 
https://dashif-documents.azurewebsites.net/Ingest/master/DASH-IF-Ingest.html

It can replace RTMP right on.

We published this version some time ago before H3 was finalized and all that. It has the right notion of “pushing” using HTTP for ingest. It is not perfect for some of the use cases mentioned here, but I don’t see why it would be a bad starting point if we are cool with keeping the DASH/HLS syntax/model. We can work on it, make it use H3 with priorities, etc. so that it does pretty much what most of us want to do. 

>> 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.
> 
> [BA] That approach would be more likely to convince the doubters.

+1