[whatwg] Stream API Feedback

On 03/17/2011 06:31 PM, Philip J?genstedt wrote:
> On Thu, 17 Mar 2011 16:48:40 +0100, Olli Pettay
> <Olli.Pettay at helsinki.fi> wrote:
>
>> 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
> scenario:
>
> function getStreamURL() {
> var s;
> // code that sets s to a new Stream object for the default camera or
> something
> return s.url;
> }
> var url = getStreamURL();
> /* garbage collector? */
> document.querySelector('video').src = url;

I'd assume stream url would be handled like
urls created using createObjectURL.
It could be then revoked.


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

API inconsistency.

Received on Thursday, 17 March 2011 09:51:08 UTC