RE: revised recording proposal

My argument is that in practice it could be a useless feature, and that there is also potential for UA implementation error if the Blob.type is not equivalent to the advertised or selected format.  

Moreover, it seems that we have already made a decision on other API's such as takePicture() that selection of encoding format is not important.  

Regardless, it is not a big issue to keep or leave out recording formats.  I'm OK with keeping it in if there is a desire by the group to do so.  

I agree that setting recording dimensions for video can be done similar to constraints.  I am not able to come up with constraints for audio, because the settable attribute of interest for audio (gain) is performed on the Audio Source.

-----Original Message-----
From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com] 
Sent: Friday, December 07, 2012 8:24 AM
To: Mandyam, Giridhar; Martin Thomson
Cc: public-media-capture@w3.org
Subject: RE: revised recording proposal

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:34:35 UTC