Re: Blob URLs for MediaStreams

On 10/09/2012 02:51 PM, Robert O'Callahan wrote:
> On Wed, Oct 10, 2012 at 1:45 AM, Harald Alvestrand <harald@alvestrand.no
> <mailto: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.

I think this is a good idea.

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

I agree.

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

Absolutely. Note that there was a proposal for this about a year ago: 
http://html5labs.interoperabilitybridges.com/streamsapi/

I don't know if that work has advanced.

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

Received on Tuesday, 9 October 2012 13:02:51 UTC