Re: MediaRecorder: stopRecording event language

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

>  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.
>

That's what I interpreted the current language was trying to do, modulo
some typos. I think 'ended' is more consistent with other webrtc elements,
though.


Reading
http://www.w3.org/TR/2012/WD-mediacapture-streams-20120628/#widl-MediaStream-onended,
I see this:

When track instance track ends for any reason other than the stop() method
being invoked on the LocalMediaStream object that represents track, the
user agent must queue a task that runs the following steps:
1. If the track’s readyState attribute has the value ENDED (2) already,
then abort these steps.
2. Set track’s readyState attribute to ENDED (2).
3. Fire a simple event named ended at the object.


stop() says this:


When a LocalMediaStream object’s stop() method is invoked, the user agent
must queue a task that runs the following steps on every track:
1. Let track be the current MediaStreamTrack object.
2. End track. The track starts outputting only silence and/or blackness, as
appropriate.
3. Dereference track’s underlying media source.
4. If the reference count of track’s underlying media source is greater
than zero, then abort these steps.
5. Permanently stop the generation of data for track’s source. If the data
is being generated from a live source (e.g., a microphone or camera), then
the user agent should remove any active "on-air" indicator for that source.
If the data is being generated from a prerecorded source (e.g. a video
file), any remaining content in the file is ignored.

I'm not sure whether step (2) here implies all the steps in ended or not.
Since the spec says specifically to fire the event only if stop() wasn't
called, then my interpretation is that 'ended' should only be fired when
the track ends "naturally" with no stop() method called. So I think we
should be consistent with that.

****
>
> 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.)
>
> **
>

I think the recorder should avoid making commitments about latencies. Event
delivery will be async to actual recording activity, at least for machine
time scales.

My interpretation of the spec is that commands like pause() and resume()
are queued in order, so there's no ambiguity about the expected state if
pause() and then resume() are invoked, no matter how quickly -- the state
should always be 'recording' (assuming no other interfering events).
Perhaps we need some language around this in the spec? The MediaStream doc
uses "The task source for the tasks queued for the stop() method is the DOM
manipulation task source."




>  **
>
> **-          **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>
> 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****
>
>  ****
>
>  ****
>
> ** **
>