W3C home > Mailing lists > Public > public-media-capture@w3.org > October 2012

Re: Blob URLs for MediaStreams

From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
Date: Tue, 09 Oct 2012 09:49:20 +0200
Message-ID: <5073D700.9050906@telecom-paristech.fr>
To: public-media-capture@w3.org
Hi,

Le 10/9/2012 7:26 AM, Robert O'Callahan a écrit :
> http://dev.w3.org/2011/webrtc/editor/getusermedia.html#methods-1
> The current draft says that createObjectURL mints a Blob URL for a 
> MediaStream. I don't think that is a good idea, since Blobs are static 
> objects (an immutable array of bytes), and MediaStreams are a 
> constantly-changing stream of media data. So a URL constructed for a 
> MediaStream cannot be used everywhere a Blob could be used, for 
> example it can't be loaded via XmlHttpRequest.
>
> So I suggest that a new URL scheme analogous to Blob URLs be defined 
> for MediaStreams, say scheme "mediastream". The rest of their 
> behavior, such as revocation, can be shared with Blob URLs.
I agree. In fact, I think MediaStreams could be useful in many 
scenarios. For instance, using a MediaStream as a text track source, 
which could be fed by XHR, for live cases. Another example is to be able 
to control the download and feed progressive document (e.g. SVG) parsers 
dynamically, adaptively, depending on for instance the bitrate. I think 
what is missing in Blob API is to be able to append data after the Blob 
is created and let the browser process/parse the new data (in a 
progressive manner).

Cyril

-- 
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Multimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
http://concolato.wp.mines-telecom.fr/
Received on Tuesday, 9 October 2012 07:49:52 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:02 GMT