Re: Extending createObjectUrl to MediaStream?

On 2013-08-30 21:40, 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.

That's my preference as well.

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

I have the same understanding.

>

Received on Sunday, 1 September 2013 05:21:48 UTC