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

RE: revised recording proposal

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>
Message-ID: <57A15FAF9E58F841B2B1651FFE16D281D46B@GENSJZMBX01.msg.int.genesyslab.com>
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);


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

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