Re: Blob URLs for MediaStreams

On Wed, Oct 10, 2012 at 1:45 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

> On 10/09/2012 09:49 AM, Cyril Concolato wrote:
>
>> Le 10/9/2012 7:26 AM, Robert O'Callahan a écrit :
>>
>>> http://dev.w3.org/2011/webrtc/**editor/getusermedia.html#**methods-1<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.


I still argue that, but as long as createObjectURL is around we should make
it work as well as possible :-).


>  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?


Using a new URL scheme is not expensive for authors (who can mostly ignore
it) or implementors (in our implementation it's very little extra code to
give MediaStreams their own scheme). If it's expensive for people writing
spec text, I think that should be pretty low on our list of concerns :-).

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.
>

I strongly agree.

Rob
-- 
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]