Re: WebRTC in workers

> Le Jun 27, 2018 à 2:25 AM, Harald Alvestrand <harald@alvestrand.no> a écrit :
> 
> On 06/27/2018 01:28 AM, Feross Aboukhadijeh wrote:
>> Seconding what Youenn said. Transferring a data channel to a worker while the PeerConnection remains in the main thread would prevent many use cases. It's best if the PeerConnection can be initiated directly in the worker so it can be shared among many open tabs, or initiated entirely from within a service worker in response to a push notification or 'fetch' event.
> 
> I’m still curious about exactly what Youenn meant by "transferring a RTCDataChannel between different contexts is already shimable".

I mean using postMessage to shim RTCDataChannel methods (send, events…) in a worker based on an existing RTCDataChannel in a window.
Obviously, it is not as efficient as it could be but it should allow getting the same level of functionality as transferring an RTCDataChannel in a Web Worker.

> Another thread pointed out that if you're in the same origin (and same process), pushing media into another page already works.
> 
> So we have three possible technical features:
> 
> - Making PeerConnections usable in workers
> - Moving objects between contexts (making them transferable)
> - Allowing access to media from workers (this may have multiple meanings)

Let’s first precise the notion of transferring.
There are two possibilities:
1. Transfer the object including its lifetime. This is the most powerful/complex transfer.
That would mean that a service worker could keep using a camera stream after the document that made the getUserMedia call is destroyed.
It might also require transferring a lot of state machinery.
This seems hard to define and implement. I do not see huge benefit compared to exposing RTC constructs in a worker.

2. Transfer the object but not its lifetime. This is the easy transfer.
When the document where the object was created goes away, the transferred object ends up in a closed/ended state.
This should work quite well for MediaStreamTrack, RTCDataChannel.
This could work with some additional efforts for RTCPeerConnection/sender/receiver.

I’ll focus on 2 below.


> I’d like to put those up in a matrix against the use cases, so that we can see what's required for what.

Let’s do this exercise.
The use cases I heard so far:
1. Process data channel content in a worker (off the main thread processing)
2. Process media content in a worker (off the main thread processing, could be funny hat)
3. Long lasting data channel content connection: DHT, WebTorrent
4. Long lasting media content connection: Could be an extension of DHT, WebTorrent for live content. Could be used as a way to have very quick connection setup.

Process data
Process media
Long lasting data connection
Long lasting media connection
RTCPeerConnection creation
Y
Y
Y
Y
RTCPeerConnection transfer
Y
Y
N
N
RTCDataChannel creation
Y
N
Y
N
RTCDataChannel transfer
Y
N
N
N
Sender/Receiver creation
N
Y
N
Y
Sender/Receiver transfer
N
Y
N
N

As can be seen, exposing RTCPeerConnection fulfills these scenarios.
Exposing RTCDataChannel/RTCRtpSender/RTCRtpReceiver constructors would equally fulfill these scenarios, with more granularity.
In most cases, exposing RTCRtpSender/RTCRtpReceiver (or RTCPeerConnection for media) is not useful if there is no way to transfer a MediaStreamTrack.