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

[Aaron Colwell]

On Fri, Feb 04, 2005 at 04:58:57PM +0000, Phil Kerr wrote:
> Aaron Colwell wrote:
> 
> >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.
> > 
> >
> So the # Vorbis frames should be limited to 32, this was the value it 
> was in the -03 draft before the introduction of the VDT field.

That seems reasonable to me. 

Aaron

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