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

On 03/05/2012 05:32 PM, Randell Jesup wrote:
> On 3/5/2012 7:42 AM, Adam Bergkvist wrote:
>> 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).

I agree that we shouldn't use object URLs as the way to consume 
MediaStream data in new APIs such as media processing and Web Audio API. 
PeerConnection is a good example of a new API that doesn't use URLs; it 
uses the MediaStream interface directly with addStream(). I was 
basically talking about legacy APIs that use a DOMString "src" attribute.

> 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.

Creating a MediaStream from a blob is interesting. We already have a 
MediaStream constructor that takes MediaStreamTrack objects. Perhaps the 
constructor could be overloaded to take a blob as well. Then we wouldn't 
have to change the Blob interface.

/Adam

Received on Tuesday, 6 March 2012 09:35:35 UTC