RE: revised recording proposal

Harald,
But in this case, there is no recording going on, so it can't stop.  If we raise recordingerror in this case, we should raise dataavailable and recordingdone as well, but there will never be any data in the dataavailable event, and I think it's questionable to raise recordingdone when we haven't raised startrecording.  That's why I think recordingwarning makes more sense.   In general we can use that event in cases where the Recorder isn't in the right state to execute the command.


-          Jim

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Wednesday, November 28, 2012 4:50 PM
To: public-media-capture@w3.org
Subject: Re: revised recording proposal

On 11/28/2012 10:41 PM, Jim Barnett wrote:
Harald wrote:  "- Does stopRecording() cause the UA to fire a "dataavailble" event in all cases, even if recording hasn't started yet? (I think so, for consistency)"
I've been thinking about this case and wonder if the UA shouldn't raise a recordingwarning event in this case instead.  In general, the semantics of the warning event seem to be "I'm ignoring what you just asked me to do and am continuing doing what I was doing before".  The best example of this that came up at the F2F was adding a Track while recording was going on while recording to a container format that didn't permit this.  In this case the UA would raise a recordingwarning event and keep recording the original set of tracks.

So in this case, you could argue if stopRecording is called while recording isn't going on,  then the UA's response should be "I wasn't doing anything so I can't stop so I'll ignore your request to stop and continue doing nothing" - and that would imply a recordingwarning event.
I would expect it to actually stop recording (no data should be delivered, ever).

That doesn't seem like the kind of event you raise a warning for.




-          Jim

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Saturday, November 24, 2012 12:29 PM
To: public-media-capture@w3.org<mailto:public-media-capture@w3.org>
Subject: Re: revised recording proposal

On 11/19/2012 10:14 PM, Jim Barnett wrote:
Here's my latest revision of the recording proposal, based on discussion in Lyon and on the list.  The main difference from the previous proposal is that I've moved recording into its own MediaRecorder class, with a constructor that takes a MediaStream as an argument.  I've kept a single record function with an optional TimeSlice argument, because that seemed to be the most popular choice.  There are questions scattered throughout in brackets [].    The treatment of errors is extremely vague, but I think that's a reflection of where we are.

Please send me any comments.


-          Jim
thanks for supplying this!
I like it - and I think it's implementable.

Some comments, worries and nits:

- the text for "record" refers to "raise a recordingerror event", but there is no "onrecordingerror" event handler. Neither is the "onrecordingwarning" specified in 1.5
- The term "The UA must record each Track within the MediaStream separately" is ambiguous to me. For instance, stereo encoding as a+b / a-b combo - is that "separate" or not? I think "in such a way that the original tracks can be retrieved at playback time" might be less ambiguous.
- Does stopRecording() cause the UA to fire a "dataavailble" event in all cases, even if recording hasn't started yet? (I think so, for consistency)
- Do we need a "setSyncPoint()" operator and a "syncpoint" signal, so that the client can tell the recorder to insert a point at which a recording can be broken up (typically a new I-frame)?
- Why does it make sense to set audiorecordingformat and videorecordingformat separately? I know we need to support container formats with options for codecs, but I don't think these are independent entities - having a "parametervalues" argument might be a cleaner way to do it.

But I think this is good enough for a first version of a document - please format it and send it in, and we can start the process of asking Dom how we do a FPWD publication of it!

              Harald