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

[Phil Kerr]

Hi Aaron,

{Sorry for the delay in replying, my network card went pfftt last night 
and I had to hunt another one down that works with Linux as well as XP)

Thanks for the feedback, comments inline.

Aaron Colwell wrote:

>Here are my comments on the Vorbis Draft.
>
>- Fragmented Flag value seems backwards to me. It is set for packets that don't
>  contain fragmented packets and not set for the first packet that is. I'm
>  fine with it not being set for a middle continuation packet and 
>  being set for the final fragmented packet. It seems like the following makes
>  more sense to me.
>
>  C F
>  0 0  Unfragmented packet (aka multi-packet..packet)
>  0 1  First fragmented packet
>  1 0  Middle fragment
>  1 1  Last fragment.
>  
>
This format is based on Jack's original draft.  I'm not sure if it was 
done for a particular reason or it was best fit at the time so if there 
are no objections it can be changes as this schema is neater.

>  Don't forget to update the diagrams and text if you decide to accept this
>  suggestion.
>  
>
Yup :)

>- The text under Fig 6 doesn't match the drawing for the C-bit. The text seems
>  wrong and the diagram is correct.
>  
>
Fixed.

>- In section 3.2, why would you buffer the final fragment if you've 
>  dropped/lost all the other fragments?
>  
>
The idea I was aiming for was to buffer packets missing if they are 
slightly delayed and only dropped once they've gone out of scope.

>- In section 4.1.1, why don't you just send the ident header packet itself?
>  This would prevent the need to update the RTP payload spec if the ident
>  header changes for some reason.
>
>- In section 4.1.3, why don't you just send the comment header packet itself?
>  This makes life easier for the server and client.
>  
>
They should be a straight mapping from the Vorbis spec.

>- Packaged header delivery. Why don't you just use the header packets as is?
>  that requires less work for the client and server.
>  
>
They are apart from striping out the RTP fields.

>
>- At the top of Page 22, fmpt should be fmtp.
>  
>
Fixed.

>- In section 5.1 I was confused about the header parameter. It says 
>
>   "If the stream comprises chained Vorbis files the configuration and
>   codebook headers for each file SHOULD be packaged together and passed
>   to the client using the headers attribute if all the files to be
>   played are known in advance."
>
>   Does this mean that the package itself should be put in the header field or
>   an URL? If you look later it seems to indicate an URL, but this text isn't
>   very clear.
>  
>
In the URL, this section will be made clearer.

>Here are some issues that I think still need to be addressed.
>
>- I think the CRC should be computed over the ident header and setup header 
>  since both of these are needed to uniquely identify the chain. Perhaps
>  the CRC is computed over the 2 pieces of data concatenated together.
>
>  
>
This is looking like the best option.

>- If the total set of codebooks is not known at SDP generation time, what are
>  the options? Does this mean that inline codebook distribution must occur?
>  Could a base URL be specified in the SDP so that when you append the 
>  codebook ID to the base URL you'll have a URL for the appropriate package?
>
>- It seems to me that the packages for each chain should be seperate. If they
>  are all together then the client may download data it already has in it's 
>  cache. Perhaps if you use the base URL idea above and provide a list of
>  CRC's, then the client can determine whether it needs to download the 
>  packages or not. There are several other optimizations of this I can think
>  of, but I just wanted to throw out an initial idea first.
>  
>  
>
This is a nice idea!

>- How would changing sample rates be handled? You can't change the timestamp
>  units on the RTP packets, since this is statically configured at SDP time.
>  There should at least be some text that specifies how to convert the original
>  vorbis packet timestamp into the RTP timestamp units when the RTP timestamp
>  sample rate does not match the vorbis sample rate. I think that it should
>  simply be something like
>
>  RTP timestamp = (Vorbis Timestamp) * (RTP Sample Rate) / (Vorbis Sample Rate)
>
>  This is defined as an integer operation and no rounding up occurs. This 
>  should allow the client know exactly what to expect if it has to recompute 
>  the packets sample position after a loss event. It's useful to have this
>  explicitly defined so that A/V sync drift will be less likely and all clients
>  will hopefully behave the same after loss.
>
>  
>
Agreed.

-P


>Aaron
>
>On Tue, Feb 01, 2005 at 04:36:40AM +0000, Phil Kerr wrote:
>  
>
>>Hi all,
>>
>>I've just checked into svn two new documents.
>>
>>draft-ietf-avt-vorbis-rtp-00.txt
>>
>>This is an update of draft-kerr-avt-vorbis-rtp-04, with a name change 
>>due to it being adopted as an AVT WG draft.
>>
>>Together with the changes detailed on the AVT list the other major 
>>changes are the increase of the Vorbis payload size field  to 16 bits 
>>and the inclusion of  RTCP feedback implosion avoidance.  There are a 
>>lot of textual changes in this document, which hopefully make it easier 
>>to read.
>>
>>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?
>>
>>Also included is details on generating the crc32 hash, with it's 
>>polynomial and C code fragment.
>>
>>
>>draft-kerr-avt-theora-rtp-00.txt
>>
>>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.
>>
>>Please have a read through the drafts, comments welcomed as always.
>>
>>http://plus24.com/xiph/draft-ietf-avt-vorbis-rtp-00.txt
>>http://plus24.com/xiph/draft-kerr-avt-theora-rtp-00.txt
>>
>>If everything is ok I'll submit them to the IETF either at the end of 
>>this week or early next week.
>>
>>Best regards
>>
>>Phil
>>
>>_______________________________________________
>>xiph-rtp mailing list
>>xiph-rtp at xiph.org
>>http://lists.xiph.org/mailman/listinfo/xiph-rtp
>>
>>    
>>
>
>  
>