W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2011

[whatwg] Stream API Feedback

From: Philip Jägenstedt <philipj@opera.com>
Date: Thu, 17 Mar 2011 17:31:13 +0100
Message-ID: <op.vshxibn9sr6mfa@localhost.localdomain>
On Thu, 17 Mar 2011 16:48:40 +0100, Olli Pettay <Olli.Pettay at helsinki.fi>  

> On 03/17/2011 03:11 PM, Lachlan Hunt wrote:
>> On 2011-03-16 19:29, Olli Pettay wrote:
>>> Perhaps navigator.getUserMedia("audio,video", success, error);
>>> could return an url to the device in the success callback, and that url
>>> could be then set to video.src.
>> The creation of a URL is unnecessary indirection. It's easier to avoid
>> creating special URLs entirely, and instead assign the the Stream object
>> directly to video.src.
> The type of .src is string.
> Assigning a different type of object to it
> is quite strange.
> Also, if getUserMedia would return just an URL, browser wouldn't need
> to create any stream object (unless someone then want to stream
> from <video> to PeerConnection).

Sure, but instead one would have to mint URLs and keep a mapping between  
those URLs and the streams that they actually represent. If people copy  
those URLs around, how long are they supposed to work for? Consider this  

function getStreamURL() {
   var s;
   // code that sets s to a new Stream object for the default camera or  
   return s.url;
var url = getStreamURL();
/* garbage collector? */
document.querySelector('video').src = url;

Does this break randomly depending on when the garbage collector runs, or  
is the returned string somehow magical so that it actually keeps the  
stream alive?

>> ... src property definition needs to be changed
>> from DOMString to any.
> That would be strange and make API inconsistent with <img> and <iframe>  
> for example.

<video> is already very different to <img> and <iframe> in that it also  
has child <source> elements and a currentSrc attribute. What's the  
practical harm in allowing video.src setter take an object?

Philip J?genstedt
Core Developer
Opera Software
Received on Thursday, 17 March 2011 09:31:13 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:31 UTC