RE: Blob URLs for MediaStreams

I think that one of the reasons for wanting a URL is to allow a
MediaStream to be assigned to a <video> element.  If we don't provide a
URL, we have to extend <video> to allow some form of direct assignment
(I think that Randell is working on that.) But if we don't extend
<video>, we are forced to provide a URL.

- Jim 

-----Original Message-----
From: Cullen Jennings [mailto:fluffy@iii.ca] 
Sent: Tuesday, October 09, 2012 12:28 PM
To: robert@ocallahan.org
Cc: public-media-capture@w3.org
Subject: Re: Blob URLs for MediaStreams


On Oct 8, 2012, at 22:26 , Robert O'Callahan <robert@ocallahan.org>
wrote:

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

I agree that Blob makes no sense here. But it seems like a better thing
might not be a URL scheme but instead just define the object that gets
returned and out to get the data out of it.

Received on Tuesday, 9 October 2012 16:40:44 UTC