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

[Aaron Colwell]

On Fri, Feb 04, 2005 at 08:29:03PM +1100, Michael Smith wrote:
> On Fri, 04 Feb 2005 10:22:50 +0100, Tor-Einar Jarnbjo
> <Tor-Einar at jarnbjo.de> wrote:
> > Michael Smith wrote:
> > 
> > >The downside is that you then have a very large gap between packets -
> > >particularly in live situations, this risks starving client buffers.
> > >Existing vorbis-in-ogg-over-http streaming often runs into this
> > >problem.
> > >
> > How is that supposed to happen? In any case, the same data will be fed
> > to the Vorbis decoder. If a receiver has problems with this situation,
> > the RTP receiver is incorrectly implemented.
> 
> Suppose the client has a one-second buffer (to account for network
> conditions, or whatever).
> 
> Then, create a situation where you can fit 60 vorbis packets into an
> rtp packet, probably by having digital silence (this could be several
> seconds, depending on things like sample rate). You can't send the rtp
> packet until you've got the data to send - in a live situation, then,
> you won't be able to send it for several seconds - by which time the
> client has run out of buffer.
> 
> This is easily remedied by just ensuring you send rtp packets
> sufficiently frequently - which is fine, but then you've got no reason
> at all to allow large numbers of vorbis packets in a single rtp
> packet. So no need for the extra complexity you were suggesting.
> 
> I might be misunderstanding something (I won't claim to have
> particularly great knowledge of how RTP works), in which case I'd
> appreciate an explanation... but this is the problem that exists with
> http-streaming currently, and I don't see why rtp would be
> fundamentally different in this respect.

Most streaming applications have a concept of preroll or initial buffering.
This is a value that is advertised by the server to tell the client how much
data needs to be buffered before playback should begin. It basically exists to
avoid this problem. The server can adjust this value if it wants to decrease
the packet rate. 

In general though you don't want to have too many packets in a single 
datagram because the cost of loss is much higher. If you lose a packet
with 63 packets in it, you lose a significant amount of time. This would be
very noticable during playback. You probably don't want much more than 
100-200ms worth of data in a packet. In some cases that might even be too much.
Like most things there is a tradeoff here. Putting more packets in a RTP packet
lowers header overhead, but at the same time it makes loss more noticable and
increases latency.

Aaron

> 
> Mike
> _______________________________________________
> xiph-rtp mailing list
> xiph-rtp at xiph.org
> http://lists.xiph.org/mailman/listinfo/xiph-rtp
>