Comparing H.265 (HEVC) and H265 video file size • Hacker News Board

Re: Comparing H.265 (HEVC) and H265 video file size

#41

Post by dylan604 » Thu, Mar 25, 2021, 2:58 AM UTC

mrtnmcc wrote: post #3

This is compressing video recordings of a computer desktop. The frames don't change much so this isn't surprising.

H.264 would be able to take advantage of the same non-changing/static in the hands of a compressionist. Realtime encoding is always subpar compared to that due to the trade-offs required. What this is telling me is that the default settings of the OS screen capture are not optimized. To be expected though, as they have no idea what you may be attempting to encode so a safe setting that is less efficient on static images but performs reasonably well for higher action would be acceptable.

Re: Comparing H.265 (HEVC) and H265 video file size

#42

Post by sidpatil » Thu, Mar 25, 2021, 3:05 AM UTC

jetzzz wrote: post #40

The comparison of H.264 and H.265 in this article doesn't make any sense. Lossy codecs can make files almost arbitrarily small at the expanse of quality. You should look at both quality and size; size alone doesn't mean anything. Also H.264 and H.265 are just formats; there are many encoders of varying quality which can generate such files and each encoder has tons of settings. I don't know which encoder macOS uses b…

> No, DivX refers to MPEG-4 Part 2 which is a completely different codec.

Poster is referring to the DivX Plus HD codec [1].

[1] https://en.m.wikipedia.org/wiki/DivX_Plus_HD

Re: Comparing H.265 (HEVC) and H265 video file size

#43

Post by vermilingua » Thu, Mar 25, 2021, 3:07 AM UTC

I don’t really understand the technical details of compression schemes, but my piece of anecdata is this: in my experience installing/maintaining CCTV systems, using H.265 over H.264 approximately halves the used bandwidth and storage for the same video quality. This is much more pronounced in static/less active scenes, but is still a measurable benefit in highly active scenes.

Re: Comparing H.265 (HEVC) and H265 video file size

#44

Post by spenczar5 » Thu, Mar 25, 2021, 3:07 AM UTC

dylan604 wrote: post #41

mrtnmcc wrote: post #3

This is compressing video recordings of a computer desktop. The frames don't change much so this isn't surprising.

H.264 would be able to take advantage of the same non-changing/static in the hands of a compressionist. Realtime encoding is always subpar compared to that due to the trade-offs required. What this is telling me is that the default settings of the OS screen capture are not optimized. To be expected though, as they have no idea what you may be attempting to encode so a safe setting that is less efficient on static ima…

Also, screen capture software usually needs to minimize CPU usage so you can actually, yknow, do the stuff you are trying to record. The blog post mentions that the transcode caused his laptop to heat way up. It was almost certainly a way different encoder profile.

Re: Comparing H.265 (HEVC) and H265 video file size

#45

Post by mohankumar246 » Thu, Mar 25, 2021, 3:09 AM UTC

Compression depends on a variety of factors - content, type of frames being used (I-P, I-3/7B-P, etc.). Bit rate vs Distortion curve also has to be considered. PSNR of encoded content is a metric. Click bait without much info.

Re: Comparing H.265 (HEVC) and H265 video file size

#46

Post by iaw » Thu, Mar 25, 2021, 3:09 AM UTC

vermilingua wrote: post #43

I don’t really understand the technical details of compression schemes, but my piece of anecdata is this: in my experience installing/maintaining CCTV systems, using H.265 over H.264 approximately halves the used bandwidth and storage for the same video quality. This is much more pronounced in static/less active scenes, but is still a measurable benefit in highly active scenes.

Assuming you meant H.265 over H.264 but could someone confirm?

Re: Comparing H.265 (HEVC) and H265 video file size

#47

Post by scottmcdot » Thu, Mar 25, 2021, 3:11 AM UTC

eikenberry wrote: post #5

The main hurdle for adoption, aside from onerous patents, is waiting for hardware acceleration to be common place. What is the current state of h.265 hardware accel? Does it come with everything yet like h.264 does?

How would you if your hardware can or cannot decode h.265? Would it simply not play or might play but stutter, or play in some compromised way?

Re: Comparing H.265 (HEVC) and H265 video file size

#48

Post by [deleted] » Thu, Mar 25, 2021, 3:12 AM UTC

oplav wrote: post #24

eikenberry wrote: post #5

The main hurdle for adoption, aside from onerous patents, is waiting for hardware acceleration to be common place. What is the current state of h.265 hardware accel? Does it come with everything yet like h.264 does?

Most Turing and above Nvidia cards have support for hardware accelerated decode of h.265 [0]. Modern Intel chips also support hardware accelerated decode (support started with Skylake [1]). Not sure about AMD. [0] https://developer.nvidia.com/video-encode-and-decode-gpu-sup... [1] https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video#Hardwar...

[deleted]

Re: Comparing H.265 (HEVC) and H265 video file size

#49

Post by dylan604 » Thu, Mar 25, 2021, 3:13 AM UTC

stevenhuang wrote: post #31

boomboomsubban wrote: post #8

Earlier quoted context omitted.

Can you clarify this please? Does h.265 have some better deduplication compression or does reencoding apply something that the original recording could not, meaning h.264 would have the same benefit.

The original h264 file was likely optimized for write speed and not storage (which takes cpu time and can introduce lag in real time recording). Reencoding the same input file as h264 again but using FFmpeg defaults would probably yield similar file size reductions. This is just a bogus post without knowing what parameters were used to encode the original h264.

For science, I just took a 10 second screen recording of my Mac with nothing but my tiny mouse cursor moving around for a few seconds which means a very static shot. The recording came out at 7.5MB. There was no audio in the original recoding.

I then used that as a source to transcode with x264 crf 23. New filesize 2.0M. ~26%

ffmpeg -i input.mov -c:v libx264 -crf 23 x264.mp4

Next, I used the same 7.5MB source to transcode with x265 crf 28. New filesize 968KB. ~13%

ffmpeg -i input.mov -c:v libx265 -crf 28 x265.mp4

CRF values were taken from [0] which states x265 crf28 should produce same visual quality of x264 crf23, but at half the size. That holds true.

[0]https://trac.ffmpeg.org/wiki/Encode/H.265

Edit: forgot link

So, I don't think the author's post is bogus. They just lose points for not showing their work (not that they did it, but you know).

Edit 2: I have no idea what the author of the post used for encode settings. I picked 2 based on the vendor's claim the 2 settings should look the same at half the bit rate. I easily could have changed the values to lower the bitrate to get from 50% to 94%. I just assumed the reader would be able to make the mental leap

Re: Comparing H.265 (HEVC) and H265 video file size

#50

Post by dylan604 » Thu, Mar 25, 2021, 3:19 AM UTC

bawolff wrote: post #22

boomboomsubban wrote: post #8

Earlier quoted context omitted.

Can you clarify this please? Does h.265 have some better deduplication compression or does reencoding apply something that the original recording could not, meaning h.264 would have the same benefit.

If you re-encoded to h.264 with ffmpeg it would also probably get smaller. Video codecs have lots of options and trade-offs. Its not just quality and file size, but also cpu usage. I suspect the original was encoded in minimize cpu usage while keeping quality constant, and the new one was minimize file size while keeping quality constant and use as much cpu as you want.

challenge accepted. see reply to sibling comment