W3C home > Mailing lists > Public > public-webrtc@w3.org > March 2012

Re: Blobs and MediaStreams (Re: getUserMedia API: How to use the LocalMediaStream object ?)

From: Rich Tibbett <richt@opera.com>
Date: Thu, 08 Mar 2012 11:56:43 +0100
Message-ID: <4F58906B.6000201@opera.com>
To: robert@ocallahan.org
CC: Adam Bergkvist <adam.bergkvist@ericsson.com>, Randell Jesup <randell-ietf@jesup.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>, "Robert O'Callahan" <roc@ocallahan.org>, Chris Pearce <cpearce@mozilla.com>
Robert O'Callahan wrote:
> On Wed, Mar 7, 2012 at 4:58 PM, Rich Tibbett <richt@opera.com
> <mailto:richt@opera.com>> wrote:
>
>     The following consequences were brought up in other recent
>     discussions elsewhere:
>
>     http://lists.w3.org/Archives/__Public/public-webapps/__2011OctDec/1522.html
>     <http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1522.html>
>
>     http://lists.w3.org/Archives/__Public/public-webapps/__2011OctDec/1516.html
>     <http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1516.html>
>
>     These problems are solvable and some good follow up emails follow
>     the links highlighted above. I think this group or the MediaStream
>     Processing API account for the concerns raised in these threads
>     (particularly in the case of the latter since it already extends
>     media elements to accept a type of 'any').
>
>
> Those threads are about the difficulties of making *all* source URIs
> accept direct Blob references, possibly while leaving the type of 'src'
> as DOMString. What I proposed and implemented is rather different: only
> 'src' for media elements is affected, I changed its type to 'any', and
> made it accept MediaStreams as well as strings. There are no difficult
> lifetime issues; in my case, a media element can keep its src
> MediaStream alive.

If we limit this initially to media element assignment with a view to 
extending it to other DOM APIs if, when and where it makes sense that 
would mitigate some of the complexity issues initially.

>
> I think the only subtlety is that when you set 'src' to a MediaStream,
> the element's 'src' content attribute can no longer reflect the DOM
> attribute, so I just set it to the empty string while the 'src' DOM
> attribute is not a string.

We went with a reserved, though unresolvable, about: URI, to indicate an 
object has been applied to the src content attribute. Specifically: 
about:streamurl. An empty string could lead to some issues when 
determining if an object has actually been assigned to src.

>
>     A number of folks from Opera have been arguing to keep this
>     optimization since it seems relatively clean and straight-forward.
>
>
> It's more than an optimization. Going through createObjectURL requires
> manual resource management but direct assignment to 'src' does not.
> Avoiding manual resource management is a big win.
>

Completely agree. createObjectURL is a level of API indirection that 
raises its own lifetime and revocation issues. I didn't want to 
underplay this as a good mechanism, just that we're likely to support 
both mechanisms going forward (with createObjectURL having more generic 
uses elsewhere in the web platform).

I'd like to see this added to the getUserMedia spec.

- Rich
Received on Thursday, 8 March 2012 10:57:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 8 March 2012 10:57:14 GMT