ZoneMinder Forums

Hey,

I am having a bit of an issue with the Hikvision DS-2CD2186G2-I cameras on Zoneminder v1.36.5 (tho it happens on v1.36.12 just the same).
Anytime they record an event, the image is completely grey for about two seconds (specifically, 7 frames on 4 FPS): The image then "blocks in", over two frames:

getting more detailed (but still blocky) in the next frame, and being clear on the frame after that one.
After that, it's fine for the rest of the event.

My settings are Modect, with FFMPEG, over their RTSP Link (rtsp://user:pass@ip/Streaming/Channels/1?tcp), over TCP (UDP causes smearing to appear, and doesn't solve the aforementioned problem either). Resolution is 2688x1520 (which is the camera's resolution).


"Image Buffer Size (frames)" is 30 frames, but I've set it to 200, and it makes no difference.
"Pre Event Image Count" is 25 frames, so at least I get the event that caused it,
"Post Event Image Count" is 5.
"Warmup Frames" are 30.
"Maximum Image Buffer Size (frames)" is zero.
"OutputCodec" is h264,
"Encoder" is libx264 and
"Video Write" is set to "Encode".
(JPEGs are disabled, and optional parameters are "crf=23").

Any ideas what might be happening here?

This looks like the recordings don’t start on an IDR or key frame. Don’t know why. Is there a reason to use encode?

Yea, that was my assumption too.
I had hoped - but maybe I misunderstand its function, in which case it'd be great if someone told me what settings to set - that increasing "Image Buffer Size (frames)" to a large enough value to catch a key frame would solve the issue. However even at 200, there will always be those two seconds of no video.

The reason to use Encode is that I require the privacy mask (for legal reasons). Hikvision cameras have a privacy mask function themselves, but the mask you can draw is rectangular (and you can only draw up to four), so I can't really hide a slanted surface.

What's really interesting is that Zoneminder's privacy mask cannot be seen while the video is grey (it's entirely grey). The privacy mask "blocks in" with the video, as if it's already a part of it. If the grey is coming from Zoneminder because of a missing keyframe, wouldn't the privacy mask be in it as well? Or wouldn't the privacy mask be crisp immediately? With that, it looks (to me, as someone who has no idea what's going on behind the scenes) as if the grey frame is generated after encode. (the slanted surface on the right is the privacy mask - this is a different camera, but the same model)

It's also not a web-thing - if I download the video and play it with, say, Windows Media Player, I see the exact same grey frame I see online. If I play it with VLC, the video is grey, and stays grey throughout.

Probably better to think of it as an absence of data, rather than a grey frame. There are probably some macro blocks and motion vectors after there and it has a try at making it a picture. Then it all snaps in when it has a fresh start on the key frame.

Mhm, though the video frame would be a composite of the source (with the absence of data), and the overlaid privacy mask (data that is present).

When it snaps into place, the privacy mask (which is the composite part ZoneMinder would already know) is just as blurry and blocky as everything else, as if it was already part of the picture. It's almost as if the key frames are missing at playback (but that's a jab in the dark and might/will likely be completely wrong, it's just how it feels).

I wouldn’t say it’s the source.

You need to set at least a crf= in the options. ffmpeg doesn't set sane defaults. Each codec has it's own settings. Read the ? for Encoder Options.

This might sound like a stupid suggestion but sometimes it's easier to take the non-technical approach. In this situation could you put some black tape over the camera to mask the image? You could then change the monitor to passthrough which I think would resolve the issue caused by recording before a keyframe.

iconnor wrote: ↑Wed Jan 26, 2022 10:26 pm You need to set at least a crf= in the options. ffmpeg doesn't set sane defaults. Each codec has it's own settings. Read the ? for Encoder Options.

"crf=23" is already set in the options, is there any other known parameter that needs to be set, in order to fix the grey frames at the start of the event?
I've tried to put "movflags=faststart" in there too (in part hoping that this would also override the other movflags defaults ZoneMinder sets), but it had no visible effect.
I was using ffmpeg version 3.4.8-0ubuntu0.2 until now, but installing ffmpeg version 4.4.1-static and putting it in the path for the optional encoder makes no difference.

bumthunder wrote: ↑Thu Jan 27, 2022 8:33 am This might sound like a stupid suggestion but sometimes it's easier to take the non-technical approach.
In this situation could you put some black tape over the camera to mask the image?

While putting a tape on the camera would no doubt be easier, it's not only a technically very unsatisfying approach, but also legally problematic - in case the tape is removed or falls off on its own.
Plus, I'm not merely reporting this for my sake, I think this might be a more common problem (if I didn't have it on multiple ZoneMinder instances I'd just reinstall), and people might not know what the correct settings are, so they could resort to this thread.

If it were just for me, I'd find some kind of solution or workaround, but since I think it might affect others too, it's probably better if it were fixed, because it'd make ZoneMinder better. If it's a fault in the ffmpeg defaults, then the fix could be as simple as updating the documentation next to the options.

FWIW, this occurs with the libx264 codec. Using any other codec, the issue does not occur, but then ZoneMinder saves JPGs instead, and uses an MJPEG stream to playback the files, which is a huge step backwards from the vjs player/the mp4 files.

How about preset=ultrafast

crf and preset are the only ones I've played with.

For other things to try you will have to read the ffmpeg docs on the h264 codec. Things change if you are using an hwaccel codec as well.

Debug logs may help figure things out because unused flags will be logged.

iconnor wrote: ↑Thu Jan 27, 2022 1:28 pm How about preset=ultrafast

crf and preset are the only ones I've played with.

For other things to try you will have to read the ffmpeg docs on the h264 codec. Things change if you are using an hwaccel codec as well.

Debug logs may help figure things out because unused flags will be logged.

The cue for the debug log helped, even if the debug logs (at least at level 2) didn't have any information about the ffmpeg parameters.
I proceeded to grep the syslog for ffmpeg, and got tons of lines such as
I would have acted had I seen these lines before, but they got drowned in the many other entries in the syslog.
Why the lines had #015 and #012 in them, I don't know. I had never changed the encoder options, other than appending the crf (but leaving the other lines intact), tho I have done that from a Windows PC using Chrome.
After removing all the other lines, leaving only crf=23 (and on one camera, the preset=ultrafast you suggested), the grey frames at the beginning went away immediately.

Apparently the lines with "#" somehow found their way to the ffmpeg codec, and the "crf" at the end was ignored along with them, so it was as if I didn't pass ffmpeg any options.

Maybe this helps some / helps the development of ZoneMinder, because the product as it is is pretty cool

Gives me something to test about. Will see if comments and those other characters can be stripped out.

Definitely room for improvement in terms of communication to the user.

sewi wrote: ↑Thu Jan 27, 2022 2:19 pm

Code: Select all

Jan 27 14:57:18 cctv zmc_m4[6390]: WAR [zmc_m4] [Encoder Option # Lines beginning with # are a comment #015#012# For 
changing quality, use the crf option#015#012# 1 is best, 51 is worst quality#015#012crf not recognized by ffmpeg codec]

Why the lines had #015 and #012 in them, I don't know.

I do. 015 and 012 are octal numbers (Hex, OD 0A) and are "CR/LF" pairs (carriage return line feed)

It looks like the content of a config file has been ingested as an option to FFMPEG, and it's saying
Where the file has ...
as content.

It's the stuff from the text box on the web UI.

Magic919 wrote: ↑Fri Jan 28, 2022 4:34 pm It's the stuff from the text box on the web UI.

Ah, clearly lines beginning with # are being treated as meaningful