Distortion of RTSP/H.264 Stream Messing Up Modect

[JayD]

Hi *,

one of my sites runs on a Debian Wheezy with a self-compiled v1.26.3. It actually aggregates up to 10 PLANET cameras via RTSP/H.264 at two different sets of resolutions (640x480 + 800x592 @ 10/15 fps). I've described the way cameras are configured within ZM using the following wiki page:

http://www.zoneminder.com/wiki/index.php?title=PLANET

Back to my initial problem - I'm facing destortion and image artifacts, occurring more or less frequently. See the attached images.

For clarification:

• No RFI/EMI, cables used for installation all of CAT 6a (SSTP)
• The entire setup is grounded so no interference from that side neither
• No Power Fluctuations since the setup is powered using a UPS which also serves as an AVR
• ZoneMinder Instance is a "far-end" system connected via a fiber optical link (fully routed)

Unfortunately I don't have any cameras in spare just for the sake of testing it locally at my office.

Some additional thoughts: Sometimes cameras are opting out just like that requiring a hard reset. I'm trying to handle this using PoE monitoring implemented by the switch powering the cameras. Just as of now the feature is still buggy as hell but also only breaks it down to the network level using ICMP echo probes. So if the web server becomes unresponsive leaving the camera reachable via ICMP, the reset won't happen. Well, funny thing is that it also happened with the firmware versions before.

To me it looks more like an issue that might require some tuning on the side of ffmpeg/avconv?

Any ideas? Experience? Suggestions?

TNX

[JayD]

During day time distortion doesn't seem to occur that much often. But maybe it's connected to the fact that right now three cameras are down leaving only six active (five in mode monitor and just one in modect). The ZM instance is running on a virtual host with 4 VCPUs and 8GB virtual memory.

Code: Select all

root@zm:~# cat /proc/loadavg;
0.78 0.90 0.84 1/235 17409

Virtual memory:

Code: Select all

root@zm:~# free -m;
             total       used       free     shared    buffers     cached
Mem:          7853       1249       6604          0        173        642
-/+ buffers/cache:        432       7420
Swap:         2046          0       2046

Some kernel options:

Code: Select all

root@zm:~# sysctl -a | grep shm;
kernel.shmmax = 8589934592
kernel.shmall = 2097152
kernel.shmmni = 4096
kernel.shm_rmid_forced = 0
vm.hugetlb_shm_group = 0

Kernel ring buffer (dmesg) doesn't show anything of interest neither.

[sgn]

Same issue as in quite a few others threads on page 1+2. Usually occurs in low-light scenarios and with h264 sources through ffmpeg. You could switch the source to mjpeg (through ffmpeg) and that would solve the issue yet has its downsides.

You could also check your monitors rate limit (fps), happens with logitech alert when fps is set to <5.

[Basildane]

I just switched my HD test camera to MJPEG from rtsp. Whoa. For the first time I can see almost full resolution.
Still could not go 2048x1536, but I'm going to drop in an I5 tomorrow and a new SSE motherboard, maybe then.

Maybe rtsp will work then too.

[JayD]

Same issue as in quite a few others threads on page 1+2. Usually occurs in low-light scenarios and with h264 sources through ffmpeg. You could switch the source to mjpeg (through ffmpeg) and that would solve the issue yet has its downsides.

Actually I've tried that earlier already but it turned out that only RTSP via H.264 was working at all.

When using MJPEG ZoneMinder can't seem to read the stream.

I've just tried again using the following URIs either with Source Type set to "Remote" or "Ffmpeg":

Code: Select all

h t t p://<USER>:<PASS>@<FQDN/IP>/GetData.cgi?CH=1
h t t p://<USER>:<PASS>@<FQDN/IP>/GetData.cgi

Though I'm able to watch the stream with Firefox and Chromium.

For the HTTP Sources Type the log file for the respective monitor keeps on throwing the following errors:

Code: Select all

