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

On 03/05/2012 02:33 PM, Adam Bergkvist wrote:
> On 03/05/2012 01:54 PM, Harald Alvestrand wrote:
>> 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,
>
> if you run:
>
> webkitMediaStream.prototype.createObjectURL = function () {
>     return webkitURL.createObjectURL(this);
> };
>
> in the init section of your JS-app you can do:
>
> video.src = stream.createObjectURL();
>
> with any MediaStream or LocalMediaStream instance.
Yep; what I can't do is to hand my MediaStream instance to a piece of 
code that doesn't know my convention, and expect it to call 
stream.createObjectURL instead of webkit.createObjectURL(stream).

Received on Monday, 5 March 2012 13:47:11 UTC