Camera picture Glitches

[ryan]

Foscam is primarily a Chinese corporation with many multinational offices, I'm not entirely sure how connected their various arms are. I will follow up with them momentarily, try to bump things up in the queue.

We try to have as conservative a policy on adding cameras to the application as we can, in that we only add cameras that we have personally used or that users have written in and notified us they are using. If we were more lax it would be simple for us to arbitrarily add every camera in existence without knowing whether it can successfully connect or not. Still, these configurations can only be as good as "If you own this camera these are the settings that should allow you to connect" rather than "We recommend this camera". I can't remove the setting from the application as this would disrupt users with that camera configured, but I can see about removing it from our website if that is being taken as a recommendation.

Because we do try to remain neutral and work with everyone, we avoid giving any specific recommendations. That being said, I've posted the following generic recommendations before:

General IP camera (or electronics as a whole) recommendations -

1) There is truth to "you get what you pay for". That isn't to say that cheaper cameras might not be perfectly suitable for some users and situations, but as price goes down often too does quality, reliability, and ease of use.

2) Read reviews from people who own the camera, whether on amazon or another site. They've lived with it, if they love it or hate it they'll let you know. Be wary of bad reviews coming from user error or something tangential, but if there are a lot of negative reviews it is a bad sign.

3) Check out the manufacturer's website. If they don't have one, or it has no real content, avoid. They should have easy access to firmware updates, manuals, and tech support. If they don't, or if there tech support forum is filled with issue after issue, avoid. Axis for example makes it very easy to obtain information and support.

[Thomas]

Hi Ryan

Just want to comment regarding Foscam H.264 cameras.

I have installed a FI9805W connected through power Ethernet and it’s working perfectly with Sighthound. My setting of the camera is:

Resolution - 960P
Bit Rate - 1M
Frame Rate - 10
Key Frame Interval - 10

It’s been working so well that I’ve just replaced my Linksys WVC210 with a FI9831W and the picture quality improvement is like night and day despite the fact that the Linksys costs more, (way more, a typical case that "you get what you paid for" does not always hold). The camera is connected through wi-fi since it is closer to my router.

My conclusion is that Sighthound does work well with Foscam H.264 cameras.

Thomas

P.S. A little bit off topic: it would be nice if Sighthound can charge $30 per additional camera as I am thinking of adding a third camera but paying +$190 for its license is ridiculous.

[Fribur]

Hi ryan,

Blaming Foscam is a dead end in my view. I got a Vivotek FD8372, and I can nicly reproduce these glitches that start at the bottom of the picture by just inreasing CPU load, regardless how I do this. I could for example access a stream of 1600x1200, and I got massive glitches, but only in Sighthound. accessing the same stream in parralell using the ipad, the picture is just fine. Accessing now a stream that is just 800x600, no glitches whatsoever. Increasing the Priority of all Sighthoudn threads helps a bit when its borderline. Borderline means about 60% CPU usage, movements in the picture increase this temporarily to 100% --> bang, glitches.

You could solve this

(1) have sighthound access two streams, e.g. 640x480 h.264 for movement detection, 1920x1080 h.264 for storage, just not sure how you get the overlay boxes into the stream without decoding it. BTW, implementing this you could also allow the user to configure a third h.264 stream low res stream (320x200) for Smartphone acess, without laggy re-encoding....
(2) same as one but accessing just one e.g. 1920x1080 stream, from which a low res version is created for the resource hungry movement detection algorythms (and cor Smartphone acces)
(3) dive a bit into ffmpeg how to prevent that a not fully decoded frame is handed over to the movement detection algorythm, to prevent such glitches are detected as movement
(4) Let DXVA do at least some of the decoding work to offload the CPU

In any case, just dumping the camera stream onto the harddisk or sending to the Snartphone with out decoding and re-encoding would be so nice, as the camera stream ist just fine. its just Sighthound that cannot keep up...For this I would even accept not having yellow/green boxes around moving object...these boxes come at quite CPU price (that I would not pay if I had a choice)

Would ve nice if you could give this a thought,
Fribur

[ryan]

@Thomas

Thanks for sharing. It is true that these cameras can work well but can also have trouble in certain configurations.

@Fribur

