[vorbis-dev] RFC draft for Vorbis over RTP

[Aaron Colwell]

On Tue, May 25, 2004 at 05:11:10PM -0700, Ralph Giles wrote:
> On Wed, May 26, 2004 at 09:57:42AM +1000, Conrad Parker wrote:
> 
> > The next steps are:
> > 
> > 	1. ensure that all outstanding issues are resolved in the
> > 	working version of the draft (ie. the one in vorbis svn).
> 
> Is there a summary of these available?
> 
> > As I recall the main outstanding issue is the delivery of codebooks as an
> > RTP payload. As these are critical for stream decode it was suggested that
> > they instead be referenced during setup and retrieved via a reliable
> > mechanism, such as HTTP. It is a technical argument, not political.
> 
> Yes, this is the "hard part". It would help if we had some active 
> implementations. I believe the current draft specifies a separate RTCP 
> connection for the headers and a way to pass them through SDP (this 
> method supports caching). The draft doesn't speak directly to the 
> headers being included in the rtp stream, but this should probably be 
> included as well.

I was planning on implementing RTP delivery of Vorbis and Theora in Helix. The
current draft leaves much to be desired. Here are the issues I see with it.

- I don't think you should use the RTCP channel for distribution of the 
  headers and codebooks. I think this should be done in the RTP channel. One
  of my main reasons for this is that the RTCP channel is much more bandwidth
  limited than the RTP channel. By default you'll only get 3.75% of the session
  bandwidth for server initiated RTCP packets. This may not be enough for
  timely delivery of codebooks.

- The support for chained files is not very robust. In the current spec, if the
  RTCP packet that says when the stream switches codebooks gets lost or 
  arrives late the decoder could try to decode Vorbis data with the wrong 
  codebook. The RTP data should have some way to indicate what chain it belongs
  to. This ID should also be sent with each codebook so that you can match the
  data with the codebook.

- There is no way to indicate that samples should be trimmed off the front or
  back of the packets. This could prevent proper playback of some files.

- Only allowing 32 packets per RTP packet seems arbitrary. If you just change
  how the length field works you don't need this limitation. One possibility
  is to have a variable length field. Use the MSB as a continuation marker. If
  it is set then then the length field uses one more byte. The remaining bits
  are used for the length. You can also define a length of 0 as the termination
  marker. This allows you to have as many packets as you want. This also gets
  around the 256 byte packet size limitation which seems arbitrary as well.

- The fmtp fields for the SDP look weird. All the payload formats that I can
  think of use a semicolon delimited list of parameters. I don't see anything
  special about Vorbis that should cause you to break from this convention.

- bitrate_max can be replaced with a b=AS line. 

- bitrate_min is of limited utility.

- I'm assuming that bitrate_nom is something like the average bitrate.
  I don't think that there is a standard SDP field for this, but it may be
  a good idea to lobby for a new b= type.

- The a=rtpmap line should be changed to include channels like other audio
  formats. This makes the the channels fmtp field unnecessary

- bsz0, bsz1, and all meta tags should just be removed. Just send the two
  header packets that contain this data in the RTP stream. If you still want
  to use the existing you can use the RTCP packets to send this data. That way
  the first chain and all furthur chains are treated the same. This is
  particularly important in the multicast/live case because the SDP info may 
  only indicate what the first chain contained. The packets you are receiving
  may not be part of the first chain. These values are part of the data
  stream, might as well leave them in there. I'm assuming of course that these
  values are periodically transmitted in a multicast/live scenario.

That's all that I can think of right now. I hope this helps.

Aaron

> 
>  -r
> --- >8 ----
> List archives:  http://www.xiph.org/archives/
> Ogg project homepage: http://www.xiph.org/ogg/
> To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
> containing only the word 'unsubscribe' in the body.  No subject is needed.
> Unsubscribe messages sent to the list will be ignored/filtered.
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.