[xiph-rtp] header ident decision

[Ralph Giles]

On Tue, Apr 05, 2005 at 08:28:29PM -0700, Ralph Giles wrote:

> Therefore I'd propose the following payload header:
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |           Setup Ident         |   Reserved    |C|F|R| # pkts. |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 

Discussion on this point seems to have petered out. I'm going to decide 
executively in favor of this proposal rather than Aaron's, with the 
blessing of Fluendo. Phil, please (again) update the draft to reflect 
this new payload header, and Aaron's changes to the meaning of the C,F 
bits.

Rationale for the record: Aaron's variable-length setup ident encoding 
is much more flexible, but also adds complexity. While it's true that's 
nothing compared actual vorbis or theora decode, the packetizer is not 
necessarily an integral part of the decoder. I'm particularly worried 
about the additional decision overhead for embedded use, where the fix 
32 bit alignment makes things dead easy. It's also a stronger decision 
against the 32 bit CRC proposal, preventing any kind of application-
specific fallback. Finally, next to the 32 bit SRC id's and timestamp 
in the RTP header itself, the 3 byte overhead for non-chained streams
felt like a reasonable balance to me.

So there we go, progress!

I've made no decision on the out-of-bound setup transmission issue 
though. Storage formats, levels of indirection and so on are still up
in the air. Really, I'd like to see some implementations try different
things.

One this I think we can define is in-band transmission. Just send the
header packets in the RTP stream like they were any other type. The 
16 bit setup ident field of the header packets must match the setup 
ident of the data packets that rely on them. In the default case the 
three standard headers are sent at the beginning of the stream, just
as they are in Ogg. The server MAY also retransmit the headers 
periodically; clients MUST handle such header packets when they occur.

 -r