[Live-devel] RTSP Client TCP mode

[Nikolai Vorontsov]

Hello Ross,
 
does it mean that we don't have any means to handle tool-low-bandwidth
network case? I can imagine for instance for the live view the following
scenario - we monitor the output queue length and when it's overflown or
close to the top - start to skip all incoming frames till the next key
frame (or till the queue is lowering)? That makes video not ideal, but
at least customer see something (with gaps).
For the playback usually it's possible to ask the source part to hold on
frame delivery and I guess, again I can monitor output queue length and
tame my backend server stream.
 
Does it make sense in live555?
 
Nikolai

________________________________

From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Saturday, May 26, 2012 11:56 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] RTSP Client TCP mode



	I have a live555 RTSP server serving a 3mbps mpeg2ts file. The
server is hosted with public internet connection.
	
	When openRTSP  is used in RTP/UDP mode its able to receive the
file properly. 
	


Yes, but if your network's capacity is less than 3 Mbps, then you will
lose data, but the losses will occur on Transport Stream 'sync byte'
boundaries.



	However when  RTP/TCP mode, openRTSP prints "Missing sync byte!"
and stops getting data. 
	On the server the Receiver Report shows lot of packet loss. 
	
	For low bitrate content TCP mode works fine. 
	


Your stream is exceeding the bandwidth of the network.  Therefore, you
are going to lose data.  End of story.  Note that - in this case -
RTP-over-TCP streaming will not save you.  If you try to stream over a
too-low-bandwidth network using TCP, you'll still get data loss, but
it'll occur at the sender (because of its OS buffer overflowing), rather
than at the receiver. 

This is the important distinction between live media streaming, and
on-demand streaming (e.g., using the World-Wide Web).  If you use our
software, it's important to understand this distinction.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120530/c624929a/attachment.html>