H.265 Uses HALF The Storage Space?

Has anyone realized storage savings of "about 50%"?

Related: Eagle Security Interviewed and H.265 IP Cameras Tested vs H.264

Empire's claim is vague. Perhaps they mean 50% less than their existing products, which could be the case. However, our testing shows that new H.265 cameras vs leading H.264 cameras have no real storage benefit. Worse, Smart H.264 implementations blow H.265 away.

That said, I am sure it is a good sales pitch for Empire.

Has anyone realized storage savings of "about 50%"?


Just got this Hik dome in, wasn't planning on using the h.265 codec, since I don't have a Hik recorder. For under $100 bucks for a 3MP outdoor dome it seemed a decent deal on its own.

Note: In no way should the following "test" be taken for anything but a half-ass feeble attempt to see if there is any possibility of the 50% claim.

So I set the config for highest image quality and h.264, like so:

Then I pointed the camera straight up at my ceiling fan and recorded from the browser client for 5 minutes, then stopped the recording.

The file size was ~257MB. You can view/download the h.264 clip here. It's quite exciting footage.

Then I changed the encoding to H.265, like so:

Recorded again for 5 minutes. The file size was ~127MB. You can view/download the h.265 clip here.

257MB for H.264 and 127MB for H.265

This is just one stupid test, and I claim it means nothing more than whatever you want to take from it. I would do more if anyone is interested, just be specific.

Does this camera support Zipstream? If so, can you try that?

You guys...

Would you mind repeating with h.264+? I'm curious where it would fall in between.

...are a couple of comedians.

I'm very glad you took the time to test what you did. If you don't have a few mins to complete the testing, I completely understand. I wasn't trying to be funny.

I WAS trying to be funny, but I think this was a pretty good test. I wonder what a still frame capture from each would look like?

One thing I would say is that during the capture, the live view for the h.265 was a bit jerkier than the h.264, though it seems to have recorded ok.

I did the test at the highest quality, maybe I will do it at the default quality as well, to see if the h.264 stream is low or not at a more typical level.

Were you able to play the files thru Dropbox? You could grab a still out of that or use Hiks vsplayer software.

I wasn't trying to be funny...

Ok, I believe you, but John knows Zipstream is from Axis, and there don't seem to be any Hik cameras with both 265 AND 264+ yet, so since your response was one minute later, I thought you were joking too. No worries.

If was a man of a sarcastic nature I would have probably responded to John with something like "Will test Zipstream as soon as my $500 ARPTEC-5 add-on board arrives.", but I'd rather take the high road here.

But regardless of how badly h.264+ or ZS would kill h.265, to your first point, there is at least some reason to believe that the advertising claim is not out-and-out fraud. So there's that.

As for the smart codec vs new codec thing, its not a failure that h.265 has less bandwidth reduction than the smart codecs, it's just the where the race is right now. If H.265 had gotten their act together 2 yrs ago like they could have, we'd be more than happy with 50% savings.

Moreover, it's a false dichotomy, the two technologies will complement, not compete, and in a years time, you will see h.265+ beating h.264+ by 50%, IMHO.

Why, because most of the gains in the smart codec are from the use of dynamic GOP, which is a idea easily applicable to h.265 as well. Heck, Geurterbreck was doing it 5+ years ago with MPEG-4.

So, it's good news if we end up can saving 90% with h.265+ compared to h.264, right?

Sean N. says maybe I can upgrade my firmware using tftp, so maybe I can get h.264+ going after all, but as for Zipstream....

I was unaware that you couldn't have h.265 AND h.264+ on the same unit. That all makes sense now. That was an honest mistake on my part.

And the fact you didn't buy a US version to do a side by side with h.264+/ZS was YOUR mistake ;)

Maybe do the same thing but reverse the fan?

You know it's always the same around here, you try to put out some serious, half-assed research, and the first thing people want to do with it is act like its "live at the improv" or something.

I guess it's just payback. :)

A couple things:

(1) My Zipstream comment was dumb (inadvertently funny but dumb). I just realized I said that. As you know, I meant H.264+ but made a mistake.

(2) To reiterate, H.265 is not being sold / supported in NA and I am not sure when it will be.

