h.265 vs h.264 discussion

[dalekphalm]

I am going to actually take a crack at some h265 Encoding my Blu-Ray Library. What were you using to transcode?

I use MakeMKV to rip the Blu-Ray itself, plus whatever language tracks I want.

 

I then use Handbrake to do the actual encoding. I currently encode in an MKV container (I just like them better then MP4 containers), and I use H.264 with CQ 18 as the base for my settings.

 

I'd like to check out H.265, but I'd really like to wait until my devices have hardware encoding/decoding support. But if I get a beefier HTPC, then that won't really matter too much.

[Elfuego]

I use MakeMKV to rip the Blu-Ray itself, plus whatever language tracks I want.

 

I then use Handbrake to do the actual encoding. I currently encode in an MKV container (I just like them better then MP4 containers), and I use H.264 with CQ 18 as the base for my settings.

 

I'd like to check out H.265, but I'd really like to wait until my devices have hardware encoding/decoding support. But if I get a beefier HTPC, then that won't really matter too much.

 

Ill have a crack when I get a bit of free time just to test it out. Though I highly doubt ill be re-ripping my entire collectionAt 10gb 1080p Videos are pretty damn close to perfect. I could probably get them smaller but the effort wasnt worth it to me with how cheap storage actually is.

 

Not to mention its somewhat outside the parameters of H265 currently.

[Guest]

WebM is just a container

WebM Container + VP9 Codec + Vorbis Audio Codec.

[Robin88]

To be fair, you're compressing an already heavily compressed video file that is already h.264.

 

As @ aerandir92 says, try the same tests with an uncompressed Blu-Ray rip, via MakeMKV. It would be a more realistic result, since you're starting with a proper source. The results might end up being 100% identical to what you've already done, but they would be more useful data points.

 

 

I would start to rip my Blu-Rays using h.265, but my HTPC is using an ancient Core2Duo with integrated graphics, so it likely wouldn't handle h.265 very well. One of these days I'll get around to upgrading it...

I reran the tests with a "uncompressed" DVD rip (uncompressed is a misnomer tbh, all DVD and Blu-Ray video is compressed) and there's some noticeable differences in files sizes at the same settings as before, but bear in mind this is a different file, so the results cannot be compared to before.

The source video was a exact copy of a episode from a store bought DVD of Through the Wormhole sitting at 2.18GB, and from that I took a 2 minute sample and ran the exact same section through H264 and H265 at 3 compression levels (CQ20, CQ30 and CQ45 using the medium preset for all 6 versions)

The original video is an MPEG2 video at 720x576i at 23.97FPS

The file sizes are;

H264 Medium CQ20 = 26.5MB

H265 Medium CQ20 = 17.5MB

 

H265 scores a major win here, identical image quality but with a much smaller file size, it must be pointed out that CQ20 is imo not great, and I would say it'd be better to go with CQ18 for DVD rips, CQ20 is passable for image quality but sharp eyed people will notice artifacts very easily at any distance from the screen, so I don't particularly consider any of these images to be usable.

H264 Medium CQ30 = 6.60MB

H265 Medium CQ30 = 5.25MB

 

H264 is a bigger file, but the image quality for H265 is slightly worse, making this one imo a draw and what you should use really depends on your needs.

 

H264 Medium CQ45 = 3.14MB

H265 Medium CQ45 = 2.85MB

 

H264 wins outright here, the file size difference is negligible but the image quality is far superior in H264's case, even if it's still awful and completely unwatchable.

Thanks for pointing that detail out, I wasn't really expecting much of a difference, but as it turns out there is one, even though it still isn't enough to make me change to H265.

But there is still the Elephant in the room we haven't discussed yet, and that is time, H264 loses in 1 of 3 tests here, and draws in another, but the time to convert from MPEG2 to H264 is about 1 third as long as it is for MPEG2 to H265, and the space savings aren't worth that extra time, storage is cheap, but time isn't and while transcoding 1 film isn't too bad and the time difference wouldn't really matter, once you consider the time difference for transcoding 100+ films or more, that time saving really adds up and in when you consider that aspect, H264 currently wins outright and will do for the foreseeable future.

[.spider.]

h.264 xCQ ≠ h.265 xCQ  :rolleyes:

[dalekphalm]

h.264 xCQ ≠ h.265 xCQ  :rolleyes:

Can you add additional detail to your post. You come off as a "know-it-all" by making a "snarky" statement (The rolls eyes emoticon gives that impression) but provide no explanation or source.

 

In theory, the entire point of the CQ = Constant Quality. A CQ of 20 should be a "relative quality level of 20".

 

You may vary well be correct, but why don't you actually explain why you think so?

[.spider.]

In theory, the entire point of the CQ = Constant Quality. A CQ of 20 should be a "relative quality level of 20".

 

That's not how CQ works (to be correct it's actually called constant rate factor, because it doesn't offer true constant quality) in h264 and h265.

"Even the CRF mode doesn't deliver “perfect” constant quality! A specific CRF value will only deliver similar quality for various sources, as long as you don't change any other settings. Using “slower” settings with the same CRF value will either produce a smaller file at same quality or a produce a file of the same size at a better quality. It's also possible that both, the size and the quality, will be increased. The “quality per size” ratio will be improved anyway." http://www.avidemux.org/admWiki/doku.php?id=tutorial:h.264

That's only for different h264 settings, after reading this http://forum.doom9.org/showthread.php?t=168814 you'll know that the crfs of h264 and h265 aren't compatible.

[bobhays]

You didn't compare the same file twice, so your comparison is void, if you're gonna test variation between two codecs, you ought to do it with the same sample file, but that's not quite the point.

