Swann Bullet Cams: Trouble in Paradise

[dvarapala 0]

I've run into an issue with the Swann 825CAM bullets I recently bought from Costco. Periodically they generate "smeared" frames that look like the attached image. This happens on both cameras in 3MP mode using both UDP and TCP transports; I tried switching one to 1080P mode and so far no smeared frames, so it may be an issue with the 3MP capture mode. Needless to day, these occasional smeared frames wreak havoc with motion detection, generating several false positives every hour.

 

I recall seeing a Swann tech support rep hanging around the forum a while back; if you're still out there I'd appreciate hearing from you.

 

Anyone else experiencing this issue?

[Boogieman 1]

I've run into an issue with the Swann 825CAM bullets I recently bought from Costco. Periodically they generate "smeared" frames that look like the attached image. This happens on both cameras in 3MP mode using both UDP and TCP transports; I tried switching one to 1080P mode and so far no smeared frames, so it may be an issue with the 3MP capture mode. Needless to day, these occasional smeared frames wreak havoc with motion detection, generating several false positives every hour.

 

I recall seeing a Swann tech support rep hanging around the forum a while back; if you're still out there I'd appreciate hearing from you.

 

Anyone else experiencing this issue?

set the I-frame to be the same as the fps....see if that helps..

[MaxIcon 0]

This is often caused by corrupt packets, not to be confused with dropped frames. These can be tricky to track down.

 

I have a Messoa NCR870 that has corrupt packet problems, and will do this if the network parameters aren't set just right. Setting the bit rate too low is just as bad as too high. This is a camera bug, though, so yours is probabably different.

 

Best bet is to run Wireshark and have it check the packets coming from your camera's IP address. It will show if there are any corrupt packets. There are lots of simple Wireshark get-started tutorials.

 

To isolate it, start with simple stuff like changing cables, POE ports, disconnecting other equipment from the network, etc. If you have a 12Vdc PS, you can run it directly to a laptop or PC to see if it's something else on the network causing problems.

 

This is assuming that settings tweaks don't fix it, such as matching the i-frame to the frame rate, reducing the bit rate, changing from CBR to VBR or vice versa, etc.

Edited February 6, 2014 by Guest

[SB_Jim 1]

I once had a couple of occurences like that (using the Swann NVR). I didn't see them live, but saw them on playback. The Swann Lev 2 tech recommended re-starting my NVR and re-setting the config to factory settings. Note: save your config file first for loading once you've re-set to factory.

 

In my case - this fixed the issue, and I haven't seen any signs of that anomaly since that time many months ago. Don't know if you're running your cams to a PC, or using the NVR. Thought I'd share my experience nonetheless.

 

Good luck.

 

Jim

[Swann Tech 0]

Hi mate,

 

What firmware version are the cameras on?

[buellwinkle 0]

Probably not Swann Firmware if he's running 3MP

[drocer 0]

Probably not Swann Firmware if he's running 3MP

 

The last swann NVR package and now 2-pack from costco do 3MP with Swan firmware. It's in the drop down box on both. Confirmed personally and the firmware versions here:

 

viewtopic.php?p=240489#p240489

 

3MP mode on swann firmware is likely still buggy/lagging hikvision's firmware.

[dvarapala 0]

Hi mate,

 

What firmware version are the cameras on?

 

These cameras drop-shipped direct from Swann in SoCal with 5.0.0 firmware on them.

 

After some more investigation, this appears to be a dropped-packet issue. Not only does reducing the resolution reduce the problem, but moving the cam from one PoE switch to another also helps; apparently my little Trendnet TPE-S44 PoE switch is starting to give up the ghost.

 

I turned on debug logging in ZoneMinder (which uses the FFMPEG libraries to decode H.264 streams) and I'm seeing a ton of lost RTP packet errors. Apparently if the packet loss is sufficiently large it overwhelms FFMPEG's ability to conceal the errors, resulting in the garbage frames.

 

One common solution to this sort of problem is to use TCP as the transport layer. Unfortunately this camera doesn't seem to support this option; although FFMPEG is configured to use TCP if available, the stream still ends up coming across via UDP packets. Hopefully Swann/Hikvision will add this in a future FW release.

 

In the meantime, I'm going to hack the FFMPEG code to simply discard any corrupted frames (i.e. frames with too many missing RTP packets) rather than deliver them to the application. When doing motion detection, it's better to have no frame at all than to have a garbage frame where 70% of the pixels are different from the previous frame.

 

Update:

 

The lost RTP packet issue turns out to be a bug in the FFMPEG library that ZoneMinder uses to decode H.264 video streams. Apparently there was also a change in the method needed in order to force the RTP packets to be carried over TCP; in the past, you could append a "?tcp" to the end of the RTSP URI to force FFMPEG to use TCP for the stream, but that no longer has any effect. It now requires a code change to switch over to TCP. However, once I made the change, the smeared frames disappeared completely.

 

Now I'm off to order more of these awesome little cameras.