Re: removing createObjectURL

On 2013-09-10 18:47, Martin Thomson wrote:
> 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.
>

I think what you're saying about a link to the media source captures 
what we're after. createObjectURL() provides us with a link to a set of 
media sources that can be sent cross window. That functionality can be 
replicated by the ability to send a MediaStream (implicit clone) over 
postMessage(). Why complicate things and transfer ownership?

>> 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.

That might work. :)

postMessage() do support a bunch of other objects as the first argument 
(of type any) already.

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

Received on Wednesday, 11 September 2013 09:27:49 UTC