[vorbis-dev] RFC draft for Vorbis over RTP

[Aaron Colwell]

On Tue, May 25, 2004 at 07:01:54PM -0700, Ralph Giles wrote:
> On Tue, May 25, 2004 at 06:15:51PM -0700, Aaron Colwell wrote:
> 
> > I was planning on implementing RTP delivery of Vorbis and Theora in Helix.
> 
> Go Aaron! :)
> 
> > The current draft leaves much to be desired. Here are the issues I 
> > see with it.
> 
> Wow. Thanks for the summary. These all look like reasonable criticisms.
> 
> > - 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.
> 
> I think delivery in the RTP channel should be possible, but I don't 
> understand how you intend to handle dropped header packets. RTP 
> generally used unreliable transport, and the stream is of course
> not decodable without the info and setup headers.

I was planning on retransmitting the headers periodically. In the case of 
an unicast delivery the client could ACK the headers via an RTCP APP packet.
This would tell the server to stop sending the headers for that chain. Even 
if the ACK gets dropped the client will send another one when it gets a header
it already has. In low loss conditions, only one ACK will be needed. In higher
loss situations, more ACKs will be sent, but one will eventually get through.
I also plan on sending the MD5 for the codebook before sending the codebook.
This allows the client to ACK the codebook header before it gets sent. That
can save bandwidth as well. For multicast transmision the headers will be
periodically transmitted and the ACK packets aren't sent. The advertised
bitrate of the stream will contain a little extra bandwidth for the header
transmission. The headers are retransmitted based on the bandwidth allocated
to them and maybe a minimum header transmission period. The minimum 
transmission guarentees that a client can get the headers within certain period
of time. This is very useful in the multicast scenario.

I've been thinking about this for a month or so, but haven't gotten time to
write it all down and test out my ideas.

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.