Re: Blob URLs for MediaStreams

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