[{"author": "\u00c9ric Vyncke", "text": "

Any volunteer https://notes.ietf.org/notes-ietf-115-mops?both ?

", "time": "2022-11-07T09:35:09Z"}, {"author": "\u00c9ric Vyncke", "text": "

Thank you, Warren

", "time": "2022-11-07T09:35:34Z"}, {"author": "Giles Heron", "text": "

seems odd that delay budget is under 1 ms when video is 120 fps (i.e. 8ms per frame)

", "time": "2022-11-07T09:46:15Z"}, {"author": "Ali Begen", "text": "

indeed

", "time": "2022-11-07T09:47:18Z"}, {"author": "\u00c9ric Vyncke", "text": "

Q to be asked on the mic ?

", "time": "2022-11-07T09:47:32Z"}, {"author": "Giles Heron", "text": "

I'm remote, but can do

", "time": "2022-11-07T09:47:56Z"}, {"author": "Kirill Pugin", "text": "

what is the reason for uncompressed video? is it driven by latency reqs?

", "time": "2022-11-07T09:49:34Z"}, {"author": "Giles Heron", "text": "

I suspect so...

", "time": "2022-11-07T09:49:52Z"}, {"author": "Jorge Ferret", "text": "

I think people already mentioned that: but why not use I frame compression (it can range from loseless to high compression), some broadcast contribuition equipment uses that schema (ex: JPEG XS)

", "time": "2022-11-07T09:54:10Z"}, {"author": "Ali Begen", "text": "

but even the newer jpeg codecs (just compressing each frame independently) gets a lot of mileage in terms of bw reduction w/o much delay.

", "time": "2022-11-07T09:54:24Z"}, {"author": "Kirill Pugin", "text": "

agree with @Jorge and @Ali, I am having trouble to see how this can be used in more than a lab with > 7.5 Gbps requirements :D

", "time": "2022-11-07T09:55:26Z"}, {"author": "Kyle Rose", "text": "

For certain applications (like surgery) you probably want to avoid the possibility of artifacts, e.g., from motion compensation. But you can probably avoid that even with some level of lossy compression.

", "time": "2022-11-07T09:55:28Z"}, {"author": "Spencer Dawkins", "text": "

I'm not smart about this, but I also suggest that some use cases are difficult to rely compressed video (especially remote surgery in a lawsuit-rich environment). Alternatively, in MOQ converstions with Cullen, he's told me \"but people are using TCP-based media in some parts of the world for remote surgery, because that's what they've got\".

", "time": "2022-11-07T09:55:49Z"}, {"author": "Giles Heron", "text": "

agreed - and as I say, I suspect having a 0.75ms RTT latency budget is a bit extreme when you only have one video frame every 8.3ms...

", "time": "2022-11-07T09:56:50Z"}, {"author": "Ali Begen", "text": "

surgeons wont react in less than a ms anyway :)

", "time": "2022-11-07T09:57:23Z"}, {"author": "Giles Heron", "text": "

exactly - human perception is a hard limit. IIRC you get false started in track & field if you move within 100ms of the gun

", "time": "2022-11-07T09:58:38Z"}, {"author": "Kyle Rose", "text": "

Does JPEG do any better these days with high-contrast, high-detail images? Like anything with text? If not, that might not be the best choice for something requiring detailed work.

", "time": "2022-11-07T09:58:46Z"}, {"author": "Ali Begen", "text": "

jpeg works wonders nowadays, but then the image profile for hevc and vvc does even better.

", "time": "2022-11-07T10:00:06Z"}, {"author": "Kirill Pugin", "text": "

any chance to turn off A/C in the room?

", "time": "2022-11-07T10:08:23Z"}, {"author": "Kyle Rose", "text": "

I'd rather they didn't. You don't want me to have to take off any more clothes.

", "time": "2022-11-07T10:09:21Z"}, {"author": "Kirill Pugin", "text": "

:satisfied:

", "time": "2022-11-07T10:09:41Z"}, {"author": "\u00c9ric Vyncke", "text": "

:-o

", "time": "2022-11-07T10:15:40Z"}, {"author": "Mohamed Boucadair", "text": "

@Luis: Thanks for sharing this. For next steps, it would be helpful to separate items that are specific to the engineering choices you made for integrating ALTO vs. items that require some protocol specific work. If no protocol extension is required, that's useful to share as well.

", "time": "2022-11-07T10:20:28Z"}, {"author": "Jorge Ferret", "text": "

Using MCAST could have great BW savings, but I guess you are converitng reliable connections to UNreliable ones, are treeCDN adding a requirement to receivers to suport auto-recovering to dataloss?

", "time": "2022-11-07T10:38:44Z"}, {"author": "\u00c9ric Vyncke", "text": "

I am more concerned about MTU mismatch (video is rather resilient wrt packet loss)

", "time": "2022-11-07T10:39:36Z"}, {"author": "Wolfgang Beck", "text": "

live streaming is the only niche for MCAST. Important, but still a niche

", "time": "2022-11-07T10:39:55Z"}, {"author": "Ali Begen", "text": "

Jorge Ferret said:

\n
\n

Using MCAST could have great BW savings, but I guess you are converitng reliable connections to UNreliable ones, are treeCDN adding a requirement to receivers to suport auto-recovering to dataloss?

\n
\n

You can still do unicast repair (as we do in iptv).

", "time": "2022-11-07T10:40:28Z"}, {"author": "Kyle Rose", "text": "

Not really. Large file downloads are also a good use case for multicast, like Windows updates and whatnot.

", "time": "2022-11-07T10:40:43Z"}, {"author": "Kyle Rose", "text": "

IMO, there are more potential use cases than it initially seems

", "time": "2022-11-07T10:41:02Z"}, {"author": "Ali Begen", "text": "

not everybody gets the updates at the same time @Kyle Rose

", "time": "2022-11-07T10:41:39Z"}, {"author": "\u00c9ric Vyncke", "text": "

OTOH Windows Updates are not done simultaneously (AFAIK and this could be changed)

", "time": "2022-11-07T10:41:57Z"}, {"author": "Wolfgang Beck", "text": "

Current provider multicast networks are not designed for software downloads.

", "time": "2022-11-07T10:42:02Z"}, {"author": "Kyle Rose", "text": "

They don't, Ali, but you can naively multicast a file in round robin fashion and receivers will just download a suffix and then a prefix rather than getting 0-<file size> in order.

", "time": "2022-11-07T10:43:29Z"}, {"author": "Kyle Rose", "text": "

Jake explained to me that there are even more efficient ways of doing this, but that gets the point across conceptually

", "time": "2022-11-07T10:43:57Z"}, {"author": "Ali Begen", "text": "

my bigger issue is the games. they are enormous (>50 GB)

", "time": "2022-11-07T10:44:29Z"}, {"author": "Kyle Rose", "text": "

Same deal

", "time": "2022-11-07T10:44:49Z"}, {"author": "Wolfgang Beck", "text": "

What protocol would you use for reliable MCast transport?

", "time": "2022-11-07T10:45:51Z"}, {"author": "Ali Begen", "text": "

yes carouseling is an old idea that works quite well but there has to be enough concurrency for the tradeoff to make sense. Otherwise, caching like HTTP is just fine and getting to the edge (via multicast if you like) and then simple unicast gets the job done.

", "time": "2022-11-07T10:46:23Z"}, {"author": "Kirill Pugin", "text": "

existing CDNs use HTTP pretty much e2e - would MCAST work with HTTP?

", "time": "2022-11-07T10:46:56Z"}, {"author": "Ali Begen", "text": "

Wolfgang Beck said:

\n
\n

What protocol would you use for reliable MCast transport?

\n
\n

If you are missing a portion of a media segment, you can do http-based repair (byte range request) like 3gpp does.

", "time": "2022-11-07T10:47:13Z"}, {"author": "Kyle Rose", "text": "", "time": "2022-11-07T10:49:53Z"}, {"author": "Wolfgang Beck", "text": "

I know re are mechanisms for media, but for game downloads you'd probably need something different

", "time": "2022-11-07T10:50:32Z"}, {"author": "Kirill Pugin", "text": "

re \"owners with rights\": wouldn't DRM solve this?

", "time": "2022-11-07T10:50:33Z"}, {"author": "James Gruessing", "text": "

Where it can be implemented, maybe.

", "time": "2022-11-07T10:52:12Z"}, {"author": "Ali Begen", "text": "

You can do something like NORM. You need a transport for multicast, whatever it is it will allow you to identify the packets and recover them thru retransmissions or FEC (like FLUTE, etc.)

", "time": "2022-11-07T10:52:30Z"}, {"author": "Kyle Rose", "text": "

DRM involves a lot of things, but I can't think of a model in which it doesn't imply the need for a relationship between every viewer and the content provider.

", "time": "2022-11-07T10:52:50Z"}, {"author": "Kirill Pugin", "text": "

yeah, decryption keys needs to obtain by every viewer - comparing to media traffic that probably not much of problem?

", "time": "2022-11-07T10:54:55Z"}, {"author": "Kyle Rose", "text": "

Good point, Eric. I can expand and maybe make my questions/comments more coherent by sending them to the list. Why didn't I think of that? ;-)

", "time": "2022-11-07T10:55:06Z"}, {"author": "\u00c9ric Vyncke", "text": "

;-)

", "time": "2022-11-07T10:57:42Z"}, {"author": "Spencer Dawkins", "text": "

We should also ask who wants to work on this in MOPS (at least on the mailing list)

", "time": "2022-11-07T11:01:36Z"}, {"author": "\u00c9ric Vyncke", "text": "

thanks to the chairs

", "time": "2022-11-07T11:01:39Z"}]