W3C home > Mailing lists > Public > public-media-capture@w3.org > April 2013

Re: Good example for media capture and streams

From: Harald Alvestrand <harald@alvestrand.no>
Date: Sun, 07 Apr 2013 17:56:43 +0200
Message-ID: <5161973B.2060608@alvestrand.no>
To: public-media-capture@w3.org
On 04/05/2013 02:54 AM, Michael Heuberger wrote:
> Thanks Adam.
>
> Of course I'll have to be specific here. Now that I have introduced 
> myself, let me outline few issues with Media Capture and Streams I had 
> and think need improvement:
>
>   * Not all browsers (Chrome + Firefox) throw the same error codes for
>     the same situations, i.E. PERMISSION_DENIED:
>       o Firefox throws a HARDWARE_UNAVAILABLE when the webcam is
>         already busy in another window.
>       o Chrome throws HARDWARE_UNAVAILABLE when the user hasn't
>         granted access to there webcam yet (for that situation Firefox
>         throws a PERMISSION_DENIED)
>
Please - this is a list for discussion of the spec.
What does the spec say? How should we change the spec?

I believe we have consensus that we need to have more error codes. But 
the spec has the defined ones listed in section 8.4.1 - they are 
"PERMISSION_DENIED" and "CONSTRAINT_NOT_SATISFIED".

"HARDWARE_UNAVAILABLE" is a Firefox extension. Do you want it to be added?
>
>   * Do you all know node.js? In node.js there is only one callback
>     instead of two, a success and an error callback. Here a proposal:
>       o navigator.getUserMedia(constraints, callback) instead of
>         navigator.getUserMedia (constraints, successCallback,
>         errorCallback);
>       o The callback has two parameters: callback(err,
>         localMediaStream) and that looks like node.js where the error
>         is always the first parameter in a callback function.
>       o An advantage of such a change would be better compatibility
>         with their huge library of other useful functions we could
>         combine with.
>

This has been suggested before. The counterargument is that imposing an 
if/then/else structure as the first thing you do in a callback is almost 
exactly the same code as two callbacks - if anything, it's less clear. 
The group decided to stay with two callbacks.

If you want to have one callback for stylistic reasons, it will take you 
approximately 10 lines of Javascript to write a 
"getUserMediaWithOneCallback" function. The change was not thought worth 
the pain of changing.

>   * I feel combining getUserMedia with a video output via localStream
>     and the 'loadedmetadata' event is a bit cumbersome. Why can't we
>     simply pipe the one output with the one input and that's all?
>

When you say "pipe the one output with the one input", I don't really 
understand what you mean. And the "loadedmetadata" event is not part of 
the spec - you're talking about something else than the spec. What is it 
that you want changed in the spec?

Thanks for the input - but I don't know what to change in response to it.

> That's all for now.
>
> Cheers
> Michael
>
>
> On 05/04/13 00:41, Adam Bergkvist wrote:
>> On 2013-04-04 03:29, Michael Heuberger wrote:
>>> Hello W3C editors of Media Capture and Streams
>>>
>>> I'd like to point you to an interesting prototype that relies 
>>> heavily on
>>> your working draft about media capture and streams:
>>> https://videomail.io
>>>
>>> It is written in node.js and uses media streams to obtain images from
>>> your webcam. Each frame is sent in real time and the server encodes a
>>> video. It works perfectly without flash.
>>>
>>> Of course I have some issues and ideas on how to improve the media
>>> stream API. And most of all, I'm also excited about the other draft
>>> about Media Stream Recording at
>>> https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/MediaRecorder.html 
>>>
>>>
>>>
>>> If you could ping me back and tell me what you think of the prototype,
>>> then we can go from there and I give you more feedback about the draft.
>>
>> It's really nice to get feedback from developers who have used the 
>> APIs we specify in this working group. The easiest way to get stuff 
>> fixed is to come with specific feedback on the parts the the 
>> specification(s) that you think need improvements.
>>
>> /Adam
>>
>
> -- 
>
> Binary Kitchen
> Michael Heuberger
> 4c Dunbar Road
> Mt Eden
> Auckland 1024
> (New Zealand)
>
> Mobile (text only) ...  +64 21 261 89 81
> Email ................michael@binarykitchen.com
> Website ..............http://www.binarykitchen.com
Received on Sunday, 7 April 2013 15:57:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:40 UTC