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
> 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
>> 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>
>> To: "Randy Lin" <rlin@mozilla.com>, 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
>> 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