Re: getUserMedia API: How to use the LocalMediaStream object ?

On 3/5/2012 7:42 AM, Adam Bergkvist wrote:
> On 03/05/2012 11:03 AM, Harald Alvestrand wrote:
>> On 03/05/2012 06:33 AM, Randell Jesup wrote:
>>> Paste from the discuss-webrtc mailing list:
>>>
>>> On 3/4/2012 12:58 PM, Ludo wrote:
>>>> I am trying to use the getUserMedia API, but i get a problem at the
>>>> moment to insert the stream object into the balise video.
>>>>
>>>> Here us the main part:
>>>> <video autoplay id="test"></video>
>>>>
>>>>    navigator.getUserMedia('video', function(localMediaStream)
>>>>    {
>>>>      $('#test').attr('src',
>>>> window.URL.createObjectURL(localMediaStream));
>>>>     });
>>>>
>>>> I use opera Labs Camera whose support the API, but i get this error:
>>>> "Uncaught exception: TypeError: Cannot convert 'window.URL' to 
>>>> object".
>>>>
>>>> I also tried without this method:
>>>> <video autoplay id="test"></video>
>>>>
>>>>    navigator.getUserMedia('video', function(localMediaStream)
>>>>    {
>>>>      $('#test').attr('src', localMediaStream);
>>>>     });
>>>>
>>>> The stream object is into the balise video but nothing happens...
>>>
>>>
>>> I'm not sure why it doesn't work in Opera, but I will note that
>>> media_element.src = MediaStream is the API we at Mozilla would prefer
>>> to see adopted as a standard.  I'll let others here make the real
>>> argument (roc in particular is on vacation, but I know this is his
>>> preference), but I'll say that it's a much more obvious usage to the
>>> application programmer (and the above is evidence to that for me), and
>>> there may be some other advantages as well - perhaps easier tracking
>>> of possible consumers of the output of a MediaStream object, while
>>> createObjectURL() produces a string and thus you can't really know
>>> when it might be used.
>>>
>> I would also prefer the media_element.src = MediaStream.
>> My second preference is to make createObjectURL() a function on the
>> mediastream, rather than a free-floating function; I was writing some
>> tests over the weekend, and realized that the fact that
>> createObjectURL() is a free-floating function is *horrible* if you want
>> to do testing with mocks.
>
> I agree that createObjectURL()/revokeObjectURL() isn't the simplest 
> API to use. However, it solves a problem in the web platform that 
> isn't unique to WebRTC and MediaStream. The API is adopted from the 
> File API where it's used to create URLs to Blobs. It can, e.g., be 
> used together with a <input type="file"> element to select a image 
> file and show it (without uploading the image to the server first).
>
> var file = filePicker.files[0];
> // profilePic is an <img>
> profilePic.src = URL.createObjectURL(file);
>
> Combine a <input type="file"> with a video element and you have a 
> media player.
>
> I think we may need to support createObjectURL() to be consistent with 
> the rest of the Web platform. The question is rather if we think it's 
> necessary to have a second approach more in line with "vidio.src = 
> stream".

Or modify blob (as part of the WebRTC spec?) to include include 
blob.getMediaStream(), which has a bunch of positive aspects, especially 
if we want to unify media objects - objectURLs are very problematic from 
that aspect for use in things like MediaStream Processing (or for that 
matter, the Web Audio API, which I would like to see modified or merged 
with MediaStream Processing to have MediaStreams as the top-level 
abstraction.)

URLs don't help us solve other problems (and add new ones); MediaStreams 
are a mechanism that lets us solve a whole class of problems (and 
encapsulate utility/semantics such as audio/video synchronization and 
multiple/alternate  tracks).

We already have talked about the idea of navigator.getUserMedia() 
allowing the user to instead of giving a camera feed to replace it with 
a still image or pre-recorded video; modifying blob in this fashion 
would make that very easy to implement.

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Monday, 5 March 2012 16:35:09 UTC