Camera picture Glitches

[bill]

Ryan,

Yes, you are correct. Changing the router port setting should not matter as I am using
SH within my network.

I am adding the camera as you are showing. I select Foscam as the manufacturer first, then the camera setup with the stream path forcing TCP.

Bill

[ryan]

@bryan - that's quite a frustrating upgrade path. As Jeremy mentioned, I'm not sure if there is a 'good' firmware version to use. I don't have one of these so I can't speak to it personally.

Unfortunately there are lots of posts on this sort of issue with these cameras around the web, including foscam's forums, with no real solution. We'll have to try to get one of these cameras and find an opportunity to examine it and see if there is something we can do to detect and work around these video errors.

[jeremyclark]

@ryan

I was planning to purchase another Foscam 9805E, especially if we're able to get the feed to more reliably work in Sighthound. Would it help out if I had it shipped to you in order to test and troubleshoot, and then you could send it on to me after you've had a chance to try to fix the issue?

[bryanw20]

I guess I still don't understand what's wrong.

I've had my FI9805W (connected wired) up for a couple of days now; and all the clips in SH are normal. (I wish I could find a better bright/contrast setting for day/night)

So it it 'smearing' alert clips, or what is going on?

I'm now afraid to touch my cam, esp firmware!

Bryan

[ryan]

@jeremy

Appreciate the offer. Typically we would connect to a forwarded camera to attempt to troubleshoot, but given the nature of this problem that might not work in this case. I wouldn't be terribly comfortable taking physical possession of a camera due to any accidents/lost mail that could occur, and I'd also hate for you to buy a known troublesome model in the hopes that a fix would be found and then that not occur, or not occur in a timely fashion. I'll look in to acquiring one of our own.

@Bryan

Glad things are working for you. The type of error periodically seen in the screenshots from this thread are due to lost or damaged packets, typically due to being sent over UDP, an unreliable transport. This is usually easily addressed by choosing TCP instead (slight overhead on the networking, but ensures in-order delivery of data). As that doesn't seem to help here, it could be that the camera itself is generating damaged frames, perhaps a bug in the encoder, or the camera is overloaded and the cpu can't keep up, or who knows.

The problem with damaged packets is that in h264 video key frames (full frames) only occur periodically, with all frames between only having information about what changed - that's why the "streaks" stick around a while. Best case is realizing a packet has been damaged and throwing it away - no big streaks, but as each subsequent frame depends on the last you'll still get some odd video effects until the next keyframe - trailing, ghosting, etc...

[bill]

Ryan,
Please keep me updated, as I have 5 cameras and no way to record........

Thanks,
Bill

[303]

Hi Sammi,

You can append "?svforcetcp" to the end of your stream path to have the software connect over TCP rather than UDP (a lossy protocol). For more detail please see viewtopic.php?f=3&t=11523

Could you folks just include this toggle in the camera config wizard instead of our having to do a manual camera entry?

[303]

@ryan

I was planning to purchase another Foscam 9805E, especially if we're able to get the feed to more reliably work in Sighthound. Would it help out if I had it shipped to you in order to test and troubleshoot, and then you could send it on to me after you've had a chance to try to fix the issue?

Your mistake is that you are planning to purchase another foscam. 99% of all my camera problems in the past came from foscam and their crappy products.

[ryan]

@303 - if it remains a necessary option for some users long term we'll definitely add a UI toggle for it.

@others -

I got an FI9805W. No matter what settings I have configured the video is extremely stuttery, normal frames for first half of every second, then pausing in the second half. I grabbed a precompiled build of ffmpeg pulled quite a few streams. By default it seems to work somewhat OK, with the occasional glitch. Surprisingly, when I request tcp rather than udp I get glitches nearly nonstop. I'm not sure why the camera suddenly starts pumping out damaged frames when pulling tcp.

Summary: with the 9805 (and likely other h264 models?) don't use the ?svforcetcp flag. Assuming that the damaged frames in UDP mode are coming from packet loss and not whatever kicks into overgear in tcp mode, I'd instead do normal UDP alleviation steps such as reducing bitrate.

[jeremyclark]

@ryan

Thanks for the update, and for locating a 9805W to test with! When you use the Foscam plugin in Safari, are you seeing any of the same artifacts? I don't seem to get any of them when viewing that way, which makes me think they're doing something non-standard with the stream but are able to render it properly because they control the renderer.