Video target turns transparent

[Ramblin]

The only thing I can think of is that the really small zone settings cause it to detect too many blobs, and just spend too much time doing motion detection, sucking up cpu.

Well, you were right (Do you ever get tired of hearing that? ... )

The Blobs was a (partial) red herrring

I have a total of 3 cameras in normal use:
2 x Tapo C320WS (fixed camera)
1 x Tapo C520Ws (PT camera)

The setup I have (for all 3 cameras, each with 2 streams : LoRes and HiRes) to minimize CPU load is
LoRes
Modect
640x360 8 bit grey scale
Jpeg and Video storage disabled
HiRes
NoDect - Triggered from LoRes Events
1920x1080 32 bit colour
jpeg disabled; Video Storage Pass-Through

It is the C520WS that is the one with which I am having issues.

I have been focussing on it and solutions within Zoneminder, including multiple setting changes.
I even rebuilt the entire system from Debian 12 up and used "--install-recommends" for both ffmpeg and zoneminder

Same issue with transparency from he C520WS with small Alarm/Filter/Blob settings

This was with the C520WS being the ONLY camera active, with the frame rate maintaining 15FPS throughout and the CPU load not gonig above 25%. So I don't think it was just a load issue.

So I used a mobile device and pointed the browser to the Zoneminder system - viewing the C520WS monitor - while I was walking in the field of view of the camera and the video came through clean, no transparency effect, so the video is getting to Zoneminder clean.

But then I tried activating the other 2 cameras (C320WS) and setting them each to small Alarm/Filter/Blob
They each worked fine.

So something about the storage of the C520WS video on the Zoneminder system is causing an issue.

I thought maybe it was the hard drive speed. I got a dedicated WD Purple drive and used it as the storage area for all videos.

No improvement.

Is there any kind of Troubleshooting or debugging you can recommend (please be specific) for me to try and further dianose?

[iconnor]

You need to turn on debug mode, restart c as mera and send me the log for the camera. Issac@zoneminder.com. to turn on debug go to option logging and check zm_drbug. Also debug level to 3.

[iconnor]

crap I mistyped my email address. isaac@zoneminder.com

[Quantum]

No, no, no, don't listen to them.

The OP has clearly become a vampire, which accounts for the camera barely being able to discern him.

OP check a mirror. If you can not see yourself, this is the problem. Stay away from crosses and daylight.

Hope this helps...



Oh, all right: https://ipvm.com/reports/tcp-udp-video-surveillance

[Ramblin]

https://ipvm.com/reports/tcp-udp-video-surveillance

After seeing the content of the link, I thought that must be it.

But unfortunately, when I checked, the protocol in use was TCP and the transparency effect was still happening.

Maybe the vampire option is becoming more realistic...

[iconnor]

Effect can also be caused by decoding thread falling behind, or not enough buffers. In which case your logs will be filled with errors. Check your logs.

[scientist434]

I'm having the same issue, it's not a camera issue since I can record the stream straight to OBS on my windows PC and it's fine. I'm thinking it's some kind of encoding error since if I download it to VLC I get ghost effects but not at exactly the same spots.

Not sure if it's related but my streams are also turning grey, you can see some movement in the grey feed but not much. When I get back to my computer I will enable debugging and post the outputs.

Edit: found a error of Monitor shm not connected so did chmod 777 to /dev/shm and now I'm not getting the grey screen. Will keep an eye on it though it's only been an hour so might be an intermittent bug.

[Ramblin]

Sorry for teh delay in following up ...

I have found a way to remove the "transparency effect"

In the setup for the camera, I did not want to store still images and did not need to use the Hi-res colour feed (stream1 = Monitor 4) to monitor the camera feed since I use a Lo-res grey-scale feed (stream2 = Monitor 3) to trigger recording in the Hi-res feed.

So I had the Hi-Res camera setup with Storage of:
- Save jpegs: Disabled
- Video Writer: Camera Passthrough

I thought this would save on bandwidth and CPU processing.

However, when I changed the Storage settings to explicitly match what the Tapo camera spec said they used as encoding: h264
- Save jpegs: Disabled
- Video Writer: Encode ; h264 ; libx264

