Camera picture Glitches

[303]

Hi Ryan, thanks for your continued support.

I have added the forced tcp query and continue to get glitches in 3 different wifi cameras from 3 different manufacturers.

I am simultaneously running SecuritySpy. SecuritySpy does not get the glitches. Do you have any idea how I can help debug this?

As a side measure, since we know that many users are experiencing this, could you implement a function to ignore stretched pixel / packet drop glitches as false positives?

[Fribur]

Its pretty clear since a while this issue is not restricted to Foscam or lost packets when using UDP. I struggle to understand why this is still recommended as a solution, while its clears the issues are due to some issues inside Sighthound/ ffmpeg. Threading issues, decoding issues or whatever when the CPU is close to maximum load. The issue happens when CPU load spikes to 100% even for just some milliseconds. I think Sighthound would do themself a favor just looking into this issue instead to continue to recommend solutions that do not address the most likely root cause.

Puzzled....reminds of how the company Soundgraph deals with issues that are reported to them....denial, distraction, ignoring those issues...

Evolutionary selection: eventually such a company culture will not pay off. Too bad as the software has potential...

BTW: a fix that works for me is using a tool that gives all Sighthound threads maximum priority.

[Semper Vaporo]

[snip}

BTW: a fix that works for me is using a tool that gives all Sighthound threads maximum priority.

What tool is that?

[ryan]

@303 - what are the camera models and settings you are experiencing trouble with?

We are hard at work on improving both tracking and recognition algorithms, these should certainly not be recognized as 'people'. There may be additional interim heuristics to ignore the glitches we can insert, but hopefully we can avoid the issues in the videostream prior to this.

@Fribur - I'm sorry you're experiencing this issue and I assure you that we would of course like to have any such problems corrected in the application. The tcp fix is often offered as a solution as this actually does address and solve the root cause of vast majority of cases, not as a distraction. We have done exploration into the few cases which have other causes and will do more. Once found, addressing these issues will likely require the integration of alternative transport/video libraries and a substantial rewrite of the video subsystem, which simply isn't something we have had the resources to prioritize over other work. Despite the low occurrence rate for cases which are not UDP related it certainly one of the highest priorities on my list and I hope it will be addressed soon. I'm not aware of issues triggered by higher CPU loads, we'll see if we can reproduce this on any cameras we own immediately.

Best,
- ryan

[303]

@303 - what are the camera models and settings you are experiencing trouble with?

DCS-942L and another D-Link Cloud Camera that is similar but I can't remember the model #. And a Foscam but it's garbage and I can't fault you for that.

We are hard at work on improving both tracking and recognition algorithms, these should certainly not be recognized as 'people'. There may be additional interim heuristics to ignore the glitches we can insert, but hopefully we can avoid the issues in the videostream prior to this.

Awesome! Thanks and keep up the great work. Any idea when we could get something like this? Or...

1. Any idea why it is happening in sighthound and not in securityspy?
2. Any idea what else we could do to our cameras to reduce it from happening?

[bill]

Ryan, this problem has been open almost a year now, are you any closer to a resolution?

Bill

[CrazyFin]

I am too experiencing the same issue with video glitches / video tearing in exactly the same way as everyone else has described in this thread (which now is over a year old but still no fix?).

I have tried with forcing TCP sessions (I am using 5 cameras of AXIS P3346-VE model) but what then only happens is that I see a lot of camera disconnects instead of the typical video tearing that I see when using UDP.

My network is a gigabit network and when I wath the web gui of my Zyxel PoE-Switch (model ZyXEL GS1900-8HP) I see only 5-15% bandwidth utilization on each port when the video tearing happens).

I have also set all Sighthound process in the task manager to have high priority (have tested with real time as well) but no difference.

I see similar tearing in other surveillance software programs but NEVER in Axis own software Camera Station.

Also, if I change from using H.264 to MJPEG then no tearing when using UDP.

I really think this is in issue within the software itself and how it opens/handles the H.264 stream requests. I see in the camera log that there is a "RTSP session timeout" in the log every time I see the tearing.
If I have understood the RTSP protocol specs correctly the software (in this case Sighthound) must send a request to the camera every xx second in order to keep the RTSP stream alive. See for example the following pages where similar issues with RTSP streams are discussed and that simple rtsp request like GET_PARAMETER can be sent every minute to keep the session alive.

http://sourceforge.net/p/onvifdm/bugs/23/
http://w3facility.org/question/how-to-k ... ion-alive/

AND see page 18 in the ONVIF specs at
http://www.onvif.org/specs/stream/ONVIF ... c-v210.pdf
where it clearly is stated "A RTSP client keeps the RTSP Session alive and prevents it from session timeout"


So the question is if Sighthound keeps the RTSP sessions/streams alive properly as described in the above document?

(A small note: I forgot to mention that if I access same H.264 stream with the same URL-path via for example VLC I do not get those glitches when Sighthound at the same time shows a significant video tearing every 1-2 minutes.)

[Devin]

Hi CrazyFin,

We do believe that timeouts are being handled properly, but I'll pass along the information you provided to our engineers as they are investigating this issue. How often do the disconnects occur when using TCP?

Regards,

-Devin

[CrazyFin]

Hi Devin

Ok I have been able to get rid of the camera disconnects when using forced TCP instead of UDP.
However, the video motion using TCP is not smooth at all and it is quite jumpy.
Using UDP is much more smoother but then I get the video tearing every minute or so.

Example of stream settings (I have left out the rtsp://xx.xx.xx.xx:yyyy/ which I of course have in front of the media path.)

Force TCP (causes jumpy video)
axis-media/media.amp?sessiontimeout=0&videocodec=h264&compression=20&svforcetcp

UDP (causes video tearing but smooth video moves)
axis-media/media.amp?sessiontimeout=0&videocodec=h264&compression=20

UDP (same as above with dedicated H.264 hiqh quality profile, still causes video tearing)
axis-media/media.amp?streamprofile=Quality

UDP (same as above but with sessiontimeout param set to 0, i.e. never timeout, still video tearing though)
axis-media/media.amp?streamprofile=Quality&sessiontimeout=0

I do NOT have any video tearing at all when using the identical path with UDP streams over RTSP in for example VLC.

I have recorded some of short video clips where I have VLC stream next to Sighthound and it is very easy to see that when Sighthound has video tearing using UDP there is NO video tearing using exactly same URL in VLC.
Even when using UDP the video motion in Sighthound is a little bit more jumpy than the smooth video motion I see in VLC.

I have also recorded a clip where you can see how jumpy the video gets in Sighthound when using forced TCP instead of UDP streams.
(Let me know if you want me to email you the links where you can download my video clips.)

I have also tested with some higher compression like
axis-media/media.amp?sessiontimeout=0&videocodec=h264&compression=30 and even up to 50% compression but still video tearing in Sighthound while no tearing at all via VLC.

[Max&Leo]

I'm back. It's really unfortunate this software is still hamstrung by this issue. Based on the developer's comments in this thread, it appears they have determined this issue is too small to warrant sufficient attention for a fix.