Re: Good example for media capture and streams

Hi Adam

See between our lines below:

> Please - this is a list for discussion of the spec.
> What does the spec say? How should we change the spec?

Ok, respect. It's my first time here ...

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

Agreed. At the moment each browser is behaving a bit differently with 
error codes. For example Chrome throws a HARDWARE_UNAVAILABLE when user 
has denied access to webcam whereas it's PERMISSION_DENIED for Firefox.

Hence I have this complicated logic in my current program code:

         if (typeof(err) == 'object')
             if (err.code == 1 && err.PERMISSION_DENIED == 1)
                 err = 'PERMISSION_DENIED';

         switch (err) {
             case 'NO_DEVICES_FOUND':
                 message = 'hmm, no webcam could be found!';
                 break;
             case 'PERMISSION_DENIED':
                 message = 'permission to access your webcam has been 
denied!';
                 break;
             case 'HARDWARE_UNAVAILABLE':
                 message = 'your webcam is unavailable!<br/>maybe it is 
already busy in another window?';
                 if (this.browser.isChrome)
                     message += '<br/>or you have to allow access above?';
                 break;
             default:
                 if (typeof err == 'string')
                     message = err;
                 else
                     message = JSON.stringify(err);
                 break;
         }

>
> "HARDWARE_UNAVAILABLE" is a Firefox extension. Do you want it to be added?

Yes please, the more the better. Thanks.

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

I understand. But then I wonder why it's differently in the node.js 
world. What was the reasons of the node.js makers to have one callback? 
I'm curious about this, will investigate a bit more and come back about 
this one. Maybe the node.js folks have a very good reason we missed out 
in that discussion? I think in general, solving problems like these must 
be shared, no matter that language or technology.

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

Thanks. I know that :)

>
>>   * 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?

At the moment it's cumbersome if I want to redirect the live video feed 
to a canvas on the browser. Too many code lines are needed: 
getUserMedia(), the 'loadedmetadata' event, play(), initialise the 
canvas and get it's 2d context for rendering. I can show you all that 
code. Or here an example (ignore the discussion): 
http://stackoverflow.com/questions/14857752/context-drawimage-canvas-todataurl-lagging-significantly-on-opera-mobile

Now, what I meant is to simplify all that: Make it possible to pipe the 
video feed into the canvas directly. Like streams. Just pseudo code here:
getUserMedia().pipe().canvas;

Any data getUserMedia generates is treated as an input that goes into 
the canvas. Something like that. Just an idea. I like the concepts of 
streams we have over there with node.js and it's fantastic. With streams 
you can attach, combine pieces very easily together ...

Cheers
Michael

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

-- 

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