[Live-devel] Basic question

[Ross Finlayson]

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

Note that this is not specific to the LIVE.COM code; it's true for *any* 
server that sends JPEG-over-RTP.

>  Currently, my camera uses bandwidth throttling and I have successfully 
> been using it with VGA images up to 50KBytes in size at up to 30fps. Do 
> you think Live would be able to achieve close to this performance 
> streaming JPEG to Quicktime on a 44 MHZ embedded (ARM7) system

I suspect so.

>I'm just trying to decide if I could replace my current JPEG server with 
>Live or just use Live for the MPEG-4 server (for that, any level of 
>performance will be acceptable).

If you want standard clients (e.g., QuickTime Player) to be able to play 
your streams, then you should use real RTP/RTCP streaming, as is done by 
the LIVE.COM libraries.


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>