[Vorbis] ogg123 and Vorbis piped to stdin

[Barry Bouwsma]

[taken from the web mailman archive -- is it just me, or are the
 in-reply-to references in the HTML source messed up?  Other sites
 see the same problem, though.  Anyway, the message ID of Stan's
 reply to my original message is missing, sorry, so threading is
 certain to be broken...]


> > Now, I see the same thing using stdin, if I'm trying to seek within
> > an Ogg Vorbis file with `dd' piped to my hacked `ogg123'.  Should it
> > in theory be possible for `ogg123' to do the same thing on an Ogg
> > stream that, say, `mpg123' does, which is to seek until a passable
> > frame header is found, and then try to play that, sometimes even

> This isn't a limitation of ogg123, but rather a limitation of Vorbis. 
> Vorbis has 3 header packets which are required in order to be able to 
> decode the bitstream.  Unlike MP3, which has frame headers periodically, 
>   Vorbis headers occur only once at the beginning of the stream because 
> they can be rather large (usually ~4kB).

Thanks for that info -- that was the missing link, which I probably
would have found if I bothered to read all the documentation.

So I'll need to use a special tool rather than `dd' to cut Ogg Vorbis
files down to size, such as `vcut' -- at least from the beginning of
the file.


Then I got to thinking, what about streaming applications for Vorbis
where one does not have a one-to-one sender-recipient ratio for
which cached headers are practical?  I'm thinking of multicast or
broadcast; the latter which nowadays usually employs MPEG layer 2
around here.

Listeners to such a stream would be in effect popping in right in
the middle, missing the required headers, like I've been doing with
my `dd' trick.  It sounds like these important applications aren't
going to work.

This has no doubt already been discussed somewhere...

It sounds as if, should I want to use vorbis format in a future
digital broadcast medium, say, via satellite, that the only way
to do so would be to insert these ~4kB headers periodically in
the stream -- if this is even possible, I'm assuming the wasted
size of the redundant info in traditional streams is the only
thing preventing it from being done.

In the case of MPEG Layer 2 audio via satellite, it's possible
today for one to jump between audio streams on the same transponder
multiplex in a small fraction of a second, although few of the
consumer products out there today seem to be able to do this in
much less than a second.  MPEG video takes a bit longer, and this
delay, compared with the almost-instantaneous switching one gets with
the analog TV and radio around here, is one of the biggest complaints
people as consumers have about embracing DVB technology.

Of course, for Internet 'casting, where bandwidth is a concern,
or limited processing power, I'm sure that a source with, say,
tens or more thousands of listeners is going to prefer some
multicast for practical reasons.  On the other hand, most people
who listen to audio streams via the net are already accustomed to
a delay before any sound can be heard, so I'll stick with broadcasting.

If I were to want to theoretically broadcast with Vorbis in place
of a decent mp2 stream which typically is sent at 192kbit/sec,
I could probably get away with the default -q3 vorbis quality, or
about 112kbit/sec average.  To that, I'd have to add the headers
frequently.  If a delay of up to half a second is tolerable, I
can add two sets of those ~4kB each second and roughly match the
bitrate of the layer 2 MPEG audio stream.  That still isn't as
good as a few receivers offer when switching DVB audio channels,
and would probably be bothersome to some -- there's undoubtedly
more delay within the decoder until it can put out audio.  If I
aim for every-1/4-second headers, I'll probably be around the
bandwidth of a few premium 256kbit/sec mpeg audio streams that
some classical radio stations use, for which perhaps a higher
vorbis quality level would be appropriate.

This sounds like a bit of a drawback for the possibility of vorbis
in large-scale broadcasting, unless I'm overlooking something.  Also,
how capable would a vorbis decoder be at handling a corrupted-in-
transit stream, and re-synchronizing itself after a brief signal
dropout, when the underlying transport can't deliver an error-free
stream?


And the same for multicasting.  I could probably get away with
redundant headers every few seconds here, if my experience joining
an internet stream is any indication, without unbearably annoying
any newly-joining listeners.  Here is where I see more potential,
say, a large ISP and a popular radio station join up and want to
supply all the ISP customers with a chance to hear the station on
their high-bandwidth connections, without needing to scale up a
streaming server.


As I'm certainly missing something, pointers to the appropriate
references will be appreciated.


thanks
barry bouwsma