Re: revised recording proposal

On 11/28/2012 11:00 PM, Jim Barnett wrote:
>
> Harald,
>
> I see that you may be thinking of another case – one where the app has 
> called startRecording(), but recording has not yet begun, and now 
> calls stopRecording().  Yes, in this case the UA should raise an 
> (empty) dataavailable event followed by recordingdone, and stop 
> recording.
>
Aha! That's what I thought.
>
> I was talking about the case where the app has _/not/_ called 
> startRecording(), but then calls stopRecording() anyway.
>
I would throw a state error exception (is there such a thing?) - this is 
a programming error.
>
> In general it’s an empirical matter when recording actually starts 
> once startRecording() is called, but from the point of view of the 
> API, the Recorder object should behave the same whether or not it has 
> actually got some data in its internal buffers.
>
Agreed. Fewer special cases to deal with.
>
> -Jim
>
> *From:*Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
> *Sent:* Wednesday, November 28, 2012 4:54 PM
> *To:* Harald Alvestrand; public-media-capture@w3.org
> *Subject:* 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 <mailto: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
>
>
>