[Theora-dev] Directshow filters 0.64.7878

[Michael Smith]

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. 

Mike