[xiph-rtp] header caching and chaining

[Aaron Colwell]

On Thu, Feb 03, 2005 at 04:06:10PM -0800, Ralph Giles wrote:
> On Thu, Feb 03, 2005 at 09:08:11AM -0800, Aaron Colwell wrote:
> 
> > I think one other Pro is that you would be able to stream a larger set of
> > valid .ogg files over RTP. Unfortunately this still won't let you stream all
> > valid .ogg files, but it is getting closer.
> 
> Do you mean Ogg files that change the number of multiplexed logical 
> bitstreams between chain boundaries? That's the only thing I can think
> of that we're not covering.

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.

> 
> > Why is it more beneficial for video than audio? I'm assuming you want chaining
> > for video to allow frame rate changes and codebook changes to allow better
> > bitrate characteristics. Couldn't these same arguments be held for audio as 
> > well? If you have audio that only has low frequency components it may make 
> > sense to use a lower sample rate.
> 
> My analysis was based on transcoding being much more expensive and 
> difficult for video. Remember I'm against RTP chaining support in
> the first place; the video framerate issue was pretty much the lever
> argument for me.

For live this could be ok, but for on-demand, transcoding won't scale 
eventhough audio is less expensive to transcode than video.

> 
> > I'm not sure if the 2 headers are orthogonal in Vorbis. You need to know the
> > channels value from the info header to properly decode the setup header. This
> > will constrain you from changing the number of channels across chain boundries.
> > The block sizes are also stored in the info header so that wouldn't be able to
> > change across chain boundries either. These 2 constraints seem to me to 
> > severely limit the usefulness of chaining support if you can only update the
> > setup header.
> 
> Right. Teaches me to not do my homework. In light of this I agree with 
> you that hashing both the info and setup packets and using that as the 
> ident key is the best approach.
> 
> > I haven't read his proposals yet (I'll try to get to this today), but the
> > way you describe it doesn't sound like it would work. What happens in the case
> > where you use the same setup header, but a different frame size or frame rate?
> > The CRC wouldn't change so the client wouldn't know that these parameters
> > changed. Depending on how the frame size changed, frame decode could fail
> > because there are either too many or too few coded coeff, block coded flags, 
> > etc.
> 
> Insightful as always. So unless I missed something in my description, 
> this is just a more expensive version of the fixed-info packet config.

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.

Aaron


> 
> Thanks,
>  -r
>