W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2013

Re: Extending createObjectUrl to MediaStream?

From: Randell Jesup <randell-ietf@jesup.org>
Date: Fri, 30 Aug 2013 15:39:38 -0400
Message-ID: <5220F4FA.5070904@jesup.org>
To: public-media-capture@w3.org
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.

Randell Jesup -- rjesup a t mozilla d o t com
randell-ietf@jesup.org (remove -ietf for personal mail!)
Received on Friday, 30 August 2013 19:40:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:19 UTC