- From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- Date: Tue, 09 Oct 2012 09:49:20 +0200
- 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 UTC