2013-09-25 09:11:55.783526 zmc_m4[19327].ERR-zm_remote_camera_http.cpp/1069 [Unable to connect to camera]
2013-09-25 09:11:55.784931 zmc_m4[19327].ERR-zmc.cpp/258 [Failed to pre-capture monitor 4 (0/1)]
2013-09-25 09:12:58.427855 zmc_m4[19347].ERR-zm_remote_camera_http.cpp/101 [Can't connect to remote camera: Connection timed out]

You could also check your monitors rate limit (fps), happens with logitech alert when fps is set to <5.

I used the frame rates provided by the cameras while leaving the monitor specific Maximum FPS setting untouched.

[JayD]

FYI: VLC is able to play the MJPEG URLs mentioned above.

[sgn]

Same issue as in quite a few others threads on page 1+2. Usually occurs in low-light scenarios and with h264 sources through ffmpeg. You could switch the source to mjpeg (through ffmpeg) and that would solve the issue yet has its downsides.

Actually I've tried that earlier already but it turned out that only RTSP via H.264 was working at all.

When using MJPEG ZoneMinder can't seem to read the stream.

I've just tried again using the following URIs either with Source Type set to "Remote" or "Ffmpeg":

Code: Select all

h t t p://<USER>:<PASS>@<FQDN/IP>/GetData.cgi?CH=1
h t t p://<USER>:<PASS>@<FQDN/IP>/GetData.cgi

Though I'm able to watch the stream with Firefox and Chromium.

For the HTTP Sources Type the log file for the respective monitor keeps on throwing the following errors:

Code: Select all

2013-09-25 09:11:55.783526 zmc_m4[19327].ERR-zm_remote_camera_http.cpp/1069 [Unable to connect to camera]
2013-09-25 09:11:55.784931 zmc_m4[19327].ERR-zmc.cpp/258 [Failed to pre-capture monitor 4 (0/1)]
2013-09-25 09:12:58.427855 zmc_m4[19347].ERR-zm_remote_camera_http.cpp/101 [Can't connect to remote camera: Connection timed out]

You could also check your monitors rate limit (fps), happens with logitech alert when fps is set to <5.

I used the frame rates provided by the cameras while leaving the monitor specific Maximum FPS setting untouched.

I did not mean to suggest that you try using http sources; most/many cameras can output mjpeg streams over rtsp either by explicit setting or path variables.

[JayD]

I used the frame rates provided by the cameras while leaving the monitor specific Maximum FPS setting untouched.
I did not mean to suggest that you try using http sources; most/many cameras can output mjpeg streams over rtsp either by explicit setting or path variables.

Sure thing, just forgot to mention that I was trying RTSP first which didn't work neither.

The video settings of the first profile on the camera are already set to JPEG.

The path usually looks like this:

Code: Select all

rtsp://<USER>:<PASS>@<IP/FQDN>:554/<PROFILE>

In my case the profile is named "v1".

[Torsten73]

when you read my thread, you will notice that i have the same problem and its definatly ffmpeg related. I had spend hours in researching it, you will see the problems when trying manually to convert a rtsp stream with ffmpeg.
Please read my thread, and here you also find a patch, wich should solve our problem. But i didn´t testet it till now, you will need to build it from source.
http://www.zoneminder.com/forums/viewto ... 275#p81275

[JayD]

when you read my thread, you will notice that i have the same problem and its definatly ffmpeg related. I had spend hours in researching it, you will see the problems when trying manually to convert a rtsp stream with ffmpeg.
Please read my thread, and here you also find a patch, wich should solve our problem. But i didn´t testet it till now, you will need to build it from source.
.

Seems like a typo, here's the actual link to your thread: ffmpeg can´t handle udp rstp streams

But by having a look at the patch I don't think it's related to my issue after all.

In my case it seems to happen only in low-light scenarios. I think fragmentation should occur persistently and not based on the time of day.

[JayD]

But by having a look at the patch I don't think it's related to my issue after all.

There's already a corresponding pull-request submitted to the ZoneMinder project on GitHub.

It has to be redone and re-coordinated with the guy currently doing RTSP related dev on ZM.

But so far it looks promising and of course I'll give it a try just for the sake of having the chance to finally solve this thing

[JayD]

Related topic:

Smearing images making system unusable

[lucx]

Hello,

I have the same problems with vivotek cameras (fish eye 5M) and alsow with hikvision cameras DS-2CD2032-I. when I set the details at maximum of camera and hy res. ffmpeg cant handle this format i belive, but it works perfect with live555 rtsp client. So if we find a way to hok the live555 rtsp client with zoneminder, is perfect.. I'am ready to start coding if some one will guide me.

[JayD]

Here's something I observed. When limiting the frame rate within the monitor configuration by means of setting maximum fps to less than the actual rate that's provided by the camera, the distortion is nearly persistent.

[Basildane]

Correct. If the camera is pushing a certain frame rate, you cannot ingest it in zm at a lower rate.
You must lower the rate at the camera.