Pausing a frame on the Montage page does not reduce the server load.

[IgorA100]

Describe Your Environment
ZoneMinder 1.37.58

PLAY on Montage page

PAUSE on Montage page

Console Page (Everything is fine)

[connortechnology]

Your images show that the stream has stopped, which is good. Your top output shows that the bulk of your cpu is taken up by zmc. This is likely the case even if you aren't watching at all. Stopping the streams isn't really about saving cpu... zms jpeg encoding can take a fair amount, but generally is way less than zmc.

[IgorA100]

1 screenshot - stream has stopped
2 screenshot - stream has run
In both screenshots, the load on zmc does not change.

3. screenshot as an example of what the zmc load should be if stream has stopped

[connortechnology]

Nor should it. zmc is the capture/decode process. Nothing to do with streaming.

[connortechnology]

Wait, are you using decode=ondemand? Thing is zms is still running, so potentially still "viewing" As discussed in forums, we may need to use CMD_QUIT instead of CMD_STOP.

[IgorA100]

Wait, are you using decode=ondemand?

Yes, sorry I forgot to mention this.

Thing is zms is still running, so potentially still "viewing"

I understand. The WEB_L_VIEWING_TIMEOUT setting only affects bandwidth.

CMD_QUIT - for some reason stops the broadcast and immediately starts it again.

P.s. WEB_L_VIDEO_MAXFPS - also does NOT affect the server load? I didn't notice any impact.

P.s.2 I’m looking for a solution so that on the Montage page it would be possible to display streams from 20-30 5-8Mp cameras with a resolution of, for example, 240x135px or 10-15 cameras with a resolution of 480x270px with low FPS (1-5)

[IgorA100]

Very strange, but ZMC loading does not depend on "scale" and does not depend on "fps". After all, the lower the output resolution, the less work the processor has to do.

[connortechnology]

I know that try to view a 4k stream puts serious load on zms. I think you aren't looking close enough.

[IgorA100]

I know that try to view a 4k stream puts serious load on zms

There are no problems with zms.
Live stream (Watch page) from a 4k camera, output resolution 960*540px, zmc(80%)+zms(11)=91% load.

View the same camera on the Montage page, output resolution 268*151px. Load zmc = 75%
Should the zmc load really be that high?

[connortechnology]

Yes. You are decoding h264 or h265 to a 4k yuv420p image. Then converting that to rgba, Then copying that to /dev/shm/zmc.mmap (That all happens in zmc.) That yuv420 to rgba is really bad. We are working to get rid of it. However you are still doing a ton of work to do the decoding.
In zms we are encoding the 4k rgba image in /dev/shm/zmc.mmap to a scale jpeg. jpeg encoding is actually still very cpu instensive, so it really benefits from scaling down first.

If you want this all to not happen, then you need to look into using rtsp2web or janus to do the viewing.

[IgorA100]

Ok.

1. But there should be a difference in CPU load when decoding 20FPS and 2FPS?
2. When analyzing motion, are frames decoded or not?
3. If "Decoding = Keyframes + Ondemand" is enabled, then the Keyframes are already decoded? So if you display it, the zmc download will not change?

I know about Janus, but it has problems with broadcast stability

In zms we are encoding the 4k

Why 4k? if you need to display 268151px, then you need to decode from 4k to 268151px, and then encode 268*151px, and not 4K. Or am I wrong?
I haven't studied ffmpeg.
I'm just speculating and I could be wrong.

[IgorA100]

I tried to decode video like this:
ffmpeg -i 1.mp4 -c:v rawvideo -pix_fmt yuv420p out6.yuv
and so:
ffmpeg -i 1.mp4 -c:v rawvideo -pix_fmt yuv420p -s 1920x1080 out6.yuv
In the second case, decoding finished much faster.

This is even faster:
ffmpeg -i 1.mp4 -c:v rawvideo -pix_fmt yuv420p -s 1920x1080 -r 5 out1.yuv

To display video on the screen, I think 1920x1080 and FPS=5 will be enough. At the same time, the decoding speed from 4K should increase several times.

[connortechnology]

We do not support altering the frame rate of decoding, except for only doing keyframes. Our experiments in the past have shown it to not work, but maybe we were doing something wrong.
Yes, encoding to 1080p takes less cpu than to 4k. This we do. However the cpu use will not show up as zmc, it will show up as zms.

[IgorA100]

Yes, encoding to 1080p takes less cpu than to 4k. This we do.

You are decoding h264 or h265 to a 4k yuv420p image.

Stream from camera h264 4k is decoded to 4k or 1080p yuv420p?
Judging by the fact that the CPU load when decoding 4k is very different from decoding 2k, then h264 4k is decoded into 4k yuv420p. For Montage page 1080p is enough

[connortechnology]

Depends on what you have for size on the Source tab. It's not actually the decoding that takes so much cpu, it's the translation to rgba and copying around in memory, so reducing to 1080p saves a lot.

[IgorA100]

Depends on what you have for size on the Source tab

Got it. I'll experiment with this setting

[IgorA100]

Depends on what you have for size on the Source tab

This only affects ZMS loading, but ZMC is still heavily loaded.
Those. h264 stream from a 4k camera is still decoded into 4k yuv420p image and stored in memory as 4k, not 1080p?

[IgorA100]

@connortechnology
Sorry that I’m probably asking something stupid, but nevertheless, h264 stream from a 4k camera is still decoded into 4k yuv420p image and stored in memory as 4k, and does not depend on the “Capture Resolution” of the monitor specified in the Source?
In fact, 4k cameras consume a lot of resources, although a lower resolution is enough to display on a monitor.

[connortechnology]

Yes, gets decoded to 4k res yuv420p. I'm not aware of a way to tell ffmpeg to do anything different. But then we convert that image to rgba, for which we use the capture resolution.

[IgorA100]

Yes, gets decoded to 4k res yuv420p. I'm not aware of a way to tell ffmpeg to do anything different.

Where is this code located?
Maybe I'll look and a thought will come into my head...

[connortechnology]

I don't think there is anything that can be done about that. Other than not decode it at all, which is what we are looking to do with webrtc/websockets and h265web.js. Where we can do better is to not transcode it to RGBA which takes up 4x the space and takes more cpu than decoding. @webgeek1234 and I are working on it.

[IgorA100]

Ok, I got it.

[connortechnology]

The decoder setup is in zm_ffmpeg_camera.cpp. The actual calls that do the decoding and transcoding are in zm_monit.cpp in ::Decode. The actual heavy lifting is done in zm_image.cpp.