RE: Expect behavior of calling stop before receiving the onstart event on MediaRecorder API?

Why don’t  we just put “return and run the following  steps asynchronously” before the phrase “wait until media becomes available”?  (Maybe change it to “once media becomes available”).  I’m less sure about the need for a ‘starting’ state.  The UA may well want to have one internally, but will it be useful to apps?


-          Jim

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Monday, December 09, 2013 8:47 AM
To: Jim Barnett; Randy Lin
Cc: public-media-capture@w3.org
Subject: Re: Expect behavior of calling stop before receiving the onstart event on MediaRecorder API?

On 12/09/2013 02:28 PM, Jim Barnett wrote:

Harald,

  Task B is not waiting for an external event.  It is queued waiting for task A to complete.  Once A completes, B takes over the single thread.

I was talking about the behaviour of Task A, not task B.

In particular, this line in the spec for the "start" method:


1.   Set state to 'recording' and wait until media becomes available from stream.

Since that wait isn't for a definite period, this means that the UA stops for an indefinite period, since no other tasks can be executed.

I think it should rather say something like:

  2. Set state to "recording" and return.

Then, somewhere else (a new section 2.4?), say

"During the lifetime of the Recording object, the following procedures are followed:"

If the state is "recording":
... steps 3-7 from the "start" method

(BTW, I think step 5 is specified in terms of an earlier version of the spec - it talks about setting recording to false; I think it should set the state to "inactive".)

(BTW(2): I think we may need to have a state between "inactive" and "recording", so that the async processing knows whether or not to raise the "start" event. Something like:

   (in "start" description): Set state to 'starting' and return.

   (in async description):

   when data becomes available:

   1. If state is "starting", set the state to "recording", raise a "start" event
       and create a blob for gathering data.
   2. Gather the data into the current Blob.
   3. If the timeSlice..... <language unchanged>

   when the stream becomes "ended":

   <language unchanged>







- Jim



-----Original Message-----

From: Harald Alvestrand [mailto:harald@alvestrand.no]

Sent: Monday, December 09, 2013 7:40 AM

To: Jim Barnett; Randy Lin

Cc: public-media-capture@w3.org<mailto:public-media-capture@w3.org>

Subject: Re: Expect behavior of calling stop before receiving the onstart event on MediaRecorder API?



On 12/05/2013 03:52 AM, Jim Barnett wrote:

Randy,

   The queuing behavior will be whatever the HTML specification requires.  If tasks A and B are put in the same queue, I would assume (given the normal meaning of 'queue') that means that B does not execute until A completes, but please educate me if the HTML spec says something different.



My understanding of the HTML event model is that essentially nothing happens while a task is executing (it's a single-threaded model), so a task waiting for something will essentially halt the browser.



If the spec says that a task should wait for an external event, I think the spec needs to change.





- Jim



-----Original Message-----

From: Randy Lin [mailto:rlin@mozilla.com]

Sent: Wednesday, December 04, 2013 8:57 PM

To: Jim Barnett

Cc: public-media-capture@w3.org<mailto:public-media-capture@w3.org>

Subject: Re: Expect behavior of calling stop before receiving the onstart event on MediaRecorder API?



Hi Jim,

About the start method

"Set state to 'recording' and wait until media becomes available from stream."

The stream available waiting time may not be estimated and it is possible that application want to cancel the recording operation during that time.

Does the stop method should in waiting queue until the start tasks finished?

That means stop method can be executed after onstart event fired.



-------------------------------------

-rlin



----- Original Message -----

From: "Jim Barnett" <Jim.Barnett@genesyslab.com><mailto:Jim.Barnett@genesyslab.com>

To: "Randy Lin" <rlin@mozilla.com><mailto:rlin@mozilla.com>, public-media-capture@w3.org<mailto:public-media-capture@w3.org>

Sent: Thursday, December 5, 2013 12:33:36 AM

Subject: RE: Expect behavior of calling stop before receiving the onstart  event  on MediaRecorder API?



Randy,

   I'm not sure why the UA would call stop().  I would expect the application to do it.  But in any case, the behavior should be as follows:  both start() and stop() queue tasks, so the stop() method's task will not be executed before the start task completes.  One of the first things that the start task does is to set the state to 'recording'.  At the time the stop task executes, it is true that the start event may not have been processed, but the state will be 'recording' and the stop task will execute and fire the dataavailable and stop events.  The only time that the stop task would raise an error would be if the recorder was in the wrong state.



- Jim



-----Original Message-----

From: Randy Lin [mailto:rlin@mozilla.com]

Sent: Wednesday, December 04, 2013 3:26 AM

To: public-media-capture@w3.org<mailto:public-media-capture@w3.org>

Subject: Expect behavior of calling stop before receiving the onstart event on MediaRecorder API?



Hi all,

Refer this API document.

https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/MediaReco


rder.html

What's the expect behavior if

UA try to call the stop method before receiving the onstart event on MediaRecorder API.

Should we queue this stop() task after onstart event or throw exception on stop method invoked or cancel the recording task and fire the events which stop() method required?

-------------------------------------

-rlin