SV: [xiph-rtp] A few other comments

[Phil Kerr]

Hi Tor,

Tor-Einar Jarnbjo wrote:

>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.
>  
>
MD5 is more collision-proof, but its size means it is impractical to tag 
each packet with a codebook key and this was one of the design goals, 
having a hard association between stream and decoding.

>  
>
>>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've just had a look at a few files. 

||---------------------------------------------------------------------------||
||  vsize: Vorbis frame size stat generator.
||
||  Filename: qq-2004-12-11c.ogg
||
||---------------------------------------------------------------------------||
||  Stats.
||
||  Total number of Vorbis frames: 29716
||  Number of small (<= 256 bytes) Vorbis frames: 29716
||  Number of medium (> 256 && < 512 bytes) Vorbis frames: 0
||  Number of big (> 512 && < 1024 bytes) Vorbis frames: 0
||  Number of jumbo (>= 1024 bytes) Vorbis frames: 0

This file is from a CBC recording that Ralph tried with a very early 
version of the RTP server.  Notice it has no Vorbis frames greater than 
256 bytes.

The next file is an encoding of a CD rip.

||---------------------------------------------------------------------------||
||  vsize: Vorbis frame size stat generator.
||
||  Filename: ../tunes/max_graham__tranceport4_disk_2.ogg
||
||---------------------------------------------------------------------------||
||  Stats.
||
||  Total number of Vorbis frames: 567071
||  Number of small (<= 256 bytes) Vorbis frames: 437171
||  Number of medium (> 256 && < 512 bytes) Vorbis frames: 698
||  Number of big (> 512 && < 1024 bytes) Vorbis frames: 5011
||  Number of jumbo (>= 1024 bytes) Vorbis frames: 124191

Lots of big frames!

Both files were encoded with the Vorbis I 20020717 (1.0) libs, the first 
one has an average bitrate of 52.27 kbps, the second 469.14 kbps.

I certainly think this issue needs to be looked at further as whilst the 
change is quite small it does have a large impact on the stream 
overheads.  Another side effect of increasing the limit to 16 bits is 
the probable increase in the number of packets that will exceed path MTU 
and will fragment.

[I'll put the vsize code at http://plus24.com/xiph/vsize.c.gz if anyone 
is interested in generating some Vorbis frame stats.]

>  
>
>>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.
>  
>
As Ralph has mentioned, this is to keep everything happy with regards to 
the official Vorbis specs, which mandate that the metadata header is 
required, even if the only info is the vendor string.

I see the use of the basic 'built-in' metadata as providing your 
bog-standard stream/track info but with Annodex you can offer a far 
richer description.  Some scenarios the basic model will be fine but 
others (plays or opera being good examples) having lots of plot metadata 
would be very good!  I covered this for opera in one of my former 
projects using MPEG-7 and Silvia has done similar work with Annodex 
which goes in a slightly different direction, Silvia, can you elaborate 
on this?

>  
>
>>>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.
>  
>
True, but if you have a codebook that spans multiple packets it's a lot 
easier to deal with one CRC, than several.  Also the packet CRC covers 
the headers, not just the payload (iirc, need to check this).

>Tor
>
>  
>
Cheers

-P