ZoneMinder Forums

Hi,

I purchased a Grandstream GXV3615W and I am having problems with the video which shows artifacts constantly which trigger constant alarms. The video looks fine when seen through the camera's web interface. I am guessing this is some ffmpeg problem... By the way, I also have an Axis camera and it works fine in h264.

• System: Ubuntu 11.04
  
  Zoneminder 1.25.0
  
  camera configuration: ffmpeg / rtsp://admin:admin@camera.ip:554
  
  ffmpeg -version
  ffmpeg version N-34613-g11e155c, Copyright (c) 2000-2011 the FFmpeg developers
  built on Nov 9 2011 14:08:10 with gcc 4.5.2
  configuration: --enable-gpl --enable-shared --enable-pthreads --enable-libx264 --enable-libfaac --enable-nonfree --enable-x11grab --enable-version3
  libavutil 51. 24. 0 / 51. 24. 0
  libavcodec 53. 29. 0 / 53. 29. 0
  libavformat 53. 20. 0 / 53. 20. 0
  libavdevice 53. 4. 0 / 53. 4. 0
  libavfilter 2. 47. 0 / 2. 47. 0
  libswscale 2. 1. 0 / 2. 1. 0
  libpostproc 51. 2. 0 / 51. 2. 0
  ffmpeg N-34613-g11e155c
  libavutil 51. 24. 0 / 51. 24. 0
  libavcodec 53. 29. 0 / 53. 29. 0
  libavformat 53. 20. 0 / 53. 20. 0
  libavdevice 53. 4. 0 / 53. 4. 0
  libavfilter 2. 47. 0 / 2. 47. 0
  libswscale 2. 1. 0 / 2. 1. 0
  libpostproc 51. 2. 0 / 51. 2. 0

I'm seeing the same artifacting with an Axis M3204 if I turn the quality up on the camera. With low quality settings it's OK. This is using H.264 via ffmpeg source and trying various versions of ffmpeg.

I'd love to see a solution or even a hint.

-David

Update:

found syslog full of these messages: there is an interesting thread here: http://ffmpeg.org/trac/ffmpeg/ticket/285

I guess I am loosing packets, however I don't understand that the video looks good on VLC (and on the web interface of the camera)...

Hey thanks! I was able to work around the problem by forcing tcp using the "media.amp?tcp" syntax mentioned by someone in that bug.

-David

I guess I am loosing packets, however I don't understand that the video looks good on VLC (and on the web interface of the camera)...

I figure that's accurate if low quality is working and high quality isn't. It's very possible that your route/switch topology has a bottleneck and is dropping packets in the queue. If the video/alarming systems are high priority you might consider enabling QoS if it's an option on your equipment. Aggregation (ex. etherchannel) might be another option if it's only making a few hops from the camera to the server.

idk if your endpoint supports compression, but that might be another way to go as well.

If that's not the issue you might try rolling back the version of ffmpeg you're using and reinstalling zoneminder as well to see if it is in fact the codec being used. If it's on the endpoint side, you might have some serious issues trying to fix it yourself and might have to return it to the manufacturer.

I was having the same h.264 artifacts that you were experiencing. Was following through this thread and did find a resolution (at least for me). I was using MJPEG and really wanted to use RTSP. Anyway, it seems like for my cameras Axis P5534 and Axis P3301, by using the following:

rtsp://<ip address of camera>/axis-media/media.amp?tcp

seemed to work for me. I followed it through a related post in this thread. When I was using it without the "tcp" flag, I guess it was in UDP mode, and it would literally wash out the picture. After using the above link, I'm able to even stream TCP RTSP through an OpenVPN bridge (back home) across WAN for 3 cameras and they run smooth over Quicktime (anonymous, no auth). I was having RTSP Auth problems with quicktime, but VLC RTSP Auth worked just fine.

Hopefully for your camera you will find something equivalent to switch the protocol to TCP method instead of using UDP.

Stonith