[vorbis] Re: [vorbis-dev] streaming FAQ
gtgbr at gmx.net
gtgbr at gmx.net
Wed Jan 29 12:29:55 PST 2003
Let's move this to vorbis@ where it belongs.
Graham Mitchell wrote:
> You know, we really need a streaming FAQ. There seem to be LOTS of
> undocumented command-line switches for oggenc that help in limiting bitrates
> that folks don't know about.
Actually, all the useful command line switches are documented. :)
> The recent thread with Derek at CD Baby brought out a lot of good info that I
> didn't know, and I consider myself fairly plugged-in. It would be helpful to
> have something like:
[...]
> Q: Okay, that worked, but I've decided I can live with the occasional
> millisecond of data over X kbps. How can I improve the quality?
The thing is that 99.9% *can* live with the occasional bandwidth peak -
that's what client-side buffers are for. It'd really suggest taking the
other approach of telling people how they can optimize their results
with the documented features, instead of telling them first how to break
Vorbis. There aren't many applications and devices that a typical
consumer sees that require absolute CBR, and streaming (even at low
bitrates) doesn't belong to those. If this FAQ contains a question "I
want to use Vorbis on <device> and its chipset/whatever requires
absolute CBR - it has a tolerance of n milliseconds, how can I achieve
that?", then the first part of the answer must be "Note that Vorbis
wasn't designed to do this.". I'd rather be honest and helpful by saying
"<x> does a much better job, use <x>" than make people hate Vorbis
because they tried it in an enviroment where it's not meant to work.
I just tried the advanced option "bitrate_average_window" and set it to
both 0.05 and 0.001 seconds, and used both -m and -M. While my test
bitrate of 96kbps was never exceeded in my test, it dropped as low as
88kbps according to Winamp in one place. :P This means that either -m
doesn't work properly, or the bitrate_average_window doesn't quite work
for the minimal bitrate. Odd enough, by using this option I greatly
increased the overhead - the smaller the window, the bigger the
resulting file. I don't know whether this is due to Ogg or Vorbis...
maybe someone can shed some light on this. If it's Ogg, libogg2 or a
completely different transport might be able to fix this.
Ah well, all I mean is that all this shows that Vorbis is not designed
for CBR and those advanced options are undocumented for a reason.
Together with the bitrate management engine (assuming it's not being
abused with advanced options), the current implementation of Vorbis
allows its use in a huge majority of possible cases. Except for a few,
and it doesn't *have* to work there, imo.
I suggest, to the one who has the time to write the FAQ, that only
documented features are being discussed. There are many people out there
who think they're doing something extremely cool by messing up Vorbis'
great default settings. That's also the reason why many lame encoded
MP3s sound crappy, although --alt-preset provides excellent results.
People always try to look smarter than they are. :)
<p>Moritz
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Vorbis
mailing list