RE: revised recording proposal

Apologies in advance for prolonging an argument.

I assume we would want the recording API to be as universal as possible.  Many recorder apps on handheld devices today do not support selection of either the container or encoding formats.  Moreover, if the application needs information on the supported recording format then this  should be discernible from the returned Blob.type attribute. 

I view this as somewhat analogous to the our current direction on takePicture(), where the image can be returned in compressed format but the format itself is not a settable attribute.

Width/height are important for recording and we should get that right.  Once again, many native media recorders support selection of width/height from a list of acceptable combinations for display size or MMS inclusion, but will not support the ability to select an arbitrary length and width. 

I would suggest changing AvailableRecordingFormats to AvailableRecordingDimensions.  The returned objects could represent a set of valid width/height combinations.  

dictionary RecordingDimensions {
 (unsigned long) width;
 (unsigned long) height;
 }

interface AvailableRecordingDimensions {
 readonly attribute unsigned long length;
 RecordingDimensions item (unsigned long index);
 }

-Giri

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Thursday, December 06, 2012 9:43 AM
To: Mandyam, Giridhar
Cc: Jim Barnett; public-media-capture@w3.org
Subject: Re: revised recording proposal

On 6 December 2012 07:48, Mandyam, Giridhar <mandyam@quicinc.com> wrote:
> get/set recording options.

As raised on the call by Travis (and for the email record).  We need to set width and height for recording in the same way that we do as for video.  Whatever makes a recording sink equivalent to a <video> tag.

Received on Friday, 7 December 2012 16:16:40 UTC