Re: revised recording proposal

Hi

I think this looks really good. Some comments below.

On 2012-11-19 22:14, 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
>

> 1.3 TimeInterval timeSlice
>
> The number of milliseconds of data to return in each dataavailable
> event. [Need more detail on this type, or a link to the relevant
> definition.]

We could simply align with the window timers [1] (setTimeout, 
setInterval) and use a long.

[1] http://dev.w3.org/html5/spec/timers.html#timers

> containerEncodingFormats of type sequence<DOMtring>
>
> A list of the container encoding formats that the platform supports.
> When setting this format, containerEncodingFormats="auto" may be used
> to select the platform default.
>
> audioEncodingFormats of type sequence<DOMtring>
>
> A list of the audio encoding formats that the platform supports. When
> setting this format, audioEncodingFormats="auto" may be used to
> select the platform default.
>
> videoEncodingFormats of type sequence<DOMtring>
>
> A list of the video encoding formats that the platform supports. When
> setting this format, videoEncodingFormats="auto" may be used to
> select the platform default.

The type would have to be (sequence<DOMtring> or DOMString) to support 
setting them to "auto". I think it's sufficient to say that not setting 
them (or an empty set) results in the platform default. Then we get rid 
of an error case (not set) and simple apps would get the default 
automatically.

Right now this interface supports getting the supported formats and 
setting the desired formats. Do we need a way to read back the selected 
formats? E.g.:

getSupportedRecordingOptions (was getRecordingOptions)
getRecordingOptions
setRecordingOptions

> recording 	MediaStreamEvent
> stoprecording 		
> dataavailable 	MediaStreamEvent
> recordingerror 	MediaStreamEvent
> recordingwarning 	MediaStreamEvent

recording Event (no payload)
stoprecording Event (no payload)
dataavailable BlobEvent (new type - name? - general name for re-usability)
recordingerror - depends on the payload data
recordingwarning - depends on the payload data

/Adam

Received on Tuesday, 20 November 2012 06:59:42 UTC