- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Mon, 05 Mar 2012 13:54:32 +0100
- To: Adam Bergkvist <adam.bergkvist@ericsson.com>
- CC: Randell Jesup <randell-ietf@jesup.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>, "ludovic.vue@gmail.com" <ludovic.vue@gmail.com>
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