[whatwg] need a way to set output format from StreamRecorder
silviapfeiffer1 at gmail.com
Sat Nov 27 12:20:37 PST 2010
In deed for audio all browsers except IE9 currently support WAV in
their media elements, which makes it a reasonable recording format and
acceptable for saving to the server. For communication between browser
instances - in particular when used for conferenceing - I can see the
need for a compressed format.
Speex is a reasonable low-bandwidth codec, but for speech only and not
for general audio. I would wait with choosing a low-bandwidth codec
until the IETF's new "Internet Wideband Audio Codec"  Working Group
finalizes their codec definition, since that will be a low-bandwidth
codec not restricted to speech. It will be an unencumbered codec
called "Opus" and is making great progress, see
On Sun, Nov 28, 2010 at 6:51 AM, Kevin Marks <kevinmarks at gmail.com> wrote:
> For Audio at least, supporting uncompressed should be possible and
> uncontroversial, as there are clearly no patent issues here. Anyone serious
> about recording and processing audio would not consider recording compressed
> audio nowadays. T
> There are several widely used raw audio formats (.au, WAV, AIFF, AVI) that
> can wrap into a filestream, and there are of course the issues of sample
> rate, channel count and bit resolution, but compared to codec issues these
> are relatively straightforward from an engineering point of view, and not
> tied up with licensing issues.
> Raw video is more of a problem at present, given common bandwidth
> constraints, but if we are interested in providing for image manipulation
> APIs, having pixel formats that map to video better than RGBA may be needed.
> The enumeration at
> may be helpful here.
> On Fri, Nov 26, 2010 at 11:10 AM, Nils Dagsson Moskopp
> <nils-dagsson-moskopp at dieweltistgarnichtso.net> wrote:
>> Silvia Pfeiffer <silviapfeiffer1 at gmail.com> schrieb am Thu, 25 Nov 2010
>> 20:01:37 +1100:
>> > Also, implementing WebM or Ogg Theora encoding is just as royalty-free
>> > as decoding them, so Mozilla, Opera and Google wouldn't need to worry
>> > there.
>> Slightly offtopic: Anyone considering the low-bandwith audio use case?
>> Surely, speex might be useful here — even a throttled UMTS connection
>> suffices for VoIP.
>> > So, the browsers would implement support for those codecs for which
>> > they already implement decoding support - maybe with the exception of
>> > Chrome which decode MPEG-4, but may not want to encode it, since it
>> > might mean extra royalties.
>> And probably less WebM content, too boot. Decoding, but not encoding
>> MPEG formats could certainly fit into a royalty-free formats agenda,
>> depending on the level of aggressiveness Google is wishing to take.
>> > It would be nice if we could all, say, encode WebM, but I don't see
>> > that happening.
>> I see what you did there.
>> Nils Dagsson Moskopp // erlehmann
More information about the whatwg