Add the ability to force RTSP over TCP in ffmpeg cameras.

[malazar]

I was capturing 10 cameras at 720p encoded with x264 and I was getting a lot of artefacts.
While examining my system for network problems I noticed that the video stream was being sent over UDP. It seems like avformat_open_input (I'm using latest ffmpeg from git) defaults to RTSP over UDP.

This is what I did in FfmpegCamera::PrimeCapture to fix my issue:
AVDictionary *opts = 0;
av_dict_set(&opts, "rtsp_transport", "tcp", 0);
avformat_open_input( &mFormatContext, mPath.c_str(), NULL, &opts )

It's a quick fix but it would be nice if it is added as an option in the web interface, as I belive there are situations where streaming over UDP is prefferable.

[chriswiggins]

You can actually do it from the camera url by appending ?tcp on the end. Works flawlessly

[malazar]

Nope. Doesn't work with latest ffmpeg. I'll give you the version numbers tomorrow, when I get to work.

[threelegs1]

@malazar i'm not sure if i understand the fix... are you appending that to the file or editing the code that is similar..

[dazedxxx]

@malazar If you could elaborate as I think this is my problem with my cameras. Are you referring to the zm_ffmpeg_camera.cpp file? (which i cant find on my system) and how to change please...I'm
not that smart at the command line....so pardon my special needs....

[dazedxxx]

Actually got it to work somehow...I went back to try the ?tcp and it worked....I am guessing it had something to do with updating ffmpeg that i found here
https://trac.ffmpeg.org/wiki/UbuntuCompilationGuide
I had fresh install of unbuntu server 12.04 LTS and followed the wiki guide
and it would not work with the ?tcp......until after i followed the link above.

[knight-of-ni]

The next release of zoneminder is in testing now. It has a new method, libvlc. We are hoping that it will be a drop in replacement for ffmpeg and make issues like this one non-relevant. I recommend you try this new method first before continuing to troubleshoot ffmpeg issues.

If you'd like to try the upcoming release now, you can do so from here:
https://github.com/ZoneMinder/ZoneMinder/tree/release-1.27

[dazedxxx]

@knnniggett I wish i knew how to get 1.27 swapped in...i followed a wiki guide to install 1.26.5 and the readme file only gets me so far.... I tried reading how to compile but I guess my Old brain just cant take it in...hopefully it will be in Repository soon or if i can find an upgrade guide to beta..?tcp works better but still getting artifacts still.

[threelegs1]

Clone the repository

git clone <repository_url>

List all branches

git branch -a

Checkout the branch that you want

git checkout <name_of_branch>

then just rtfm

[dazedxxx]

@threelegs1 Ok I did best i could....still says 1.26.5 version...doesnt need the ?tcp...but picture is still smearing only in ZM. I was expecting it to say 1.27 but that may be nothing.

[threelegs1]

try removing your source completely before giting the branch and make sure to have libvlccore5 and vlc installed. also before you install zoneminder do a apt-get remove --purge zoneminder to clear your old db and everything

[Sune1337]

I'd like to "vote" for this issue :) If im reading the ffmpeg source right, the "?tcp" option was removed somewhere around 0.9 - 0.11. I a camera that was smearing the image; but after streaming over tcp (with the suggested code change applied) the smearing disappeared. I can't use ?tcp since im using ffmpeg 2.0.

[Sune1337]

Two notes:

1. The "?tcp" option was removed in FFmpeg 0.11. See:
   https://github.com/FFmpeg/FFmpeg/blob/release/0.10/libavformat/rtsp.c#L1412
   vs
   https://github.com/FFmpeg/FFmpeg/blob/release/0.11/libavformat/rtsp.c#L1457
2. I actually have a case where UDP works better than TCP. If i try to stream the camera i have issues with from my home (across the internet), TCP give me terrible results. I mean not a single complete frame is transferred. If i switch to UDP i get mostly complete images.
   I've gotten these results in a few FFmpeg versions i've tried. When i'm at the LAN where the camera's at, i get the feeling that TCP works better; although its not really a big difference.

[knight-of-ni]

The irony of this whole situation is that UDP is supposed to work better than TCP in the general case. Any modern device that transmits information in real time e.g. video cameras, ip phones, multiplayer games, etc. should be using UDP.

Switching to TCP is/was just a bandaid for those experiencing issues. TCP Ack packets cause the sending device to retransmit dropped packets, but that can cause bigger problems for a device sending information in real-time.

The real problem has got to do with why packets are being dropped or missed in the first place and how well the system recovers from that. I know this is easy for me to say, but from what I've read the problem seems to be within ffmpeg and not zoneminder. That's not to say someone can't figure out some way to get zoneminder to compensate for this, however.

Just a reminder that the new libvlc method in zonemidner 1.27 should be a drop-in replacement for ffmpeg. Please try it.

[Sune1337]

libvlc was a fail for me. Tested it with 2 cameras and both went:

[0000000006b89f78] pulse audio output error: PulseAudio server connection failure: Connection refused
[0000000006d74258] core vout display error: Failed to change zoom
[0000000006d74258] core vout display error: Failed to set on top
[0000000006d74258] core vout display error: Failed to change source AR
[0000000006bc4658] core input error: ES_OUT_RESET_PCR called
[mpeg4 @ 0x6beb360] warning: first frame is no keyframe

and then a stacktrace when i kill the process:

/usr/src/zm/git/ZoneMinder/src/zm_signal.cpp:89
??:0
/usr/src/zm/git/ZoneMinder/src/zm_comms.h:265
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0

I get the feeling vlc tries to display this on a screen.. :)

[Sune1337]

Decided to have another shot at libvlc. Noticed i got a "libjpeg-turbo is required for JPEG encoding directly from BGR24 source" in the zms debug log after switching the camera to libvlc.

After going through hell twice i got ZM to use jpeg-turbo and i could see the video. The above errors still occurs, but i guess they're not fatal to VLC. So im gonna test this live and hope the distortions go away.

Its a shame libvlc uses twice the amount of CPU tham FFmpeg :(