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

[Aaron Colwell]

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.

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

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

- In section 3.2, why would you buffer the final fragment if you've 
  dropped/lost all the other fragments?

- 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.

- Packaged header delivery. Why don't you just use the header packets as is?
  that requires less work for the client and server.



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

- 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.


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.


- 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.
  
- 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.

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
>