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

Careful model: What's in a transfer?

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 28 Jun 2021 11:01:17 +0200
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <4830e24d-9428-4b09-de7d-e40f6f7d3321@alvestrand.no>
The editors are currently discussing the PR that is the next step in 
completely specifying what it means to transfer a MediaStreamTrack 
between Javascript contexts using PostMessage: 

Despite the title, "Describe more precisely track lifetime management", 
this (and the discussion) is mostly about the relationship between 
tracks and sources when multiple contexts are involved.

One point raised: What context does a source live in, and what happens 
to a source when the context dies?

As long as all tracks produced by a source stayed in the same context, 
the answer was easy: When the context dies, the source dies, and all the 
tracks associated with it end.

In the case of in-context iframes, it is also possible to observe the 
tracks' behavior from outside the context, even though this was never 
discussed in the design phase of MediaStreamTrack.

According to experiments by Youenn, all present implementations will end 
the tracks when the original context dies.

This means that the source context and the current context of a track 
share some communication channel that allows this to happen. We should 
discuss whether this communication channel (which is not 
Javascript-observable, since sources aren't) also carries 
ApplyConstraints calls and their effects, and whether there are other 
considerations that need to be taken into account because they cause 
inter-context interactions. Perhaps we should also discuss whether or 
not the tracks somehow carry their source origin with them, and what the 
result is if this is true?

Please discuss on the PR or the corresponding issue (or here, if you 

Received on Monday, 28 June 2021 09:01:31 UTC

This archive was generated by hypermail 2.4.0 : Monday, 28 June 2021 09:01:32 UTC