SV: [xiph-rtp] A few other comments

[Tor-Einar Jarnbjo]

Hi Phil,

> Vorbis data and its associated codebook.  What replacement to CRC32 did
> you have in mind?

I was thninking about something like MD5, but CRC32 will probably do just as
good.

> The length octet dates back to Jack's original draft so I'm sure he can
> answer this better than me.  But if this was bumped up to 16 bits then
> more often than not the top 6 or 7 bits aren't going to be used, is this
> not a waste?

I just picked and analyzed a random Vorbis file and it has a total of 26465
packets with the following sizes:

10130 [0,256> bytes
14505 [256,512> bytes
 1830 [512,615] bytes

Extending the length field to 16 bits, all packets may be transmitted
without splitting, but it adds a 26465 bytes overhead to the total data
amount.

Splitting the 16335 packets with a length >= 256 bytes however, will cause
an additional 18165 packets to be transmitted (14505 + 2*1830). Assuming a
50 byte overhead for the UDP header, RTP header and the Vorbis specific
header, it adds a ~900kB to the total data amount.

> I thought that Vorbis has the basic metadata which can be
> augmented with Annodex if the particular usage instance required
> something mor detailed.

Ok, I sort of agree on this, but wouldn't it at least be wise to define the
Vorbis metadata header as optional and not mandatory. If a particular setup
decides to use any other metadata format, it would allow a cleaner design if
the Vorbis metadata is completely left out instead of forcing the server to
send an empty Vorbis metadata header, just to satisfy the RFC. In many
cases, even the limited metadata fields in the SDP may be enough for a
particular purpose.

>> Why is there a codebook ident in the configuration header packet?

> RTP is based on UDP, not TCP, so there is no reliability or
> retransmission ability built-in.

This depends on what you mean with "reliability". UDP does not offer a
guarantee that the packet is being received by the client, but _if_ the
packet is being received, you can rely on its correct content, as the UDP
header contains a CRC field to ensure data integrity, which has to be
checked by the UDP stack before forwarding the received packet to the user
software.

Tor