(3) As with our H.265 Test, we are certainly not accusing the 50% claims as being fraudulent, just not being that meaningful / valuable compared to existing H.264 cameras or, worse, new smart codec H.264 ones.

(1) ...As you know, I meant H.264+ but made a mistake.

Actually, the thought didn't even cross my mind that you made a mistake; take it as a back-handed compliment. I did find it unusually wry for you, but...

(2) ...H.265 is not being sold in N.A.

Do you mean as branded Hikvision only, or even their OEM product?

(3) ...we are certainly not accusing the 50% claims as being fraudulent.

Well, you couldn't be blamed for doing so; the models you tested were only marginally better at h.265 than h.264 on their own settings! This camera appears to be a far better implementation of h.265 than those. Sure, maybe it's h.264 is rigged to make the h.265 look good, but do you really believe that?

(3) ...meaningful...

Again, there are more reasons that people buy a camera than just whether h.264+/zip exists. For those cameras purchased that don't, for whatever reason, it may be very meaningful whether h.265 saves 50% or not, no?

I have tested here in France with Networx and VLC stats utilities comparing H264, H265 and H265 + DgoP/SmartStream, using VBR without limits during tests

Indoor, but also outdoor conditions (more complex more moves) with Taiwanese cameras. (3MP)

H265 saves between 30 (upper moves) to 50% (quite)

H265 + Dgop( 12 - 120 Gop) /SmartStream (30 foreground to 45 % background compression) enables to save 70 to 85% of bandwidth and storage capacity, day and also at night (but you also need to enable DNR, without DNR you are dead in low light conditions with your test)

H265 - as IPVM already mentioned - occured a 20% raise in my PC CPU versus H264

So for upcoming projects I'm telling people to mention H265 in tenders to prepare future VMS migrations. No doubt it's useful especially during 24H/7D - the way to record in most public areas


H265 - as IPVM already mentioned - occured a 20% raise in my PC CPU versus H264

Mine too. Although I think it's worth pointing out that if the channel is not being monitored live and no server side analytics are being used, it's just pure storage/network savings.

Yes. On some VMS even you are not recording neither viewing the CPU is used by daemons running in background... better oversize your server.

What are you saying? H.265 decoding daemons needlessly decoding?

Yes. That's what I've been told by a technical support I had mentionned my high CPU level with H265 whitout true reasons. I'm not a developper so I'm far to explain why it's so

Im a "fan" of the fan test for comparison purposes. Same movement and background for each camera tested. Good thinking. (undisclosed because of the pun)

Very informative, thank you.

If I get a chance I will do some software encoding and decoding tests and maybe some streaming tests with H264 and H265.

I just got the stable H265 codecs so at least can put real numbers against it

Personally, I'm seeing about a 30% savings, but that's with no tweaking applied. Plugged it in, turned it on, 30% savings. I've heard 50% thrown around quite a bit, so it might just be possible with a little effort on my part.

Hal, 30% savings of what compared to what? i.e., what camera model and what settings?

Sounds like he's comparing default h.264 settings ("plugged it in"), vs h.265 at those same settings ("turned it on").

That's what I did, at least. Otherwise, how can you compare?


It's very informative.

I have downloaded both the files (FAN_264 & FAN_265) but when I am trying to play both the files in VLC media player (V 2.2.4), FAN_264 is giving video stream but FAN_265 is not giving video.

Is there any special video player required to play the video which is encoded by H.265?

Can you test and make the network bandwidth consumption comparison for H.264 & H.265?

Is there any special video player required to play the video which is encoded by H.265?

The Dropbox player worked for me, but I also used Hik's vsplayer.

Can you test and make the network bandwidth consumption comparison for H.264 & H.265

I didn't do it explicitly, but I see no reason why the size of the file / number of seconds in the clip can't be used as a relatively accurate estimate, since there was < 1 seconds lag, there was no second stream, and I was monitoring live as it recorded.

Which yields about 6.8 Mbps for the h.264 and 3.4 Mbps for the h.265.

Apparently this 50% number is a good result for Hik as their engineers are maybe not quite seeing that level of savings in the field, so would rather like pump their proprietary h.264+ encoding algorithm and to derogate h.265 at this point to differentiate themselves from Dahua and/or other low cost Asian h.265 providers who may not be shipping a smart codec currently.