Re: Extending createObjectUrl to MediaStream?

On 08/30/2013 09:39 PM, Randell Jesup wrote:
> On 8/30/2013 9:14 AM, Stefan Håkansson LK wrote:
>> On 2013-08-28 17:48, Dominique Hazael-Massieux wrote:
>>> We are thus looking for input on the use cases for createObjectURL as
>>> used for the File API, and whether these use cases would also apply to
>>> our MediaStream case. In general, is there a need for any object
>>> readable by media elements to support an URL-based approach for
>>> consistency with the rest of the platform?
>> One need I can see is when you want to display the video in another
>> window. Let's say you want to have the video in a popout window -
>> something I think we should definitely support - handing that window the
>> URL (using postMessage) for use by its video element is a very
>> convenient way to support this use-case. This works in Chrome today.
>>
>> But, an alternative could perhaps be to make MediaStream a transferable
>> (which means that the MediaStream object could be sent over using
>> postMessage IIUC).
>
> I'd far prefer that (transferrable...)  (and of course you can clone 
> MediaStreams using constructors, so you can keep a copy yourself). And 
> if it's transferred as a string, you'd have all the lifetime issues 
> caused by createObjectURL compounded.
>
> The uses I've seen to provide a URL to a worker or equivalent could be 
> handled by having it be a transferrable object and using postMessage() 
> (per above) as well.
>
For the benefit of those of us who don't know that part of the spec:

What spec is it that specifies what a transferable object is, and what 
the results of declaring it transferable are?

I guess that special cases for MediaCapture include handling / 
transferring the NoAccess and PeerIdentity constraints, if specified at 
creation time.

Received on Monday, 2 September 2013 13:54:55 UTC