[Live-devel] TCP streaming problem with LIVE55

[Marcin]

Hello Ross,
I have an IP Camera that i need to insert SEI messages into datastream.
I used Live555ProxyServer with some modification to do this. But after
that i faced a huge problem.
Camera has already build in RTSP Server so i recompiled to ARM, ran this
inside camera:
localRTSP => liveProxy => output
Then in tested stream i use VLC to check this and see lost packets.
Added some debug infos:
NAL size and truncated data below:

NAL 123096 5 0
NAL 124295 5 0
NAL 120028 5 0
NAL 120117 5 0
NAL 117643 5 0
NAL 116544 5 0
NAL 106158 5 0
NAL 112396 5 0
NAL 145041 5 0
NAL 145389 5 0
sendDataOverTCP: resending 1456-byte send (blocking)
NAL 145054 5 0
sendDataOverTCP: resending 1456-byte send (blocking)
NAL 137306 5 0
NAL 140356 5 0
NAL 129889 5 0
NAL 143098 5 0
sendRTPorRTCPPacketOverTCP: failed! (errno 11)
NAL 127436 5 0
NAL 135058 5 0
NAL 121653 5 0
NAL 104777 5 0
NAL 110900 5 0
NAL 106449 5 0
NAL 124335 5 0

Interesing is that same stream from original RTSP works well.
So:
rtsp://IP:554/ works okay
rtsp://IP:8554/ drops packets

Any clues?
Marcin

[Ross Finlayson]

This post might be inappropriate. Click to display it.

[Marcin]

Hello Ross,
The problem with "why" i have to use proxy - it's because i dont have
source code for original software inside - then i have to "glue"
something else in camera to do the job.
I am using genuine proxy server, without modifications yet and still see
the problem. The error is EAGAIN, and proxy uses nothing more than 2% of
CPU and little of memory.
The VERY intereting part is that if i use "openRTSP -v -t -d 60
rtsp://proxyaddress > /dump.h264 INSIDE camera - i recieve complete
working stream without any damage and not lost packets.
I am directly connected to camera over LAN 100Mbps, when looking on the
same time of original RTSP and Proxy RTSP - original works well but
errors are only on proxied stream.
So where to search the clue?
Marcin

Post by Ross Finlayson
First, if you have access to the IP camera - and are able to completely control what runs on it - then why are you using a proxy server at all? Why not modify the H.264 stream (to add SEI NAL units) as it comes from the camera’s H.264 *encoder*, and just run a single RTSP server (not a proxy server) to stream the modified stream?
If instead you are running - inside your IP camera - “encoder” + “built-in RTSP server” + “your modified proxy server (which manipulates (presumably with lots of data copying) the H.264 NAL unit stream)”, then perhaps you are becoming CPU bound?

Post by Marcin
sendRTPorRTCPPacketOverTCP: failed! (errno 11)

What is errno 11 on your system? (Run “man errno”?)
In any case, when streaming-over-TCP fails (as it did for you), it means that the data rate of the stream exceeds the capacity of your TCP connection. In this case, that might be because your IP camera’s CPU (and/or memory subsystem) is becoming overloaded (from all of the extra stuff you’re running on it, with all of the extra data copying), causing its effective TCP data rate to drop.
http://lists.live555.com/pipermail/live-devel/2018-September/021053.html
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
http://lists.live555.com/mailman/listinfo/live-devel

[Ross Finlayson]

I am using genuine proxy server, without modifications yet and still see the problem. The error is EAGAIN, and proxy uses nothing more than 2% of CPU and little of memory.
The VERY intereting part is that if i use "openRTSP -v -t -d 60 rtsp://proxyaddress > /dump.h264 INSIDE camera - i recieve complete working stream without any damage and not lost packets.

Then this is telling you exactly what the problem is: The problem occurs only when you stream the data over TCP. The EAGAIN error is your OS’s TCP implementation telling it that its buffer - for outgoing TCP connections - is full. I don’t know why this is happening, but perhaps you can increase this buffer size (inside your OS; Linux, I presume), or diagnose the problem (again, inside your OS) in some way? But this begs the question: Why are you streaming over TCP?? If your clients are all on the same LAN - i.e., with no UDP-blocking firewall between them and the server - then you don’t need to be streaming over TCP at all.


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