[Vorbis] ogg123 and Vorbis piped to stdin

[Ralph Giles]

On Sat, Dec 25, 2004 at 04:13:04PM +0100, Barry Bouwsma wrote:

> 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.

Indeed. Ogg streaming over HTTP works very well, but is a poor 
application for multicast or broadcast use. So is Ogg itself,
really; the error detection granularity is really more coarse
than you want for an unreliable transmission medium.

We do intend for these applications to work with Vorbis, but
not with Ogg. There's a new RTP Vorbis encapsulation draft in
development right now, which we hope will address those same
issues, primarily by allowing cached headers and out-of-band
retrieval. You might join the xiph-rtp mailing list and contribute
to the discussion if you have expertise/interest in this area.

See also 

  http://svn.xiph.org/trunk/vorbis/doc/draft-kerr-avt-vorbis-rtp-04.xml
  http://wiki.xiph.org/index.php/VorbisRTP

> 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.

Yes. The keyframe+delta format of most video codecs is a quite
similar issue, except that you can't really argue the periodic
keyframes are 'wasted' bandwidth. I actually expect the way
this will be solved in practice, at least for broadcast, is to
have multiple decoders operating speculatively.

> 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.

We've traditionally felt multicast support was a low priority,
precisely because of the vanishingly small deployment among
consumer broadband connections. If that changes of course it
will become very important.