[whatwg] <device> element, streams and peer-to-peer connections

On Sun, May 30, 2010 at 6:01 PM, James Salsman <jsalsman at gmail.com> 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

Received on Monday, 31 May 2010 07:07:37 UTC