[xiph-rtp] Updated Vorbis and new Theora I-D's

[Phil Kerr]

Hi Ralph,

Ralph Giles wrote:

>On Tue, Feb 01, 2005 at 04:36:40AM +0000, Phil Kerr wrote:
>
>  
>
>>I've just checked into svn two new documents.
>>    
>>
>
>Great to see these!
>
>  
>
>>I've included a MIME section for the packed headers.  I'm not 100% sure 
>>if the media type is right, should it be audio or application?
>>    
>>
>
>Hmm. I guess we need a separate format for multicast.
>
>For reliable transmission, what do you think about just serving an Ogg
>file with all the headers embedded normally (and the actual compressed
>data elided)? This is the simplest approach programmatically.
>  
>
This is worth looking at.

>Have you thought about including the CRC32 in the packed header format?
>That might also add some convenience, and help verify both intended
>match and successful transmission in lossy delivery schemes.
>  
>
Do you mean a separate CRC32 of the whole packed header or just the 
Ident CRC?

>  
>
>>Also included is details on generating the crc32 hash, with it's 
>>polynomial and C code fragment.
>>    
>>
>
>Yay. I'd also reference it, indicating (for example) if it's the same
>hash used by Ogg or zlib, just to save people checking the definition
>by hand.
>  
>
It's used in a few implementations of ssh that I've seen.  If we need to 
base it on something the polynomial used by PNG is a reasonably well 
known format.

>  
>
>>A new I-D covering the RTP transportation of Theora Video is available.  
>>It draws heavily from the Vorbis draft and shares a lot of the basic ideas.
>>    
>>
>
>One quick thing: the three 'total number of blocks' aren't actually in the
>setup header; they're calculated from the other fields that are in the 
>bitstream. What looks like the packet structure table in the spec is
>actually the output of the specified decode routine, which generates the
>redundant values for the convenience of other sections of the spec.
>  
>
For RTP is it ok to use the structure even though it is derived from 
calculated fields?  In order to use the Theora data there is an element 
of parsing needed and the calculated fields can be worked out then.

>I'd also suggest some wording clarification:
>
>    'width/height of the encoded frame in...'
>    'width/height of the valid picture region...'
>  
>
Will be fixed.

>And reference the definitions in the spec since these informative but
>not nominal.
>
>KFGSHIFT would better be defined as the log of the maximum keyframe spacing,
>since the granulepos is irrelevent in this context.
>  
>
Fixing.

>Technically, the NOMBR, QUAL, and KFGSHIFT are not necessary for decode
>and could be elided. Reasonable values can be recomputed by an application
>that needs to regenerate the original theora packet. In practice, including
>them probably does no harm.
>  
>
Ok, I'll leave them in but mention they are not really needed.

Cheers

-P

> -r
>
>  
>