[xiph-rtp] header caching and chaining

[Ralph Giles]

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.

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

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

Thanks,
 -r