[xiph-rtp] header ident decision

[Aaron Colwell]

On Sun, May 01, 2005 at 09:52:56AM -0700, Ralph Giles wrote:
> On Tue, Apr 05, 2005 at 08:28:29PM -0700, Ralph Giles wrote:
> 
> 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.
> 
> 
When you say "embedded" are you refering to a hardware implementation of this
packetization scheme or just it's use in an embedded device? If it's the later 
then I don't see the tiny bit of extra complexity something to worry about. 
Robust sorted and interleaved AMR-NB packetization (RFC 3267) is WAY more 
complex than this and I've had it running perfectly fine on a 104MHz ARM that 
is also doing H.263 decoding at the same time. Most multimedia embedded devices
these days have more horsepower than this so I don't think that the variable
length ID is that big of a complexity overhead.

Is it really likely that a hardware encoder will actually use 
several chains in a single transmission? If not then there is no extra 
complexity for the variable length field. If your doing hardware
decode it seems likely to me that depacketization and RTCP ops would be done
by a general purpose processor and the hardware would only do decoding. If that
is the case then my earlier argument applies. If you aren't using a general
purpose processor, then the logic needed for the IP and RTP stacks will be
WAY LARGER than the logic to support this variable length field.

I also don't really understand your argument about comparing the variable 
length ID field complexity with the decode complexity. Hardware bitstream 
parsing is probably several orders of magnitude more complex than the variable 
length field. I doubt the added logic needed to parse the variable length ID 
field would even be noticable compared to the amount of logic needed to parse 
the bitstream. Yes there is more decision logic, but it is extremely trivial.

Just my $0.02

Aaron