I suspect that your Vivotek issue when increasing CPU load is related to lost/dropped/delayed UDP packets, a TCP connection should prevent this. The unique oddity with the Foscam models is that the content itself seems to arrive "damaged" in some cases, outside of network issues.

Thanks for the suggestions. Unfortunately 1&2 would not help, as the feed we receive is still damaged. As these problems seemed to occur more when these models are under heavier load, requesting additional streams may actually exacerbate the problem with these cams.

With regard to 3, throwing away all subsequent frames until the next key frame is received would be possible, as would be turning off recognition, but if something serious was occurring this would not be the desired behavior.

On 4, DirectX is a windows only technology (with parts available only on some editions). While it will likely make sense for us to investigate OS specific technologies in the future, at the moment keeping as much shared codebase allows us not only to more easily support multiple platforms, but also provides us with extra resources to work on new features rather than writing the same components multiple times.

Best,
- ryan

[Fribur]

Thanks for the reply Ryan. Related to UDP: nope, camara is configured to send TCP.

Its really just Sighthound that cannot keepup decoding, accessing the same streams in parralell using other devices works just fine. Therefore I stick to my proposal of having Sighthound accessing different resolution streams to invest decoding power only where its absolutely necessary (movement detecting), and otherwise on user request optionally just pass trough camera streams to Smartphone/Storage. As for DXVA: I am aware of the restriction to Windows. Does ffmpeg really not offer anything that can be re-used on all platforms? https://trac.ffmpeg.org/wiki/HWAccelIntro

Don't want to keep the discussion circling endlessly, but offering more options to deal with the different needs for storage, smartphone, and movement detection towards the stream resolution would be really high on my wishlist. e.g. It really buggs me to have only a choice on Android to wait 10 second until the 300kbit stream is encoded (hls, h264), or to alternatively quickly without delay access an outragous 10Mbit MJPEG stream via 4G....its a bitter pill either way..delay or bandwith. Knowing the camera offers already free of charge without delay a h264 stream that I cannot access via the sighthound app is just..unfortunate.

So I use the "IP cam viewer" app instead for instant mobile access after an alarm was triggered (and two apps instead of one is just painfull)

Best wishes,
Fribur

[Max&Leo]

I keep hearing about how Foscam needs to fix this, but I paid Sighthound some unbelievably large sum of money. What was that for? What solution are you working on for our software other than emailing Foscam?

[Fribur]

I second that. Please Ryan, consider for a moment the underlying issue to the entire thread could truely be just a Sighthound decoding issue, nothing else. No damaged streams due to nasty Foscam or UDP (well, the latter dos indead damage streams). When I read the thread, there is sufficient evidence for that....please also consider some on the thread might have sufficient IT background to analyze such a problem.

Thanks,
Fribur

[ryan]

I don't believe I ever said that this is an issue that Foscam must fix and we won't spend any time on, and if anything was interpreted that way I apologize. I mentioned reaching out to them for assistance and providing them with technical information and reproduction steps on the issue (not using sighthound video) as there very well may be issues they would like to address on their end as this is not only an issue in our software.

The speed of remote streams starting up is something we've improved in the past and will continue to work on in the future. Unfortunately your camera has the benefit of constantly encoding those streams and having them ready. We could do that in Sighthound as well, but it would increase CPU usage for each camera to encode extra streams that are typically not in use.

[Fribur]

Ryan: thanks for not loosing your patience with us

So if I may, let me ask another question...Just realized already the first post includes a picture that shows the decoding artifact is Sighthound specifc, and does not occur in the parrallel running Firefox (similar to my obervation).

So why is your first recommendation still "check if you transmit using lossy UDP instead of TCP"? Isn't the very first post already indicating the root cause is somewhere else (specific to sighthound) and UDP is just an additional/side issue? Would not lost packets cause the same type of glitch in parrallel in Firefox and Sighthound?

[ryan]

@Fribur

The stream used by a camera's webpage is very often a different stream than you will be connected to from a different app. Consider even the fact that for HD cameras the stream shown on a webpage is often a much lower resolution, let alone differences that may exist in transport and even codec. The following doesn't apply to that scenario, but as your comment was leading into other theoretical general networking scenarios consider two arbitrary clients connected to one source. They each have a unique data stream - just because I drop two postcards in the same mailbox addressed to the same person does not mean they will both arrive at the same time (or arrive at all).