On Sun, May 30, 2010 at 6:01 PM, James Salsman <[email protected]> wrote: > It's hard for me to take http://www.w3.org/TR/capture-api/#formatdata > seriously. There are no references to open codecs or codec > parameters; the only audio codec specified is audio/x-wav, which is a > Microsoft-defined union type (RIFF) with a huge number of different > possible instance types, including only a few poor quality open > vocoders and audio codecs by contemporary performance/bandwidth > standards. Where is speex or ogg vorbis? Where are their quality and > bit rate parameters? Why is http://www.w3.org/TR/capture-api/#future > empty when most of the normative sections say, "No exceptions"? Where > is the compatibility with existing file transfer standards? The > security section doesn't contemplate permissions revocation. > > If audio were segmented into separate files as per > http://www.w3.org/TR/capture-api/#captureaudiooptions how would that > affect real-time performance on mobile devices? Are these files > required to have sequence numbers? With phase vocoder time shifting, > UDP delivery as per http://dev.w3.org/html5/html-device/#stream-api > would be far superior in quality and intelligibility under packet loss > or delay, assuming they went with an open audio codec (or, even > better, allowed a choice of speex or ogg vorbis.)
To be clear I'm not advocating for one particular capture API or codec; rather I'm advocating that capture and record not be tied to network transport, and separately that the p2p network transport be flexible, low-level, low-overhead and have a minimal attack surface (suitable for real-time game data as well as audio/video). Where is the discussion regarding phase vocoder time shifting and UDP delivery? I didn't see it in the stream-api section. Cheers, Mark
