[xiph-rtp] Re: header caching and chaining

[Ralph Giles]

On Thu, Feb 03, 2005 at 02:02:53PM +0000, Phil Kerr wrote:

> I think the most compelling argument you give is the last pro point 
> concerning re-encoding.  But the frequency  of re-encoding needed for 
> audio should be a lot higher so the re-encoding strain for audio may be 
> as high as for video.

Not really. Video's two extra dimensions tends to make up for the 
smaller sampling rate. Or, looking at it another way, it's not 24 frames 
a second, it's 8 (or 50) million pixels a second.

> So, just to get this straight, the core objection is which header is 
> being hashed, not that hashing is being done?

Well, I'm trying to frame the decision. We have:

 0. No hashing. All decode parameters are fixed for the duration of the
    RTP stream. 
 1. Hash the setup header only: codebooks can change doing a stream,
    but not parameters like sample rate, framerate, image size, etc.
 2. Hash the info and setup headers together: all decoder parameters
    can change.
 3. Hash all headers. the setup ident carries metadata changes as well.

Of these, I think (0) and (2) are the only reasonable options for the 
reasons we've been discussing. I think 2 makes chaining work reasonably 
for the use cases I've posited, so we're just down to the feature cost 
and aesthetics.

A question: is there now or can we define some method to direct the 
client (through rtsp or whatever) to connect to a different stream?
I ask in all ignorance. That would handle the case of the number of 
streams changing, which is I think quite important for conference 
webcasts and the like.

> If the whole chaining mechanism is to go then, although it does make the 
> whole structure a lot easier, it does lose a significant amount of 
> functionality.  People will compare the RTP implementations to Icecast, 
> and if it isn't on par people will not be happy.

Well, I don't actually know anyone who does the bitrate-fallback thing 
with icecast. That just leaves needing to transcode when doing 'fake' 
live streaming from a mixed-encoding set of files. The tools can do that 
automatically, so most people won't notice. I think the additional cpu 
cost is worth the simplification as far as icecast regression goes.

 -r