Re: removing createObjectURL

On 2013-09-05 23:22, Martin Thomson wrote:
> On 4 September 2013 05:39, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>> I don't thing it would be that much that needs to be specced up.
>
> After having a bit of a look at this, your analysis looks good to me.
> I think that doing this and removing createObjectURL together would be
> good.
>

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.

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?

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.


[1] 
http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#transferable-objects
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22270

Received on Tuesday, 10 September 2013 13:45:43 UTC