W3C home > Mailing lists > Public > public-media-capture@w3.org > November 2012

Re: revised recording proposal

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 28 Nov 2012 22:49:53 +0100
Message-ID: <50B68701.4070909@alvestrand.no>
To: public-media-capture@w3.org
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
>
>
>
Received on Wednesday, 28 November 2012 21:50:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:12 UTC