On Thu, 17 Mar 2011 17:51:08 +0100, Olli Pettay <[email protected]>
wrote:
On 03/17/2011 06:31 PM, Philip Jägenstedt wrote:
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;
I'd assume stream url would be handled like
urls created using createObjectURL.
It could be then revoked.
I wasn't aware of this API, it's in
http://www.w3.org/TR/FileAPI/#dfn-createObjectURL for reference.
That API has an explicit revokeObjectURL to solve the lifetime issue, but
there's no such thing for the Stream API.
--
Philip Jägenstedt
Core Developer
Opera Software
