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