All green image distortion, in camect but not in other app

[deesp...@gmail.com]

just got front and back doorbell cameras from what seems like a generic brand XTU. i specifically picked out something that's onvif capable to use with camect, as many doorbell cameras seem to be locked in to the manufacturer's apps and services. they were both looking great earlier today but when it got dark one of them started looking all green and kind of distorted like in the attached picture. I saw flashes of this effect periodically on both cameras earlier but they were generally running fine all day. I don't see this effect at all in the app that I used to set them up, called CloudEdge, so i presume it must be something about how camect handles the stream.

any help would be great. i'll try some more basic troubleshooting like rebooting the cameras and so forth later but nothing i've done on the app side has gotten this one back to looking normal yet.

[CamectArup]

Are these cameras on WiFi? Is the WiFi signal strong where they are? 

Green video is usually a symptom of data loss occurring somewhere between the camera and Camect. It could be in the network (e.g. WiFi), at the camera (if you're pulling more streams than the camera can handle) or even due to bad wiring, e.g. between Camect and your router. 

Some apps hide the data loss from you by only showing the last "good" frame received until the next one arrives ... i.e. you don't see the problematic frames that cause the green video. This might be why your app appears to be fine while in Camect it is not. 

Also, one other possibility (but much less likely) is that there's a problem with the data flow between your Camect device and your viewing device. I don't think that's the issue here because you're not seeing the effect on all cameras. You can check by exporting a video clip and playing in an external player. If you get weird-looking video (not necessarily green, but on VLC it may be green) then you know the issue is between the camera and Camect.  (For the same reason, I don't think it's the network cable between Camect and your router -- a bad cable would also cause problems on all cameras.) 

[Dolf Starreveld]

Images like this are generally indicative of (de)coding errors in so-called key frames. Any frames other than key frames essentially only encode the differences relative to key frames so if something goes slightly wrong in the key frame, it would be visible for quite a bit, until another key frame comes by that does not have a problem.

What kind of problem? In my experience (I used to do JPG and MPEG work at the standards committee level) what you see is indicative of the so-called DC component of one of the RGB channels getting messed up. If, for example, the green channel accidentally gets a much higher value, everything looks overwhelmingly green, yet if the non-dc component is not messed up (comes a little later in the bitstream), there can still be some level of detail.

Where does it come from? Well the typical source of problems is some kind of encoding/decoding software error (somewhat unlikely these days), or a transmission error (that went undetected), or a storage error (if what you are seeing went to storage first). Transmission errors are more likely with WiFi, but still should be caught and handled instead of this happening.

Since you describe it only happening when viewing through Camect and not the native app, one would think it is a Camect problem, but… In my experience Camect is quite robust in this regard so if it were Camect, I would venture to guess an intermittent (storage?) hardware problem. On the other hand, if the Camera manufacturer is cheap and did their own encoder software they are likely also use their own in the receiving application. It is not unusual, historically, the encoder and decoder produced by the same company handle each others idiosyncrasies or errors so that when you have a combination of encoder (camera) and decoder from another software origin problems can become visible. You can exclude this theory by looking at the camera with yet another software such as VLC.

On May 3, 2021, at 21:40, deesp...@gmail.com <deesp...@gmail.com> wrote:

just got front and back doorbell cameras from what seems like a generic brand XTU. i specifically picked out something that's onvif capable to use with camect, as many doorbell cameras seem to be locked in to the manufacturer's apps and services. they were both looking great earlier today but when it got dark one of them started looking all green and kind of distorted like in the attached picture. I saw flashes of this effect periodically on both cameras earlier but they were generally running fine all day. I don't see this effect at all in the app that I used to set them up, called CloudEdge, so i presume it must be something about how camect handles the stream.

any help would be great. i'll try some more basic troubleshooting like rebooting the cameras and so forth later but nothing i've done on the app side has gotten this one back to looking normal yet.

<Screenshot 2021-05-03 233322.png>

--
You received this message because you are subscribed to the Google Groups "Camect User Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to forum+un...@camect.com.
To view this discussion on the web visit https://groups.google.com/a/camect.com/d/msgid/forum/bc67c9df-5b18-421a-a3ac-89995285cee6n%40camect.com.
<Screenshot 2021-05-03 233322.png>

[Dolf Starreveld]

Oops, just now saw Arup’s answer and we’re overlapping in explanation and opinion. Sorry about that...

[CamectArup]

No need to apologize. I thought the technical details were actually a nice addition. 

[deesp...@gmail.com]

thanks for quick responses. is there any trick for getting the signal back to a good keyframe? should rebooting the camera help? it's a slight physical hassle so i'll avoid it if there's no hope. i'll try exporting clips to view in other players and report back. these are both wifi cameras and i do have a lot of stuff connected to 2.4GHz so loss during transmission sounds probable, except that i'm not seeing the same effect persisting on the other app. the possibility of pulling more streams from it than it can handle seems plausible too, as i've been running at least a couple streams or more all day while we try out the different features etc. but then i would expect to be able to get it to go back to normal appearance by disconnecting streams (if i haven't misunderstood the keyframe concept).

if it does wind up being a double-ended encode/decode issue with this product, do you happen to know if there's a good alternative firmware i could install without excessive hassle?

[deesp...@gmail.com]

I went ahead and attempted the hard camera reboot, which got me back into non-green color right away. would still love to understand more of the details if you don't mind elaborating, and hopefully end up with something a bit more conclusive about where this problem originated in case i have to deal with it repeatedly.

[Dolf Starreveld]

I couldn’t see clearly enough in the image you posted, but here is a possible clue: If the image not only showed the green tint, but also strings of “blocky” artifacts then what you were seeing was likely a data error in the bitstream, either through incorrect coding, transmission, or storage. If there were no artifacts, there is another possibility and that is that the camera itself has a hardware problem with its frame buffer.

On the other hand, that would not allow it to be seen without problems in another app. Again, testing with VLC is important to give some more clues. You want to configure VLC to tap into the camera’s RTSP stream (you can use Camect to find out the URL it uses for that). This way you are completely exploding Camect from the testing path and directly decoding and showing data coming from the camera.

Arup already mentioned that different SW handles data errors differently. One approach is that when there is a data error, you simply discard the frame with the data error. If that frame is not a key frame, you have a “skip” lasting 1/15 or 1/30 of a second. You’d never notice. If it is a key frame the skip would have to be until the next key frame. Depending on what happens in the view, you might still not notice. A completely different approach relies on the fact that, to some extent, the bitstream for each frame in the video encoding is somewhat able to recover from coding errors and so you would use that to display on “best effort” basis. That could easily result in the green cast as Arup also explained.

It also sounds that the green “thing” persisted for quite some time. The description related to key frames that I gave would not persist for more than part of a second up to perhaps a few seconds, because that’s how often new key frames should be inserted (rebooting starts a new stream, which starts with a key frame as well so that is why it fixed the problem, at least temporarily). If it persisted longer than that it is not simply a matter of a spurious data error, but rather something more systemic, likely in the camera. The possible encoder implementation error is still a possible explanation in that case.

Resetting the camera fixed it, so staying with that theory I would guess an uninitialized piece of memory somewhere.

I don’t know these cameras so cannot say anything about alternative FW. Typically though, these things are specialized enough that you cannot install alternatives easily at all (even if they could exist).

Is this just one camera that shows the problem? Consistently? Only at night? Nightvision images are very different from a typical daytime full color image so that may expose a SW problem that otherwise doesn’t manifest. You did mention that earlier both cameras showed the problem periodically. That would suggest it is not an individual product hardware problem (it would be extremely unlikely).

Does the playback of recorded video using Camect also show the green? If so it might be possible to save the clip and have it analyzed by Camect to see exactly what goes wrong. That might give clues.

[deesp...@gmail.com]

thanks for the extra explanation, much appreciated

after observing some more today, i'm thinking this may be mostly a wifi overload issue. the green effects are definitely intermittently recurring fairly often (perhaps once a minute) but not staying stuck in all-green like that first night. i'll get a brief flash of green on the whole image, or just the bottom half, or a "blizzard" effect with blobs of green distortion migrating down and to the right for a few seconds before going back to normal. in some cases i'm seeing blockiness and low framerates/freezing at the same time. this is both cameras, not just the one, but it definitely affects the front door cam about 10x more often than the back door one. perhaps related to more solid materials being in between it and my router, much more wireless hardware in use in the front room, etc.

i'll try capturing some clips to share if possible soon. i'm still getting acquainted with the UI and preoccupied with other projects. i'll also do the vlc testing you mentioned, when i get a break to tinker with that.

if it does turn out to be a signal or bandwidth issue, that should be no big deal as i'm going to need to upgrade my wireless gear sometime soon anyway. most of these consumer grade wifi routers are built and advertised to support a handful of devices, not the dozens we have these days.

[Billy Milchak]

I had same issue it's definitely camect box, my internet is blazing fast with a brand new router, I view my cameras on 3 different apps and not a single issue, but on camect app I get live video that flickers, or turns green like yours. I realized camect was lowering my video settings inside my camera to a setting very low from about 20 fps to about 7 fps I had to uncheck optimize settings on new cameras to get camect to stop messing with my video settings. Since then I don't have the green screen and the flicker doesn't happen much. Hopefully that w will help. 

[Alan Day]

Hi,

We have seen this a bit and we have found that changing the encoding from H265 to H264 helps 

To view this discussion on the web visit https://groups.google.com/a/camect.com/d/msgid/forum/8d3138af-977a-44d2-a8a7-628f0abae884n%40camect.com.