On Thu, 17 Mar 2011 16:48:40 +0100, Olli Pettay <[email protected]>
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;
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