h265 is harder to decode and encode now because most hardware doesn't natively support it, most decoders in GPUs only support h264 and other older codecs so of course it used more CPU time during playback, and h265 is only in the same situation that h264 was in just a few years ago.

h264 used to take forever compared to mpeg4, but now with hardware and software support h264 is nearly as fast as mpeg4, and the same is true of h265, it'll take longer now but once the support is in place it should be just as fast if not faster than h264.

I'll get handbrake installed and run some encode tests and see what the numbers give, also remember that the advantage of h265 is not really speed, it's compression and the resulting file sizes, h265 allows for a file about half the size of h264 for the same quality, and that's the important part, which if you only compare similar settings for h264 vs. h265, h264 wins nearly every time, but start compressing h264 more and more and watch as the quality tanks, whereas h265 holds the same quality but at greater compression ratios.

 -snip-

If you read the first line of the post it says I used the same video file....

 

I even set the CQ to 20. Someone mentioned its not exactly the same but its the only way I knew to keep a relatively similar quality.

 

It seems clear that h.265 works better when doing even higher compression levels but at a CQ of 20 the smaller size is not worth the extra encoding power.

[anticeon]

you cant compared the x264 vs x265 that way ... the real encoding use terminal using handbrake CL and using pure CPU power. x265 will have 65% size of x264

[.spider.]

the real encoding use terminal using handbrake CL and using pure CPU power. x265 will have 65% size of x264

What?

[MG2R]

@alpenwasser has quite a bit of experience with this by now

[alpenwasser]

@alpenwasser has quite a bit of experience with this by now

Well, I have experience with transcoding h265/XviD/DivX/WMV9 etc. videos into

HEVC with the x265 implementation. Haven't done any BluRays yet though.

I don't have any examples for comparison because I've deleted my source files

by now, but my experience has been roughly this (also, I'm still learning the

ins and outs and quirks of HEVC as well, so my lessons learned might change

and/or be amended):

• For lower-quality content, filesizes won't be reduced that significantly,

  at least not for identical quality.

• For higher-quality content, I have found that I can achieve a reduction in

  filesize of between about a third and two thirds, with the source and the transcode

  being only distinguishable when overlaying still shots and switching between them

  quickly while watching out for changing pixel areas (so, while you're watching,

  quality is identical for practical purposes). It will depend quite a bit on the

  video, but I haven't yet quite figured the rules of what to expect when here.

This is just my recent experience with part of my personal video library, not a

scientific test. But personally, I will probably be transcoding quite a bit of my

library to HEVC in the near future, except the stuff which I really don't want to

touch and want to keep in as high a quality as possible. x265 might not be as mature

as x264 (or other implementation of that codec) yet, and depending on what kind of

video you're trying to compress it might not be as good yet, but for the videos

I've tried and compared, it's been working very well.

Also, a general note for those complaining about the slowness of their h.265

implementation: This is not merely due to implementations not being very mature

yet (such as x265), although that does play a part I'm sure. One of the basic

ideas behind HEVC is to improve the quality/filesize ratio at the expense of

computational effort. So while I'm confident we'll see much faster HEVC implementations,

they're not likely to ever be as fast as AVC implementations such as x264.

Lastly:

To be fair, you're compressing an already heavily compressed video file that is already h.264.

 

As @ aerandir92 says, try the same tests with an uncompressed Blu-Ray rip, via MakeMKV. It would be a more realistic result, since you're starting with a proper source. The results might end up being 100% identical to what you've already done, but they would be more useful data points.

I'm sure you know this, and I get the point you're making, but I just thought I'd point

this out for those who are not aware: Blu-Ray video is not uncompressed, it's just not as

heavily compressed as a rip. Just thought I'd add that for clarification so that those

who don't know don't get confused.

[dalekphalm]

Well, I have experience with transcoding h265/XviD/DivX/WMV9 etc. videos into

HEVC with the x265 implementation. Haven't done any BluRays yet though.

I don't have any examples for comparison because I've deleted my source files

by now, but my experience has been roughly this (also, I'm still learning the

ins and outs and quirks of HEVC as well, so my lessons learned might change

and/or be amended):

• For lower-quality content, filesizes won't be reduced that significantly,

  at least not for identical quality.

• For higher-quality content, I have found that I can achieve a reduction in

  filesize of between about a third and two thirds, with the source and the transcode

  being only distinguishable when overlaying still shots and switching between them

  quickly while watching out for changing pixel areas (so, while you're watching,

  quality is identical for practical purposes). It will depend quite a bit on the

  video, but I haven't yet quite figured the rules of what to expect when here.

This is just my recent experience with part of my personal video library, not a

scientific test. But personally, I will probably be transcoding quite a bit of my

library to HEVC in the near future, except the stuff which I really don't want to

touch and want to keep in as high a quality as possible. x265 might not be as mature

as x264 (or other implementation of that codec) yet, and depending on what kind of

video you're trying to compress it might not be as good yet, but for the videos

I've tried and compared, it's been working very well.

Also, a general note for those complaining about the slowness of their h.265

implementation: This is not merely due to implementations not being very mature

yet (such as x265), although that does play a part I'm sure. One of the basic

ideas behind HEVC is to improve the quality/filesize ratio at the expense of

computational effort. So while I'm confident we'll see much faster HEVC implementations,

they're not likely to ever be as fast as AVC implementations such as x264.

Lastly:

I'm sure you know this, and I get the point you're making, but I just thought I'd point

this out for those who are not aware: Blu-Ray video is not uncompressed, it's just not as

heavily compressed as a rip. Just thought I'd add that for clarification so that those

who don't know don't get confused.

 

Yes of course, even Blu-Ray is compressed. But from a "consumer" standpoint, Blu-Ray is as close to "uncompressed" as we get.  Though you are correct to clarify that for users who might not understand the difference.