Re: Questions/Comments on Media Stream Recording

onstop, onerror and maybe onwarning events  could need access  to accessor to allow MediaStream termination if needed.

regards, Frederick

Frederick Hirsch
Nokia



On May 22, 2013, at 4:15 PM, ext Mandyam, Giridhar wrote:

> Depends on the callback/event handler.  It may not make sense to make the MediaStream available to the ondataavailable handler for Recording API, as an example, because the MediaStream constraints could be changed by the handler which would interfere with recording.  On the other hand, it looks reasonable for onstop as fjh had suggested.
> 
> -----Original Message-----
> From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com] 
> Sent: Wednesday, May 22, 2013 12:41 PM
> To: Frederick.Hirsch@nokia.com
> Cc: public-media-capture@w3.org
> Subject: RE: Questions/Comments on Media Stream Recording
> 
> Frederick,
>  Ah, I get what you mean about having an accessor.  It may make sense to add an accessor so that callback functions could get at the MediaStream if they need to.  Does anyone else have an opinion on this?   I'd like to keep a consistent style across the Media Capture, Media Recording and Image Capture specs, so I'm wondering if we have any group-wide guidelines.
> 
> - Jim 
> 
> -----Original Message-----
> From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
> Sent: Wednesday, May 22, 2013 3:12 PM
> To: Jim Barnett
> Cc: Frederick.Hirsch@nokia.com; public-media-capture@w3.org
> Subject: Re: Questions/Comments on Media Stream Recording
> 
> Jim, thanks for your reply, my comments inline prefixed with <FH>
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> 
> On May 22, 2013, at 2:57 PM, ext Jim Barnett wrote:
> 
>> Responses in-line, set off by '>>'
>> 
>> - Jim
>> 
>> -----Original Message-----
>> From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
>> Sent: Wednesday, May 22, 2013 2:27 PM
>> To: public-media-capture@w3.org
>> Cc: Frederick.Hirsch@nokia.com
>> Subject: Questions/Comments on Media Stream Recording
>> 
>> I have a few comments/questions on the Media Stream Recording 5 Feb
>> 2013 draft,
>> http://www.w3.org/TR/2013/WD-mediastream-recording-20130205/
>> 
>> 1. General comment - I think some examples would help clarify the 
>> document, especially for constructor use and linkage with getUserMedia
>>>> Yes, we'll add these as we progress.
>> 
>> 2, section 3.1 says
>> 
>> "An implementation must return a Blob in a format that is capable of being viewed in an HTML <img> tag. ."
>> 
>> I assume this is true only for image blobs, for video this could be the <video> tag but not if the blob is only a slice of a video. Thus it might make more sense to say that the blob is the binary form of an image or video portion.
>>>> Yes, this is poorly phrased.  We haven't decided what we want to say about codecs, yet.  The general idea is that the UA should record in a format that it can play back, but it may not be necessary to say this, and there may be cases where it is reasonable to record in a format that you can't play back.  I think that I'll just remove this line for now.  
>> 3. I assume there is no way to create a recording and underlying stream in one step. Instead the process is to create a getUserMedia stream, then start recording, then end recording, then clean up the stream. Is this correct? 
>>>> This is correct.  
>> 
>> In this case, how likely is it that incorrect javascript or error handling could leave an underlying getUserMedia stream intact despite recording failure or completion?
>>>> Recording is not supposed to have side-effects on the MediaStream, so I would certainly expect the MediaStream to be intact upon completion of recording.  In the error case, it would depend on the nature of the error, but there certainly are recording errors that would terminate recording but leave the MediaStream intact.  
>> 
>> 4. would it make sense to include the underlying getUserMedia stream as an stoprecording event parameter to allow cleanup without global variable for the underlying stream?
>>>> I'm not sure I follow this comment.  The stream is an instance variable in the MediaRecorder class, so in that sense it is global to the class, but it is not global in the larger environment.  Since the MediaStream is passed in to the constructor, it seems natural not to require it to be passed in again as an argument to functions that work on it.  If you pass it in as a parameter, you open up the possibility of programming errors - passing a stream to stop on which start hasn't been called, etc.  
>> 
> <FH> I guess I'm asking how to determine the getUserMedia stream if needed to close it etc, as there is no MediaRecorder accessor for it (or is there?) If there is  no accessor then need to pass stream around or have a global, neither of which is desireable.
> 
> 
>> 5. should there be any guidance on timeslice values? What is a reasonable maximum or is there a way to query the available buffer size?
>>>> It might make sense to make this a Setting that can be queried.  I'd like to hear from implementers, though, as to whether they think they can define reasonable values for this. (I can imagine that a UA might want to define a max size, but I'm less sure about a min.) I would think the actual timeslice value would be heavily application-dependent.  
>> 
> 
> <FH> agree, only concerned with max - was wondering how an application developer would have any idea what to use for a timeslice and also write portable code.
> 
>> Based on code from Eric Bidelman (simplified from http://html5-demos.appspot.com/status/getusermedia/photobooth.html ) the following might help with creating an example for the document, though it probably could use some correction:
>> 
>>>> This could be useful.  It seems to record forever, though.  There is a  stopCallback, but stop() is never called.  Would the user stop recording by clicking on a button?   
> 
> <FH> that was my assumption in this case.
> 
>> 
>> HTML snippet
>> 
>> <p><button onclick="init(this)">Capture</button></p>
>> 
>> <script>
>>   navigator.getUserMedia = navigator.webkitGetUserMedia || navigator.getUserMedia;
>>   window.URL = window.URL || window.webkitURL;
>> 
>>   function dataAvailableCallback (data) {
>> 	// e.g. send blob to server which builds recording of video
>>   }
>> 
>> function stopCallback (stream) { // does callback receive underlying stream?
>> 
>> 	stream.stop();
>> 	// anything else?
>> }
>> 
>>  function successCallback(stream) { 
>> 	streamRecorder = MediaRecorder(stream, {onstop:  stopCallback ; ondataavailable: dataAvailableCallback} );
>> 	if (!streamRecorder) {
>> 	  console.log('could not record stream');
>>        stopCallback(stream);
>>         return;
>>      }
>> 
>>     streamRecorder.record(60000);  // return a minute at a time  }
>> 
>> function errorCallback(error) {
>>      console.log('Unable to get video stream [CODE '+  error.code + ']!' + error);  
>>      return;
>> }
>> 
>> function init(el) {
>>     if (!navigator.getUserMedia) {
>>         console.log('native web camera not supported');
>>       return;
>>     }
>>     navigator.getUserMedia({ video: true}, successCallback, 
>> errorCallback);  } </script>
>> 
>> thanks
>> 
>> regards, Frederick
>> 
>> Frederick Hirsch
>> Nokia
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
>

Received on Wednesday, 22 May 2013 20:50:36 UTC