- From: Jim Barnett <Jim.Barnett@genesyslab.com>
- Date: Fri, 7 Dec 2012 16:24:03 +0000
- To: "Mandyam, Giridhar" <mandyam@quicinc.com>, Martin Thomson <martin.thomson@gmail.com>
- CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
I don't follow your argument. Certainly some platforms will support multiple formats, and in those cases the application needs to be able to pick the one it wants. So I still think we need AvailableRecordingFormats and the associated Get/Set. In the case of devices that don't allow selection, that list will be of length one, and there'll be no point in calling the Set, but there's no need to require all devices to be that limited. We will need to Get/Set Dimensions, but it should be nested under video somewhere, since it doesn't make sense for audio. Are there other parameters that we should define? Once we have a complete set, it will be easier to come up with a syntax (and, yes, it will probably look a lot like constraints). - Jim -----Original Message----- From: Mandyam, Giridhar [mailto:mandyam@quicinc.com] Sent: Friday, December 07, 2012 11:16 AM To: Martin Thomson Cc: Jim Barnett; public-media-capture@w3.org Subject: 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:24:32 UTC