[whatwg] default audio upload format (was Fwd: The Media Capture API Working Draft)

[James Salsman]

On Tue, Aug 31, 2010 at 11:24 PM, Roger Hågensen <rescator at emsai.net> wrote:
>  On 2010-08-31 22:11, James Salsman wrote:
>>
>> Does anyone object to form input type=file
>> accept="audio/*;capture=microphone" using Speex as a default, as if it
>> were specified
>> accept="audio/x-speex;quality=7;bitrate=16000;capture=microphone" or
>> to allowing the requesting of different speex qualities and bitrates
>> using those mime type parameters?
>>
>> Speex at quality=7 is a reasonable open source default audio vocoder.
>> Runner-up alternatives would include audio/ogg, which is a higher
>> bandwidth format appropriate for multiple speakers or polyphonic
>> music; audio/mpeg, a popular but encumbered format; audio/wav, a union
>> of several different sound file formats, some of which are encumbered;
>> etc.
>
> Actually, wouldn't accept="audio/*;capture=microphone"
> basically indicate that the server wish to accept anything as audio?

Yes; that doesn't encourage implementors to implement. However, as it
was agreed on by two different browser developer representatives, it's
the best way forward.

> The proper way however would be to do:
> accept="audio/flac, audio/wav, audio/ogg, audio/aac,
> audio/mp3;capture=microphone"
> indicating all the audio formats the server can handle.

I agree that the specifications should allow a comma- or
space-separated list of MIME types. I have no idea why that was
specifically disallowed in the most recent HTML5 specification, and
think that decision should be reversed before publication. I also
think "capture" would work a lot better as an attribute of the input
type=file element than a MIME type parameter.

> Although I guess that audio/* could be taken as a sign that the browser
> should negotiate directly with the server about the preferred format to use.
> (Is POST HEADER request supported even?)

Not for multipart/form-encoded input type=file uploads, sadly. There's
a way to do that specified in http://w3.org/TR/device-upload with the
"alternates" form POST parameter which the browser would send back to
the server when the requested type(s) were unavailable. I guess that
is a content negotiation feature, but it seemed unlikely that people
would need it for that because ideally the server would specify all
the types it could accept, as you pointed out.

Best regards,
James Salsman