[xiph-rtp] header caching and chaining

[Ralph Giles]

On Mon, Feb 07, 2005 at 01:18:35AM +0000, Phil Kerr wrote:

> I think Derf was talking about Theora, not Vorbis, but from what I 
> gathered he listed the maximum permutations for all the config fields.  
> In practice there will be a large number of permutations that will never 
> be seen.

He was. I didn't necessarily agree with his feelings about the relative 
danger of collision, so I generalized the argument. :)

> When the idea came up for using a CRC32 field there seemed to be no real 
> objections to it, perhaps we should find out what the frequency of hash 
> collisions are in real-life?

The problem is it's hard to judge because this depends on the behavior 
of future encoders. I'm more worried about custom codebooks generated by 
more advanced multipass theora encoders. I guess I do agree the issue is 
probably more important for theora than for vorbis.

OTOH, caching seemed like a major win on the whole chaining thing.

> >So, the only way around this is to not cache the headers. We could just 
> >say that, but doing so breaks the broadcast use case where play-time 
> >retrieval isn't an option.
>
> This is a solution, but does it harm functionality too much?

I think so. We have people interested in satellite broadcast of 
vorbis+theora right now. That use case is important.

> >The other thing we can do is just make it an arbitrary number and say 
> >that the sender and receiver MUST negotiate a mapping between the ident 
> >and the decoder setup out of band, and just leave it out of the scope of 
> >the RTP mapping (beyond the in-band transmission option anyway.) This 
> >should work fine for the SDP uri and so on.
> >
> If there is no caching then this will work as there only needs to be a 
> unique ident for each file for the session life.  How do you ensure that 
> the arbitrary numbers are unique?  Would ov_serialnumber be unique enough?

Well, it would be up to the server to make sure it didn't reuse an ident 
for two different decoder configs within a given RTP session. Otherwise, 
it's arbitrary. That enforces no caching based on the ident, and isn't 
much of a burden for the server.

IMHO,
 -r