Re: removing createObjectURL

On 10 September 2013 06:45, Adam Bergkvist <adam.bergkvist@ericsson.com> wrote:
> I don't think MediaStream is a good candidate to be Transferable; it's not a
> "unsharable or expensive" resource [1]. We even support cloning in the API.
> It's also not clear how to neuter the transferred MediaStream object (on the
> sending side) since we don't have a permanent state where a MediaStream is
> useless. For example, you can always add new tracks to an inactive
> MediaStream.

I think that the desire is to make the MediaStreamTrack transferable,
which by proxy leads to a desire to make MediaStream transferable.  To
some extent the unsharable or expensive thing is a problem.  Consider
our discussions around exclusive access to sources.

And that's probably more to the point, it's the link to the
MediaSource that we want to be able to transfer.

> We also get some strange cases when ownership is transferred. Besides the
> getUserMedia() case that Stefan mentions, we have the case when a stream,
> received via PeerConnection, is transferred. What happens to the stream in
> the remoteStreams set in the PeerConnection?

Neutered, I imagine, since they are references to the same object.

> If we want to "export" a MediaStream I think it would be better to not
> transfer ownership, but simply clone the object as you send it as the
> "message" (first) argument to postMessage() (similar to Blob). The object
> that pops out on the other side should, preferably, be a MediaStream type
> that doesn't have the add/removeTrack() methods (as described in [2]). The
> track list of the "exported" stream would then reflect the original stream
> similar to a stream sent over a PeerConnection.

If you want to invent new mechanisms, another way of thinking of this
would be to create an RTCSelfConnection that worked like
RTCPeerConnection.  You could instantiate one in each window and pipe
the output from window to another.

Maybe an analogue of this problem has already been discussed in the
streams API work.

Received on Tuesday, 10 September 2013 16:48:17 UTC