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

[Tor-Einar Jarnbjo]

Fredag, 4 februar 2005, skrev Michael Smith <mlrsmith at gmail.com>:

>Suppose the client has a one-second buffer (to account for network
>conditions, or whatever).

Having only a one second buffer sounds extremely optimistic to me.
The Windows Media Player defaults to five seconds if I'm not completely 
wrong.

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

And what is the client doing when the buffer is empty? Being silent? 
What is the client doing when the RTP eventually arrives and it detects 
that some of the contained Vorbis packets should already have been 
played? The packets are dropped. The result is?

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

There is a difference between allowing 63 Vorbis packets and enforcing 
the transmitter to fill an RTP packet with 63 Vorbis packets. 

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

I understand that this situation may be a theoretical problem using 
RTP transport, but I still don't understand how this is relevant 
for HTTP streaming, as packet bundling does not make any sence in 
a TCP streaming situation.

Tor