[xiph-rtp] header caching and chaining

[Aaron Colwell]

On Thu, Feb 03, 2005 at 04:50:12PM -0800, Ralph Giles wrote:
> On Thu, Feb 03, 2005 at 04:37:59PM -0800, Aaron Colwell wrote:
> 
> > Yes. Since SDP forces the number of streams to be constant, you can't support
> > changing the number of logical streams unless you do SSRC multipexing over a
> > single RTP channel. I'm fine with not supporting those types of stream since
> > hopefully they are rare. For on-demand content you could support these files
> > by figuring out the max number of Vorbis and Theora streams needed and 
> > advertise that many streams. You just don't send data on some of the streams 
> > when they aren't needed. This is basically how I support these types of files
> > in the Helix Plugins.
> 
> Ok, thanks. That helps.
> 
> > For live this could be ok, but for on-demand, transcoding won't scale 
> > eventhough audio is less expensive to transcode than video.
> 
> Is there a reason to use RTP instead of HTTP for on-demand work??

I don't really want to start a huge thread about this. I just want to say that
there are several streaming servers out there that use RTP for on-demand. 
They can serve all sorts of other datatypes fine. Why make Vorbis and Theora
exceptions? A server can choose not to support these types of files if it 
doesn't want to deal with the added complexity. If chained stream are somehow
marked in the SDP, then the client can opt not to play them back. It just
seems to me that making all streaming methods have equivalent functionality
is beneficial and doesn't limit the the distribution mechanisms you can use.

Aaron 


> 
> > I'm not sure what you mean about "a more expensive version of the fixed-info 
> > packet config". I think it just means that if you want to support changes in
> > the info header then you need to have the CRC cover the info header and 
> > codebook. If you just want to switch out the codebook then it will work fine.
> > Since the frame-rate info is in the ident header this would mean fixed 
> > frame rate for video and fixed sample-rate and channels for audio.
> 
> That's what I mean. :-)
> 
>  -r
>