Re: MediaRecorder: stopRecording event language

I think having an event indicating that recording has ended is good, but I
think it'd be better to keep it separate from a stop event.

(On that note, I think there's an argument we ought to get rid of all the
pause, resume, and stop events. The JS is causing them, so it can directly
signal any local state that needs updated.)


On Thu, Sep 19, 2013 at 12:48 PM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:

>  We may have an inconsistency between versions here.  In my editor’s
> draft, there is only a stop event with a corresponding onstop handler.
> This event fires whenever recording stops, no matter whether stop() was
> called or not.  (It won’t fire when you call stop() in the inactive state
> because in that case there’s no recording going on.)  Does this make sense?
> ****
>
> ** **
>
> **-          **Jim****
>
> ** **
>
> *From:* Greg Billock [mailto:gbillock@google.com]
> *Sent:* Thursday, September 19, 2013 1:59 PM
> *To:* public-media-capture@w3.org
> *Subject:* MediaRecorder: stopRecording event language****
>
> ** **
>
> Current spec language around an event generated when streaming
> dataavailable events stop:****
>
> ** **
>
> 4. When the stream is ended set recording to 'false' and stop gathering
> data.****
>
> 5. Then raise a dataavailable event containing the Blob of data.****
>
> 6. Finally, raise a stoprecording event.****
>
> ** **
>
> But the spec for the stop() method says:****
>
>
> When a MediaRecorder object’s stopRecording method is invoked, then if
> state is "inactive", the user agent must raise an INVALID_STATE exception
> and return immediately. Otherwise it must queue a task, using the DOM
> manipulation task source, that runs the following steps:****
>
> ** **
>
> (I think this is just a historical syntax error.)
>
> And 'stoprecording' doesn't appear in the section 2 EventTarget list.
>
> I think a "recording has now stopped" event is mandatory for the streaming
> updates case, so we need something here. Concrete suggestion:****
>
> ** **
>
> 1. Add a "attribute EventHandler onended;" line to section 2.****
>
> 2. The name of the "recording is now done" event will be "ended". (This
> mimics other webrtc events for similar semantics.) Update section 6 to
> reflect this.****
>
> 3. This event should be fired when either a single-shot recording finishes
> or streaming updates finish. That is, the docs for record(), step 6, should
> say "Finally, raise a ended event."****
>
> 3b. Clarify that a stop() call won't necessarily fire an ended event --
> only in a racy state where in fact the recording happens to have finished
> at the same time as the call will this happen, and then 'ended' may fire
> before the 'stop' event does.****
>
> 4. Change 'stoprecording' to 'stop' in the stop() method docs.****
>
> ** **
>
> -Greg****
>
> ** **
>
> ** **
>