Re: to stream the impossible stream (Knee deep in the wasm nonsense)

Lorenzo said: 

"-1 on an RTP stack in JS :-P

I'm strongly against all this wasm nonsense. Just because machines are
getting more powerful, doesn't mean we should drop more efficient code
for something that runs worse just because it's easier to move around.
It's a trend that is happening everywhere, and I hate it, because it
shows no regard for those who still ship machines that would atthe very
least struggle with that. Besides, this seems to bring us back to the
"WebRTC just for browsers" era: WebRTC is everywhere, now, and I can
already picture my mobile phone melting down any time I open a web page
with WebRTC on it."

[BA]   Let me try to re-trace the path that got us into the "wasm nonsense", in an attempt to understand where we made the "step too far". 

(Queue rendition by Pete Seager of "Knee Deep in the Big Muddy", lyrics: https://genius.com/Pete-seeger-waist-deep-in-the-big-muddy-lyrics)

The Funny Hats use case generates a requirement for access to raw media, and presumably some processing to be done on the raw media to generate the Funny Hats. 

This processing might use workers or WASM to improve performance.  But it seems to me that addressing those needs does not necessarily imply an RTP stack in JS, 
or even separation of Sender/Receivers into smaller bricks.  So the Funny Hats use case by itself doesn't necessarily imply an RTP stack in JS. Do you agree? 

Now there is also another requirement that has popped up, for synchronized data.  This has been encountered in VR scenarios where today developers are doing weird hacks on codecs that would probably be unnecessary
if they could send the meta-data over RTP (such as using the RTP payload described in RFC 4103). 

Support for an "RTP data channel" (as has been implemented in Chrome, Skype and other applications) would enable placement of arbitrary data into an RTP payload. 

Combined with access to raw media, it would become possible to implement a codec in JS. 

However, while this would make it *possible* to implement a codec in JS, it wouldn't *mandate* that developers implement codecs in JS, let alone an entire RTP stack. 

So I think that this incremental functionality does not yet lead us to be "Kneep Deep in the Warm Nonsense". since a developer can still access the RTP stack and codecs as they did before in WebRTC/ORTC without having to write their own RTP stack in JS. 

A developer *could* try to implement AV1 in JS with horrendous results in an effort to win a WebRTC NV 

But they would only be hurting themselves, and not inflicting pain on the wider developer community.  Do you agree? 

Lorenzo also said: 

"Even if all that weren't an issue, I still have strong concerns about
the impact this would have on interoperability. Right now, no matter
what you're using, as long as you implement the right protocols things
can exchange media with each other."

[BA] It is true that access to an RTP data channel could enable developers to create non-interoperable payloads in RTP and maybe even to carry out some attacks on faulty decoders (which could be attacked anyway without WebRTC). 

But this has already shipped in Chrome, so presumably there is data on whether bad things happened (I don't recall any incidents, myself). 

Lorenzo further said: 

"If "funny hats" and the like are the target here, as explained by
others I think there are better (and basically ready) ways to accomplish
this without disrupting the work that has been done in the last years."

[BA] IMHO, the Funny Hats use case only requires access to raw media and some processing on the raw media, not separation of the Sender/Receiver into smaller bricks or an RTP stack in Javascript. 

The VR use case requirement for synchronized data doesn't require an RTP stack in JS either, but may imply the need to place data into an RTP payload, which could lead to some of your interop concerns. 

But even with that step, there is no *requirement* that developers implement codecs in JS.  They only are given an additional gun to shoot off their own feet.

Received on Friday, 15 June 2018 02:14:17 UTC