W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2018

Re: webrtc nv and whatwg streams

From: Randell Jesup <randell-ietf@jesup.org>
Date: Sat, 9 Jun 2018 20:13:23 -0400
To: public-webrtc@w3.org
Message-ID: <476de062-3b79-1fd8-9fd6-d7b74f2d9d65@jesup.org>
On 6/9/2018 2:52 PM, Sergio Garcia Murillo wrote:
> On 09/06/2018 19:41, Randell Jesup wrote:
>> Not to belabor a point here, but if this is to occur on the main 
>> thread there's a real problem with this API (and this could occur I 
>> suppose, with a bunch of additional work elsewhere in the spec, on a 
>> Worker).
>>
>> Even on a Worker, outside of emscriptem/WASM code that carefully 
>> doesn't throw garbage, there will be GC pauses causing hiccups in the 
>> stream - potentially long (in a realtime sense).
>>
>
> Fully agree. But if all components are implemented natively there 
> should be no need to go into the main thread or call any js code once 
> the streams are attached and the pipe chain is created. If someone 
> wants to reimplement any of the components in js or add custom ones, 
> then, they will have to be really careful, but they will not impact on 
> the performance of the rest of the people using the APIs.
>
> Not sure what is the expected whatwg stream behavior and if this is 
> supported/possible, but both in their use cases and the design would 
> be quite similar to what we are trying to achieve.

Correct - if these are all predefined nodes (or something in WASM that 
doesn't throw garbage, probably), then you won't be subject to GC (or 
event queue) delays.  I may have been jumping the gun on suggesting that 
this was a problem with streams here (it's a saturday and I'm packing 
for a conference).  If, however, any of these takes a trip through 
JS/event queues, then it's problematic (like a number of the proposals 
that had JS involved in packetization and other network and media-input 
related actions).

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too much spam
Received on Sunday, 10 June 2018 00:16:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:42 UTC