Smearing images making system unusable

[Basildane]

I only have the one HD camera so far, but I know the problem is not in the camera because I can view the camera using the included software "GSurf Pro". Using the same h264, at 2048x1536 at 8 meg/sec, 10 fps (not what I am attempting on zm).

The picture at that setting on GSurf Pro is like a Hollywood Movie. It is spectacular. I can clearly zoom in on license plates, etc.

After weeks of trial and error, I've found that I can pretty much run the camera using 1600x1200, at 1.8 meg/sec, 5 fps, and zm can usually handle it. But the picture is not great. And that's only ONE camera. I was planning on rolling out 9 or 10 more cams.

[tduncklee]

Add ?tcp to the end of the url to force ffmpeg to use tcp. This should stop the smearing.

[Basildane]

Add ?tcp to the end of the url to force ffmpeg to use tcp. This should stop the smearing.

I lowered the resolution and the system is doing better now. However, I do use ?tcp on the ip cams. Wireshark shows they are still connecting by udp.

[bbunge]

I had this same issue with ZM 1.25.0 and my recent upgrade to 1.26.4. Running Ubuntu 12.04 LTS. I actually rebuilt the server with a fresh Ubuntu 12.04 Server, X264 and ZM 1.26.4 from the Launchpad repository (see my how to in the Ubuntu specific area of the WIKI). I have 11 Linksys IP cameras, 1 Vivotek IP camera, and 1 Logitech USB camera on a Core 2 Duo, 2.66 MHZ with 8 GIG RAM. The Vivotek was running on FFMPEG H.264 stream and recording smeared images every two minutes or so.
Earlier tonight I switched the Source to Remote
Remote Protocol: RTSP
Remote Method: RTP/RTSP
Remote Host Name: IP of camera
Remote Host Port: 554
Remote Host Path: set to the H.264 camera stream setting

Happy to report it has been over two hours with no smeared images! Only things that move get recorded.

bb

[Basildane]

I've dropped my resolution down to 1280x960, 20 fps, 4,096 kbps.
No smearing now.

Looks decent. Now I just have junk cameras to deal with...

[sogood007]

Add ?tcp to the end of the url to force ffmpeg to use tcp. This should stop the smearing.

I lowered the resolution and the system is doing better now. However, I do use ?tcp on the ip cams. Wireshark shows they are still connecting by udp.

I have the same issue with ffmpeg. It fixed after appended the ?tcp in the link. Thanks tdunklee so much for the suggestion. For the record, I also tried using "Remote" mode instead of FFmpeg. It had less smearing issue but it used 100% of CPU of the zm process. Using ffmpeg with ?tcp, it uses much less CPU time

I also run netstat which confirm the rtsp connect is tcp.
tcp 0 0 192.168.0.111:48079 192.168.0.134:554 ESTABLISHED

NOTE: I appended the tcp in the Source Path as below
rtsp://<user>:<passwd>@IP/play1.sdp?tcp

[pezed]

I can confirm the same problem on hikvision 2cd2112 cameras. I compiled ffmpeg and zoneminder from source and the issue seems to go away.

Good version:

ffmpeg version N-57330-g610a8b1
built on Oct 22 2013 19:49:24 with gcc 4.8 (Ubuntu/Linaro 4.8.1-10ubuntu8)
configuration:
libavutil 52. 47.101 / 52. 47.101
libavcodec 55. 37.102 / 55. 37.102
libavformat 55. 19.103 / 55. 19.103
libavdevice 55. 4.100 / 55. 4.100
libavfilter 3. 89.100 / 3. 89.100
libswscale 2. 5.101 / 2. 5.101
libswresample 0. 17.104 / 0. 17.104

[Basildane]

It is crazy. For me, I had a problem on camera 1 with smearing. For the past 2 weeks, I've had no smearing on camera1, but the problem jumped to camera 8. Camera 8 now goes into alarm every 10 seconds because of corrupted / smeared image. And nothing has changed in camera 8 for over a month in terms of configuration. It's just insane.

[pezed]

Whats your load average and IO wait % like? I have noticed if I cause heavy disk access on my system it will cause smearing. I am running a core2duo E8500 on a single 7200rpm disk. My load avg is normally around 1.1 with 6 ip cams at 640x480 and 1 at 1280x960.

[Basildane]

Whats your load average and IO wait % like? I have noticed if I cause heavy disk access on my system it will cause smearing. I am running a core2duo E8500 on a single 7200rpm disk. My load avg is normally around 1.1 with 6 ip cams at 640x480 and 1 at 1280x960.

My load is around 1.57 average.
I have 6 analog low-res cameras, and 2 1280x960 HD cameras.

Server is a dedicated i5, with 8 gigs of dual channel memory, SATA-6 drive, Gig Ethernet.
I do not know how to find my IO wait %.

I have htop installed...

[c128]

How performant, for h.264 cameras, is the ffmpeg supplied with the Puppet install of Zoneminder?

I see terrible smearing, as posted here, with a Merit Lilin 1080p camera - the only way I can (mostly) avoid it is by dropping the resolution, bit rate and fps considerably, but then quality suffers... Everything's fine with the camera's own web view.

The ffmpeg supplied with the Puppet install is the following:

Code: Select all

ffmpeg version N-56672-g5dc6c0e
built on Sep 26 2013 20:50:41 with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5)
configuration: --enable-shared --enable-swscale --enable-gpl --enable-libx264 --enable-libvpx --enable-libvorbis --enable-libtheora
libavutil      52. 46.100 / 52. 46.100
libavcodec     55. 33.100 / 55. 33.100
libavformat    55. 18.102 / 55. 18.102
libavdevice    55.  3.100 / 55.  3.100
libavfilter     3. 87.100 /  3. 87.100
libswscale      2.  5.100 /  2.  5.100
libswresample   0. 17.103 /  0. 17.103
libpostproc    52.  3.100 / 52.  3.100

[c128]

I see terrible smearing, as posted here, with a Merit Lilin 1080p camera - the only way I can (mostly) avoid it is by dropping the resolution, bit rate and fps considerably, but then quality suffers... Everything's fine with the camera's own web view.

Well, oddly (or maybe not - dunno ) I seem to have completely removed my smearing/lines by tweaking an RTSP setting on the camera - I upped "RTSP Package Size" from its default minimum of 1KB up to the 64KB maximum. I've no real idea what this does (nothing in the documentation with the camera) but the only thing that seems to have changed is that I no longer have corruption of the image in Zoneminder.

[3esmit]

Can you try running some commands to stress the CPU to see if it get worst or if it triggers the problem?