RE: MediaRecorder: stopRecording event language

The stop event is the event that fires whenever recording ends.  It's not tied to the stop() function.  So it's just a question of what it should be called.

For the pause and resume events, it's likely that some applications will want to know _exactly_ when recording pauses and resumes.   Other events can be ahead of them in the queue, so we can't assume that they're instantaneous.  (Or, if we think we can, we could make them synchronous.)  If an app calls pause() and resume() right after each other, it can't be sure what the state is when resume() returns (unless we make resume() synchronous.)


-          Jim

From: Greg Billock [mailto:gbillock@google.com]
Sent: Thursday, September 19, 2013 4:15 PM
To: Jim Barnett
Cc: public-media-capture@w3.org
Subject: 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<mailto: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<mailto:gbillock@google.com>]
Sent: Thursday, September 19, 2013 1:59 PM
To: public-media-capture@w3.org<mailto: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