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

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.

/Adam

Received on Monday, 5 March 2012 13:39:24 UTC