[Theora-dev] Directshow filters 0.64.7878
msmith at xiph.org
Tue Oct 5 20:10:17 PDT 2004
On Tuesday 05 October 2004 21:06, Thomas Vander Stichele wrote:
> > The conditions under which i can get chaining to work with this hack
> > are...
> > a) The stream is non-seekable.
> > b) Each chain contains the same number and type of codecs with the same
> > settings (ie can't change the samplerate or the number of channels)
> > c) The stream is valid.
> > Which as far as i know this means it should be fine for icecast.
This is mostly ok - icecast will generally happily change around codec
settings (sample rate, number of channels) on the fly, but most (and possibly
all) clients don't support that, so in practice streams don't do this. I
don't think this limitation is at all problematic. However, some icecast
streams DO change the codebooks, so you do need to properly reinitialise the
libvorbis decoder with the new headers.
> Personally, I'd already be happy if it could play a non-chained network
> stream. I understand how chaining is important for icecast, but I
> personally like the one-chain approach more. Really, chaining oggs
> together is just a bad way of doing a radio anyway, you want to have
> mixing done.
In practice, I find that chained streams are 'neccesary' for two purposes:
- streaming pre-existing collections (already encoded). Commonly, these will
be homogenous enough (same codebooks, headers, etc.) that a smarter program
could get away without chaining for this, except for...
- metadata. Right now, we don't have a client-supported way of doing
metadata except by sending the initial headers again (i.e. a new stream). And
people really want to be able to update the metadata on the fly.
Actually getting a _client-supported_ (this makes it much, much harder,
obviously!) mechanism to do metadata updates without the rest of this stuff
would be terrific.
More information about the Theora-dev