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

On 03/05/2012 01:42 PM, 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".
I'm tempted to claim that the correct response is that the Blob 
specification needs to be changed to support a createObjectURL() call.

The internal plumbing will be just about exactly the same, but the 
ability to do JS-level testing will be hugely different.

                          Harald

Received on Monday, 5 March 2012 12:55:02 UTC