Hikvision H.265+ Tested

IPVMU Certified

Ethan,

Thanks for the report. Great news that you can have 4X the video resolution with the same or perhaps even less bandwidth consumption.

We are presently CPU bound on the workstation client side for decoding the video streams. Would it be possible to add some metrics to your report to measure how much more expensive CPU wise the video decoding is for H.265 vs H.264. I have to believe its probably pretty substantial penalty.

We are waiting for the day when video decoding will be available on the NVidia or AMD graphics cards offloading the host CPU. We have tested the Milestone XProtect Smart Client on the top-off-the-line Intel I7 processor with video decoding hardware acceleration but it still does not have the resources to decode all of the video streams our customers require.

Don

Reactions:

(2)

(3)

Marco Sanchez

Good information. Have you tried Genetec? I have heard they have been doing gpu decoding for a while now and just curious.

Reactions:

(1)

(2)

Ethan Ace

H.265 definitely has an effect on CPU load, but we did not specifically test it here.

You can see details in our H.265 IP Cameras Tested vs H.264 report. Essentially, on small streams, increases in CPU load were fairly small. But when looking at higher bandwidth streams, they definitely spiked.

When you say:

We have tested the Milestone XProtect Smart Client on the top-off-the-line Intel I7 processor with video decoding hardware acceleration but it still does not have the resources to decode all of the video streams our customers require.

What streams do they require that you can't decode?

Reactions:

Ethan Ace

Hey Don, we have added CPU load to the report. H.265 is more than double the load of H.264 at 1080p. And that's without factoring in GPU support. If I turn up hardware acceleration in Exacq (the only VMS we can test these cameras with right now), H.264+ load drops further, with <1% load for the same stream pretty typical.

However, none of the cards we have here support H.265 hardware decoding, and it's unclear if Exacq will take advantage of it if they did. As things become more common and VMS support broadens we will take a look at H.265 hardware decoding support more.

Reactions:

Donald Gordon

IPVMU Certified

In reply to Ethan Ace

Thanks Ethan. I did review your earlier article on H.265 testing and it looks like anywhere from 25% to 60% CPU usage increase over H.264 depending upon the number of streams and stream bandwidth. Doubling the CPU usage definitely will inhibit our ability to take advantage of H.265.

It will be interesting to see how this plays out in the next year or two since the client workstation bottleneck is currently our barrier from upgrading to 4k cameras and H.265 video CODECs.

BTW, this problem also manifests itself on the recording server if it performs video motion detection since it needs to decode the stream to perform the analysis. When I first tested HD cameras with about 2 mbps per stream and 200 cameras per server it swamped the CPU on the recording server when video motion detection (VMD) was enabled. Rather than purchasing an even more expensive recording server or substantially decreasing the number of cameras per server, we have elected to disable the server-side VMD and offload the video motion detection to the cameras. However, I'm not sure the camera VMD is quite as good as the server-side software VMD though I don't have any specific metrics. Have you reported on any camera-side VMD performance vs server-side VMD performance?

Milestone is partnering with NVidia to solve the server-side VMD/decoding issue. Hopefully this solution will transition over to a client-side solution as well for GPU-based video decoding.

Don

Reactions:

Donald Gordon

IPVMU Certified

Ethan,

We have a goal of 75 streams per workstation at 1920x1080 and 30 fps. We can only support about 35 of those streams maxing out the CPU at 80%.

We dual stream the cameras currently to support about 50 cameras live using MJPEG at 640x480 resolution and 10 fps and support 35 cameras during playback using H.264 at 1920x1080 resolution and 10fps. Camera-side video motion detection elevates the frame rate to 30 fps. The switch from 10 fps to 30 fps on motion results in a ~1 second video interruption in the live and recorded streams which is distracting. This is our current workaround for the workstation performance problems.

We would like to return to a single video stream from the camera using 1920x1080 resolution and 30 fps but the workstation just can't decode that much data using the CPU (a Intel Xeon E5 CPU, dual processor, 14 cores each).

Perhaps if we had a high performance GPU supporting video encoding hardware acceleration we could achieve our original streaming goals. As I mentioned earlier, we tried the I7 Processor with the Intel hardware acceleration using the Smart Client and we fell far short of our goal.

Using 4K resolution of course compounds this problem considerably so we will be stuck at 1920x1080 resolution until the client-side hardware and software technology catches up.

Don

Reactions:

(1)

Brian Tally

I'd second the recommendation to check out Genetec. I currently don't have the ability to test what you are describing, but Genetec's GPU decoding is very good in my experience. You may want to ask them for a demo.

Reactions:

Keith Young

Unfortunately until Milestone releases their GPU decoding solution, your best bet is to either severely reduce the frame rate or use MJPEG. We have an i7 beast of a demo machine with dual NVIDIA GTX 1080 founders edition video cards feeding 8 monitors, each displaying 4x 1080p/10fps scenes. I know this is out of the ordinary for the typical install, but we wanted to push Milestone to see where the limits were.

The only way we were actually able to manage CPU levels and keep the PC from locking up was to use MJPEG for live view.

Reactions:

Donald Gordon

IPVMU Certified

In reply to Keith Young

Keith,

We had a similar outcome. We basically use an enterprise class processor in a desk side workstation to display the video streams. We had to use MJPEG with our live streams which really blew our network bandwidth up but did help substantially reduce the CPU overhead of decoding the video streams.

We do use the H.264 CODEC for recording and playback since the number of concurrent video streams during playback are not nearly as demanding as live and disk space usage is more manageable.

Since we dual-stream the cameras with MJPEG and H.264 our network bandwidth is much higher but using a GbE backbone LAN for the camera network we don't seem to have a problem (yet).

Don

Reactions:

Marc Pichaud

Donald

30fps@FullHD is much too much according to me to achieve most security purposes, but if you want it really, checkout that the "High" H264 or H265 profile isn't enable in your cameras. I have experienced on several installations that those profiles were killing video servers (using much more CPU that Main or Basic profiles usually do)

You can also play on the GOP lenght (till you are not willing to capture plates)

Then increase a little bit the compression by avoiding the factory defaut settings in the NVR (Milestone using 30% compression with Axis for example..when you can use 35% without noticing it) Most NVR / and VMS are proposing crazy factory settings ..! Most Integrators let it be... YOu can finally use UDP to decrease broadcast and disable Upnp and Bonjour... to save bandwidth, ah ah ah (nobody does..)

Reactions:

(1)

Donald Gordon

IPVMU Certified

In reply to Marc Pichaud

Marc,

I've seen the H.264 baseline, main, and high profiles settings on cameras before but usually end of using the default setting. I'll give the baseline settings a try and see if it has a measureable impact on CPU usage.

I have not tried setting the quality higher for less compression. That might have a measureable impact on CPU usage as well.

If I find anything dramatic I will post the results.

Don

Reactions:

Ethan Ace

One thing I strongly recommend to people who want to minimize their bandwidth is checking sharpness. It's unbelievable how much of a difference it can make on bandwidth without really changing image quality. It brings out fine patterns like carpet, asphalt, etc., which are harder to encode and increase bitrate.

This image is a few years old now, but the measurements stand, and I see similar patterns on newer cameras. You could lower your bitrates and CPU load by a few percent at least by adjusting sharpness down if it's not necessary.

Reactions:

(1)

Donald Gordon

IPVMU Certified

In reply to Ethan Ace

Wow great advice Ethan. I'll try that as well. I think the Milestone Management client wants a sharpness numeric value. I'll try some different values.

Don

Reactions:

Sandy Gilad