- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 09 Oct 2012 14:45:29 +0200
- To: public-media-capture@w3.org
On 10/09/2012 09:49 AM, Cyril Concolato wrote: > 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. I agree - the Blob URL here is very much used as "opaque token passed from one API to another", not as "first-class object you can actually do things with". Mozilla's argued before that the use of "getURL(stream)" is not appropriate, and we should instead define a "srcObject" attribute on the HTML media elements - but this spec hasn't landed yet. >> >> 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. This makes sense to me, but URL schemes are a little expensive for my taste. Is there sense in looking for an URL scheme that can be used for "opaque token" instead? Or do we need the "mediastream" URL for anything else? > 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). FWIW, I think these usages are perfectly legitimate, but we should not confuse them with MediaStreams. MediaStreams are (at least in my mind) highly specialized objects, which do lots of things that are never appropriate to do on a pure data object - such as convert data formats, adapt to changing conditions, mediate changes in condition between PeerConnections and devices, and so on and so forth. If you need a generic byte-queueing object, I think that is a completely different specification. Harald
Received on Tuesday, 9 October 2012 12:46:10 UTC