[Live-devel] [live555] RTP sequence number is not continuous when video bitrate is high (for example: 8Mbps)

[Alexander Tumarov]

Hi Ross,
 
In the case of TCP should it suspend sending up to the point there is a space available 
instead of dropping RTP packets? or close connection in such a case? or at least should it 
be up to implementation/user code?

RTSP can be user for streaming stored data - not only real time streams.

Best regards,
Alexander.

On Wednesday, July 29, 2020 12:14:07 PM IDT Ross Finlayson wrote:
> > On Jul 29, 2020, at 9:05 PM, Zhang Qian（张倩） <qianzhang at asrmicro.com>
> > wrote:
> > 
> > 
> > Hi Ross,
> > 
> > 
> > Sorry for misunderstanding. I catch the tcpdump log for rtsp server, and I
> > use the TCP socket. Seems that these FU packets are not sent to TCP
> > protocol stack. So I want to check whether these packets are lost in rtsp
> > server for large bitrate.
> Your stream’s bitrate is exceeding the capacity of your network.  You will
> lose RTP packets, ***even if you are streaming RTP-over-TCP***.  (If you
> are streaming RTP-over-TCP, then eventually the TCP socket, inside the
> sender’s OS, will run out of buffer space, and several writes to the TCP
> socket - by the RTSP server - will fail.  This is what you are seeing.)
> 
> You CANNOT avoid data loss if your stream’s bitrate exceeds the capacity of
> your network (which is usually a lot lower than the nominal ‘speed’ of your
> network interface).  This is physically impossible.  The ONLY solution is
> to reduce your stream’s bitrate.
> 
> 
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> 
> 
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20200729/29603343/attachment-0001.htm>