- From: James Salsman <jsalsman@gmail.com>
- Date: Wed, 1 Sep 2010 08:21:31 -0700
- To: rescator@emsai.net
- Cc: whatwg@lists.whatwg.org, public-device-apis@w3.org
On Tue, Aug 31, 2010 at 11:24 PM, Roger Hågensen <rescator@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
Received on Wednesday, 1 September 2010 15:22:04 UTC