Vorbis - Dec 2004 - ogg123 and Vorbis piped to stdin

Moin,

Two questions I have.

Actually, the first isn't so much a question.  It seems that `ogg123'
is not able to play streams from stdin, at least not for me on FreeBSD.

It also seems that with the patches way down below, it can play from
stdin for me -- I handle stdin like http-transport and return the
same values for seeking and the like, to avoid calls that fail, and
so it works, though I'm probably not doing it right.  Review is urged.


Second, I've noticed that `ogg123' isn't able to play streams that
do not start with an Ogg header or such -- for example, long ago,
when I tried to stream an Ogg Vorbis file by the same means I was
streaming mp3, it didn't work -- unless I used the software which
inserted the header before streaming the data on the proper
bondaries.

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
getting the frame header right?

The purpose being to coarsely chop up some ogg files, as well as to
play files which unpatched-ogg123 isn't able to handle well (large
files, f'rinstance)


Thanks.  And below, my hacks to be able to play from stdin:

--- file_transport.c-DIST	Sun Aug 22 20:33:26 2004
+++ file_transport.c	Mon Dec 20 12:38:51 2004
@@ -84,6 +84,11 @@
   int items;
   long start;
 
+/* XXX HACK special-case stdin */
+  if (private->fp == stdin)
+    return 0;
+/* XXX */
+
   /* Record where we are */
   start = ftell(fp);
 
@@ -118,6 +123,11 @@
   file_private_t *private = source->private;
   FILE *fp = private->fp;
 
+/* XXX HACK special-case stdin */
+  if (private->fp == stdin)
+    return -1;
+/* XXX */
+
   return fseek(fp, offset, whence);  
 }
 
@@ -134,6 +144,11 @@
 {
   file_private_t *private = source->private;
   FILE *fp = private->fp;
+
+/* XXX HACK special-case stdin */
+  if (private->fp == stdin)
+    return 0;
+/* XXX */
 
   return ftell(fp);
 }


barry bouwsma

Barry Bouwsma wrote:
> Second, I've noticed that `ogg123' isn't able to play streams
that
> do not start with an Ogg header or such -- for example, long ago,
> when I tried to stream an Ogg Vorbis file by the same means I was
> streaming mp3, it didn't work -- unless I used the software which
> inserted the header before streaming the data on the proper
> bondaries.
> 
> 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
> getting the frame header right?
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).

Streaming tools like icecast have to cache these headers and insert them 
into the beginning of the stream for new clients when they first connect.

Vorbis itself has no concept of the "frame header", though the Ogg 
container it usually lives in is composed of "pages" which have
headers.
  Once the Vorbis codec has been initialized with the approprate 
codebook headers, you could jump to a random point in the file and scan 
ahead until the next Ogg page and resume decoding from there.

---
Stan Seibert

[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