[Live-devel] Basic question

[Bill Russell]

At 12:17 PM 11/13/2003 -0800, you wrote:

>>>>Isn't the idea of RTP that the server will throttle back on the packet 
>>>>rate based on client packet-loss reports?
>>>
>>>Well, a server certainly *may* do this (if it's programmed to do so).
>>So you're saying that Live doesn't do this and that's why you recommend 
>>using small frames.
>
>No, I'm saying that if you (or *any* server that streams JPEG-over-RTP) 
>use large JPEG frames (that thereby take up a large number of RTP 
>packets), then you increase the risk that the receiver (e.g., QuickTime 
>Player) won't be able to play the stream at all - because the loss of 
>*any* of the packets will render the frame unusable.
>
>E.g., suppose you're streaming over a link with 1% packet loss.  If you 
>send 50 kByte JPEG frames (==35 RTP packets-per-frame), then only about 
>70% of your frames will be playable by the receiver.  (The other 30% of 
>the time, at least one of the RTP packets will have been lost.)  If, on 
>the other hand, you send 10 kByte JPEG frames (==10 RTP 
>packets-per-frame), then about 90% of your frames will be playable by the 
>receiver.

But, if you keep adjusting frame rate for 0% loss most of the time, and you 
get 100% playable frames most of the time no matter how big they are. Your 
example assumes a constant non-zero packet loss. If I had to always have 1% 
packet loss, then I would definitely go with smaller frames.

Bill