The Recorded video does not have the transparency effect.

Does this mean that the handshake with the camera is not properly identifying what the encoding protocol is, requiring the protocol to be explicitly identified?

I am still seeing the following errors in the Log display so not sure if this is something to worry about and if so, how can this be fixed?

Code: Select all

2024-06-20 12:54 PM	zmc_m3		3783	INF	BackYardPTZ LoRes: 25000 - Capturing at 14.99 fps, capturing bandwidth 31386bytes/sec Analysing at 14.99 fps	zm_monitor.cpp	1680
2024-06-20 12:53 PM	zmc_m4		7536	INF	BackYardPTZ HiRes: 3000 - Capturing at 15.00 fps, capturing bandwidth 149941bytes/sec Analysing at 0.00 fps	zm_monitor.cpp	1680
2024-06-20 12:53 PM	web_php		511	ERR	socket_sendto( /run/zm/zms-266689s.sock ) failed: Connection refused	/usr/share/zoneminder/www/includes/functions.php	1882
2024-06-20 12:53 PM	web_php		561	ERR	socket_sendto( /run/zm/zms-266689s.sock ) failed: Connection refused	/usr/share/zoneminder/www/includes/functions.php	1882
2024-06-20 12:53 PM	zms_e19060		7640	ERR	Unable to decode frame at frame 0: -11 Resource temporarily unavailable, continuing	zm_ffmpeg_input.cpp	205
2024-06-20 12:53 PM	web_php		3897	ERR	socket_sendto( /run/zm/zms-266689s.sock ) failed: Connection refused	/usr/share/zoneminder/www/includes/functions.php	1882
2024-06-20 12:53 PM	web_php		7604	ERR	socket_sendto( /run/zm/zms-266689s.sock ) failed: Connection refused	/usr/share/zoneminder/www/includes/functions.php	1882

Thank you again for your support.

[mikb]

IT could be as simple as the camera's highly tested, standards compliant H264 implementation falls a tiny weeny bit short of being compliant

And that when ZM gets its hands on the wonky H264 and shoves it through FFMPEG to recode it as H264, that FFMPEG is a lot more tolerant to incoming-stream-stupidity and fixes the problems, writing a properly compliant stream.

It wouldn't be the first time that has happened.

The transparency/shearing/ghost images etc. is also usually a result of corrupted and misunderstood intra-frame compression, causing the decoding to be done against wrong/bad/non-existent data.

Often gets triggered if you move around in the stream (seek) or editted the stream in some clumsy way causing the initial "I-Frame" to be lost. So the first part (or last part) of a stream can look broken because the player joined the conversation literally in mid-stream.

Suddenly, getting directions on how to manipulate the current frame *given* that the decoder state is ... "wait ... I'm missing the previous bit of the stream? Sorry. Confused. Making a mess until the next GOP (group of pictures starts). Ah, here's an I-Frame, we're good again!"

[Ramblin]

So the first part (or last part) of a stream can look broken because the player joined the conversation literally in mid-stream.

Thank you for the (easy to understand) explanation

That is likely the issue here

The other Tapo Cameras (C320WS) also show errors at the start of a recording but they seem to rectify it and get on with proper recording.

The C520WS has the errors and they just continue indefinitely.

Would the explanation you provided also explain the errors shown in the log posted above or is that another issue?

[mikb]

Would the explanation you provided also explain the errors shown in the log posted above or is that another issue?

"failed: Connection refused" seems to be unconnected to the corruptions. Not sure exactly what that's coming from though, I'm not understanding whether it's zms failing to connect TO something, or something failing to connect TO zms.

[iconnor]

I got a Tapo 520WS in order to solve this.

It works fine for me, but it gives packets with weird timestamps. I have added code to deal with it, and other than the cameras clock jumping around from time to time, it seems to be working ok here.

Working on the PTZ script.

[Ramblin]

I have added code to deal with it

Would I be correct in assuming the new code is in the most recent development version of 1.37 and not in the production version 1.36?

[iconnor]

Correct, although I may merge it to 1.36.34