[Live-devel] RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize"

[Roman Gaufman]

Just to follow up, I tried with UDP also and the proxy seems to just freeze
after a while and take 100% cpu - I then need to killall -9
live555ProxyServer and restart it to make it receive data again.

On 14 October 2012 14:52, Roman Gaufman <hackeron at gmail.com> wrote:

> Thank you for a detailed explanation, but I'm still not sure why this
> would be happening as the network isn't saturated. The stream is around
> 1.5mbps on a 1gbit network with nothing else taking up the bandwidth - it
> could be the camera misbehaving I guess?
>
> My problem however is say the camera is misbehaving or the delivery isn't
> 100% briefly for any reason, why would the proxy just freeze and stop
> receiving data? - is there any way to get RTSProxy to not just freeze but
> rather reset itself or retry or whatever is required to keep receiving the
> stream?
>
> As for UDP, I tried but the stream looks horribly broken with
> ffmpeg/opencv - there seems to be some bug processing streams over UDP, I
> tried opening 4 different UDP streams from 4 different IP cameras directly
> with opencv/ffmpeg (axis ip server, axis camera, sony ip camera and some
> chinese IP camera), the stream breaks almost immediately unless I pass
> -rtsp_transport tcp
>
> On 13 Oct 2012, at 19:32, Ross Finlayson <finlayson at live555.com> wrote:
>
> I'm reading from a Sony IP cameras, I'm running:
>
> ./live/proxyServer/live555ProxyServer -t "rtsp://
> 192.168.88.13/media/video1"
>
> I'm then trying to read the RTSP with:
>
> ./live/testProgs/openRTSP 'rtsp://192.168.0.2:554/proxyStream'
>
> After a while, the stream freezes and I'm getting: RTCPInstance error: Hit
> limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize"
>
>
> This error message (which I presume is being printed by the proxy server,
> not by "openRTSP") suggests that the TCP connection is 'missing' data,
> presumably because send() calls by the server (over the TCP connection)
> have begun.  This tells you that the stream's bitrate exceeds the capacity
> of your TCP connection.  There is *nothing* that you can do to overcome
> this, other than reduce the bitrate of the stream (from your camera).
>
> Also, as I said a few days ago (in response to another question):
> Everyone needs to understand that streaming RTP-over-TCP is something that
> you should do *only* when you are streaming over a firewall that does not
> pass UDP packets.  You should not think that just because TCP is a
> 'reliable' transport protocol, that you can use it to ensure 100% delivery
> of all of the stream data.  This may happen if the stream's bitrate is less
> than the capacity of the TCP connection, but if the stream's bitrate
> exceeds the capacity of the TCP connection, then you *will* get data loss
> (and in an inefficient way, because it won't occur on RTP packet
> boundaries, as it would if you were streaming via RTP/UDP).  This is the
> difference between streaming and 'file/webpage downloading', for example.
>
> 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/20121015/6e9d77fc/attachment.html>