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

[Phil Kerr]

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.

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