[whatwg] need a way to set output format from StreamRecorder

Incidentally, I agree that recording audio should best be kept to an
uncompressed format, because I can see great browser applications for
audio editing.

As for choosing a single codec - if we end up not being able to agree
on a single compressed codec for audio/video streaming, we will get
into a situation where all your involved parties in a video or audio
conference have to use the same browser (or select from a restricted
group of browsers only) for a live communication. I guess it's
workable, but kinda strange for an open platform like the Web.

Cheers,
Silvia.


On Sun, Nov 28, 2010 at 7:20 AM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> 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" [1] 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
> http://www.ietf.org/mail-archive/web/codec/current/msg02029.html .
>
> Cheers,
> Silvia.
>
> [1] http://datatracker.ietf.org/wg/codec/charter/
>
> 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
>> http://developer.apple.com/quicktime/icefloe/dispatch020.html
>> 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.
>>>
>>>
>>> Greetings,
>>> --
>>> Nils Dagsson Moskopp // erlehmann
>>> <http://dieweltistgarnichtso.net>
>>
>>
>

Received on Saturday, 27 November 2010 12:26:58 UTC