New camera, compression artifacts through ZM...

[Tantamount]

Just purchased what I hope will be higher resolution replacement camera.

It is the ReoLink RLC-411 (Running the latest firmware: v2.0.0.1215_16091803).

Specs:
30fps
2560x1440
H.264 - MPEG-4 AVC (part 10)
Planar 4:2:0 YUV
Onvif supported
Optically zoomable

VLC is able to see a perfectly clean stream when viewing this uri:
rtsp://username:password@ipaddress/h264Preview_01_main

Media Info from VLC shows two streams -- one video, the other audio, even though the device doesn't have a microphone.
Statistics shows there are some lost frames - 32000 Decoded, 500 lost (1.5% loss ratio).

Content bitrate is hovering around 8000 kb/s

VLC shows CPU utilization of around 6% in one core of an Intel i7-6700 CPU @ 3.40GHz when viewing the stream.

The camera is current set in "monitor" mode within ZM. When viewing the camera, I am seeing compression artifacts -- certainly enough to trigger motion detection, if I were to turn that on.

I've set all my other cameras modes to "none", and have disabled them for this testing.

ZMC shows an average of 40% CPU utilization for a single core on an Intel i7-6700K CPU @ 4.00GHz

If I attempt to view the camera's feed through ZM, ZMC averages around the same, but sometimes goes as high as 80%, and a new process NPH-ZMS starts and hovers around 40% utilization.

The camera settings:
Server: None
Source Type: Ffmpeg
Function: Monitor
Enabled: Yes
No linked monitors
Analysis FPS: 5.00
Maximum FPS: [blank]
Alarm Maximum FPS: [blank]
Source: (see uri above)
Remote Method: RTP/Unicase
Target colorspace: 24 bit color
Capture Width (pixels): 2560
Capture Height (pixels): 1440

Everything else should be defaults.

Some of the settings of the camera are settable through its web GUI -- I already had audio recording unchecked.
I have the ability to lower frame rate, resolution, and bit rate of the camera, but for obvious reasons would not like to do this since that's the point of getting this camera.

Am I bumping up to the limitations of ZM?

[Tantamount]

Update: I don't get any lost frames in VLC when VM isn't also monitoring the feed. I suspect I was just seeing those lost frames because two devices were attempting to watch the feed simultaneously. Note that the compression artifacts remain when ZM is exclusively monitoring the camera.

[SteveGilvarry]

ffmpeg does not have a non blocking udp buffer so this
Remote Method: RTP/Unicase
can cause artefacts, try RTSP/RTP, it forces TCP and avoids the issues with UDP

[Tantamount]

SteveGilvarry,

I had the camera set up via Onvif. Do you know which is responsible for supplying "RTP/Unicase" (Camera / ZoneMinder)? From what you've stated, it seems like a poor default choice. If the camera is supplying that info, I'd like to email their support about possibly changing this.

[Tantamount]

ffmpeg does not have a non blocking udp buffer so this
Remote Method: RTP/Unicase
can cause artefacts, try RTSP/RTP, it forces TCP and avoids the issues with UDP

I just did this and the problem is gone! Thanks!

[PacoLM]

Also, set Target colorspace to 32 bits, many ZM gurus confirm that this decreases CPU usage (I could confirm it too, but I´m not a guru... )

[SteveGilvarry]

Tantamount,
It is the default in ZM, not all are impacted, more so the higher res cameras as, maybe I will PR a change and see if anyone objects. Ideally I would align them to the actual ffmpeg option. If I knew how to fix it in ffmpeg would be even better, I should check if it is still an open issue with them, last time I checked it their response was anytime someone wanted to write a new buffer go ahead. There is a discussion around, GitHub issue I think, with me and someone else discussing some options in OS to stop it.
Steve

[Tantamount]

Also, set Target colorspace to 32 bits, many ZM gurus confirm that this decreases CPU usage (I could confirm it too, but I´m not a guru... )

I tested this recently and saw no difference. Mind you this was just looking at 'top' output... but maybe when I did the test I had the camera in monitor mode? I'll do some more testing and see if that really does make a difference. Which process should show the difference? zmc or zma? Maybe even playback?

[PacoLM]

Here is the source of the information:
viewtopic.php?f=34&t=24462&p=93518&hili ... nce#p93518
Regards,
PacoLM

[iconnor]

The 32bit colourspace helps motion detection, but I suspect your cpu is spending all of it's time decompressing the h264 and recompressing jpgs.

[Tantamount]

The 32bit colourspace helps motion detection

I followed the links and found the post about SSE2. Has this been verified with today's processors?

I've been researching this and it looks like the alignment requirements of SSE2 are all but gone, starting with the SandyBridge Intel processors (circa 2011):

Most XMM instructions that read or write 16-byte memory operands require that the
operand is aligned by 16. Instructions that accept unaligned 16-byte operands can be quite
inefficient on older processors. However, this restriction is largely relieved with the AVX
instruction set. AVX instructions do not require alignment of memory operands, except for
the explicitly aligned instructions. Processors that support the AVX instruction set generally
handle misaligned memory operands very efficiently.

Source: http://www.agner.org/optimize/optimizing_assembly.pdf (Page 86)

Also, why is there a choice between 24 and 32 bits?

The reason why I ask is how colors are represented-- 8 bits per color, with three primary colors = 24 bits. The 32-bit color space is only 32-bits because of an additional 8 bit transparency layer -- no additional color exists. Maybe the GUI should just have a single 24/32 bit choice that always works in 32 bits internally (Since things don't seem to break when people choose that setting instead of what their camera actually outputs)?

but I suspect your cpu is spending all of it's time decompressing the h264 and recompressing jpgs.

Has anyone tried using GPU hardware decoding for h264 here? It looks like ffmpeg supports it? ( https://trac.ffmpeg.org/wiki/HWAccelIntro ). I'd have to think this would make a huge improvement in speed? Is that what that forked h264 version of ZM is attempting?

I'm going to change the jpg quality setting to 100 and see if that helps CPU utilization at all.