x264 and x265 - Difference

[THRobinson]

So, as I understand it, the x265 is the newer 'improved' codec. I looked online to see what the difference was but, was a lot of overly technical stuff for me. I'm just a basic user.

So, I tried it... took an 18GB movie and re-encoded it down to 4000kbps for the video, AC3 5.1 640kbps, high profile, 2-pass, and a few other settings... saved profile I use for pretty much everything. Video comes out usually pretty good, can still see film grain, sometimes I bump up/down the bitrate but in general, I am happy with it. I use VidCoder which is basically Handbrake, but I like the GUI better.

Anyways, ran the encoding for x264 and took maybe 2h. Using the same settings I ran using x265 and took about 8h, and came out to being the same file size...???

I was expecting the compression to be better maybe, or encoding faster, or something... but nope. 4x longer and same size when done.

So... what's the deal with x265 over x264?

[Atak_Snajpera]

If you set the same bitrate no wonder file size was the same

Bitrate determines final file size.
Example

4640 kbps(video + audio) = 580 KB/s = ~566 KiB/s

Now we just have to do simple calucation in order to predict file size.
example for 100 min movie.
100 *60*566= ~3.24 GiB

[SameSelf]

Don't be too hard on x265. It is still under development and hasn't had nearly the run time that x264 has had. Give it time, maybe in a year or two we will see speeds comparable to x264.

Think of it this way. MPEG2/H.262 is to SD video and DVD, the way AVCHD/H.264 is to HD video and Blu-ray, the way HEVC/H.265 is to UHD/4K video. That is not to say you can't encode HD video using mpeg2, but mpeg2 is not nearly as good/efficient as using H.264. Presumably, we will be saying in the near future the same thing regarding 4K encoding using H.265 vs H.264.

But if you are just trying to encode HD content using H.265, then presumably you can do so at much lower bit rates for a similar quality than what H.264 requires.

[THRobinson]

I figured being a new codec, the math would be different or something, like using the same settings as x264, the x265 would be 25% smaller.

Rather, I guess I can get the same results using a smaller bitrate?

Is there a 'general' percentage?

Like... x265 is the same quality as x264 using a bitrate 25% smaller... so x264@4000kbps = x265@3000kbps?

[aedipuss]

it's pretty subjective. your eyes are different than others. try it and see for yourself how much you can lower the bitrate before noticing it looks worse than x264.

[THRobinson]

Be nice to shave off some file size... though kinda sucks. Finally built a new computer, which dropped my 8h encodes down under 2h... but if I switch to x265, I'll be back up to 8h again.

[SameSelf]

The same was said for when AVCHD came out. Took a few years for computers to catch up.

[LigH.de]

No algorithm can measure how annoying a specific loss of quality feels to the person watching the video. And there are so many different people, feeling so different about the same loss. (moviez sharer A: "suuuper quali!!1eleven!" / home archiver B: "gosh, that makes eye cancer!")

There are different metrics an algorithm can measure. PSNR is simple, easy to fool, don't rely on it. SSIM is a bit more elaborate but not foolproof either. Both x264 and x265 encoders can use a quotient from the depths of their algorithms, called "rate factor", which is relatively good, but unfortunately you can't easily compare the RF of x264 with the RF of x265; you can not even compare the rate factors of the same encoder under different constraints. It can only help keeping the degree of quality loss quite constant over the playing time.

In addition, the kind of quality loss in x264 is different to the kind of quality loss in x265; and so we are back to the different people judging them differently, subjectively.

As long as you can't "measure quality exactly and independently of the viewer", you can't decide either if two movies "have the same quality". You can only decide for yourself that you like one better than the other, or you can't decide because they look equally good for you, and possibly only you...

If you can't say that a copy looks worse than the original, then it is "visually transparent" for you. In this case, enjoy it and keep the copy. If not, you may need more bitrate to lose less quality. With x265 you may be satisfied with the result already at less bitrate than with x264. Try it if you have the patience. Or trust in recommendations if you have less patience than free disk space.

[THRobinson]

Well, I'm stingy with the disk space.... so will likely start switching over. The time to encode isn't too bad, I often let it run while at work or sleeping.

That being said, I don't have the patience for Constant Quality... which I know is supposed to be better overall than a fixed bitrate, but, I never know how big the file will be until it's done, and I treat my memory like money. I look at a movie and debate, is it worth 5GB or 3GB of space, then play with the bitrate to match. The CQ takes too long to play with... trial/error to get the right size-range.

Though, next question I guess... how does CQ work size wise? Like, same movie, CQ set to 20... if the x264 file comes out to 5GB... would the x265 come out the same size as well?

[Cornucopia]

No, I don't think you are quite getting it.
CQ/CRF doesn't work size-wise. It works quality-wise. And the numbers aren't linear (16 is not "twice as good", nor twice the size, as 32). Probably not logarithmic either. And as was already pointed out to you, the numbers for HEVC have no (current) relation to the numbers for AVC.
If you are still of the user category that has substantial size constraints, you are better off using 1 or 2pass VBR. Hands down.

Scott

[ValenNC]

NVENC h.265 is faster than x264 and definately x.265 compression if you have a NVENC capable card, you might want to give Hybrid a look. I'm mostly using h.265 for TV Series where I just want HQ, small size and won't need to edit the footage and take x264 1080p content down to 480p. I really can't see the difference on my 80" HDTV and the size is 60% reduced with a QT of 20.

[LigH.de]

GPU encoders usually have a rather low complexity, due to limitations of the hardware, they can only take limited efforts in searching for "redundancies" (= similarities which can be reduced in size by prediction). Therefore GPU encoders may produce convenient results only with a rather genreous bitrate respectively quality-level, while more elaborate CPU encoders like x265 can compress more efficiently and return acceptable quality already with lower bitrates, but will need more time because they need to compare a lot more.

CRF means (more or less) "a constant degree of quality loss" (with "quality loss" in terms of a measurable difference between original video and reconstructed encoded video). You decide how much loss is acceptable (i.e. hardly noticable) to you. But the kind of loss is different between AVC and HEVC. The HEVC algorithms take a lot more efforts in trying to make the loss look less annoying. So you may get a similarly convenient result with x265 already with a bigger rate factor than with x264; you may get a bigger measurable difference to support compression efficiency, yet it may still "look good enough" to you.

[THRobinson]

Man... most of that was beyond me.

Sounds a bit like photography... older digital camera shooting at ISO800 was grainy and speckled... newer processor in a camera can shoot ISO800 but quality is much better. Can have the same lens, MP, settings etc... but image quality is much better.

Have my file encoding at home... x264@4000kbps and x265@3500kbps. Saved about 500mb and when done I'll see how the quality is. But, as mentioned, kinda sucky that if I go with x265, I jump back up to the encode taking 4x the time.

I'm not sure if my card will be NVENC capable... Asus STRIX GeForce GTX960 (DC2OC-2GD5).

I'm just a basic user, with space concerns so, if I can make a file using x265 that's smaller and as good as X264, I'll start using it going forward. I use KODI for my media player/server and the file seems to play fine so, apart from encode time, I don't see many downsides. Just need to play around to get a number that works.

Right now I find that 80% of the time, x264@4000kbps is enough to keep the file around the 4GB mark in size and high enough quality that I can still see film grain without it going all blobby or blurred out. If I can see film grain and motion is smooth, I'm happy. That's my start point/preset... I tweek from there based on the movie. Just need to find my start point for x265 and use it from now on.

Thanks

[ValenNC]

Yes, the GTX960 is a Maxwell card, download Hybrid and give NVENC a try.

I just did a comparison between NVENC and x.265 here. I know it's hard to judge by a single frame but this is a good one with bokehing which tend to generate artifacts and it looks great on both.

x.265 will out compress NVENC, NVENC doesn't even support B-Frames but it does totally make h.265 advantageous to use with even quicker encoding times and smaller file sizes than x.264 and Quality wise you'll have to judge for yourself, my legs are weak and my eyes are old.

[THRobinson]

Hmm... I'll have to give that a try tonight with my test movie.

[sneaker]

it does totally make h.265 advantageous to use with even quicker encoding times and smaller file sizes than x.264

File sizes can be arbitrary controlled through --crf/--bitrate parameters. The only reason your x264 files are bigger is because you chose settings that made them bigger. It is not a meaningful way to compare two encoders. I can make XviD files come out smaller than x265 files, does that make XviD superior to x265?

[LigH.de]

As several people with very founded knowledge (including encoder developers) already stated several times: The only acceptable way to compare different encoders (or different settings of an encoder) is to create two copies with the same size as close as possible, and compare which of them looks worse. And this would still be a subjective result. To make it more objective, a mass ABX test would be required, to collect a statistically meaningful result.

[THRobinson]

Well, I tried Hybrid last night... didn't like it at all... not a user friendly app, especially compared to VidCoder/Handbrake. Followed some YouTube how-to's but even then, way too many tabs and settings to shuffle through.

Ran a few tests... did my usual x264@4000kbps, then ran 3 x265's (3000kbps, 3500kbps, 4000kbps) and for me, looking in the backgrounds at grain and the edges of faces, I think to get the same results as the x264 file, I'll be between 3600-3800kbps with x265.

Sat there last night skipping through video and comparing for a long while and well, not as happy with the results as I thought I would be. I was expecting to be down closer to 3000kbps. So, for me/my test... the amount of space I save per file (200mb) wasn't worth the giant jump in time it takes to produce the file. I was hoping maybe nearer the 600-800mb range.

[LigH.de]

People really believe rather in miracles than in evolution (let's blame the Creationists). Already "50% of x264" is optimistic for x265. But 20% ... not with the same frame dimensions. Maybe downscaled from HD to SD.

[Atak_Snajpera]

@THRobinson

You should understand one important thing. Every movie has different complexity. In one movie you can have many static scenes which are a lot easier to compress than dynamic ones (car chases , explosions and so on). In other words 3000 kbps for "talking heads" will look great but in more complex scenes may not be enough to maintain the same quality. 2-pass mode is also not optimal even if you intend to store movies on HTPC. Example.
Cartoons/Anime are generally much easier to compress than regular movies. A lot of static shots (especially japanese cartoons ). Painted backgrounds do not have many details. Steady camera ...
In this case you are literally wasting space on your HDD. You could achieve the same visual quality with let's say 1000 kbps.
CQ mode is much better choice because:
1) single pass (faster!)
2) encoder automatically adjusts bitrate on-fly according to video complexity and specified CRF value.

You just have to figure out which value is good trade off between quality and size. Start with default CRF value and then go up or down. (lower value = better quality/larger size )

[THRobinson]

I do understand about different complexities, which is why I mentioned that I have a preset I made that generally works, and tweak as needed.

But it's also because of those different complexities, that I don't use CQ Mode, because there's no way to calculate the end file size, and it's a total guess at which number to use as a starting point. I simply don't have the time to reencode the same file 3-5x to get it to a size I'm happy with... especially if using x265 will double or quadruple my time.

Like CORNUCOPIA said... "If you are still of the user category that has substantial size constraints, you are better off using 1 or 2pass VBR. Hands down.".

But... for me anyways, boils down to a point which was mentioned a few times... create some files and compare yourself... which I created 1 using my preset, and 3 of various bitrates using x265... and even having both at the same bitrate of 4000kbps, it was debatable for me if the x265 was any better. Factoring in the jump form 2h to 8h to encode... for now I think I'll stick with x264.

Always the chance of end user error of course... all I did was take my x264 preset, and in the drop down switch to x265.

[PuzZLeR]

You very much sound like the me of yesteryear as I was first feeling out this hobby many years ago, and you bring me back to, not only the old DivX/Xvid vs x264 days, but to even DivX vs MPEG-1/2 days, and all that nit-picking we'd all do with bitrate, quality, speed enhancements, etc. Personally, I'm done with that, and I'm done with burning out processors, motherboards and fans.

You don't have to understand all that tech stuff here, but you can still learn from us here, and our experience.

1) Retain your Source. Whatever you do now will change again and again (and again), and restarts are always better from the Source than from a constantly re-encoded stream. Yes, it's more hard drive space, but it's just something many of us have accepted, and implemented into our lives.

Having said that...

2) Whatever you do now with x265 will not be relevant down the road. Keep in mind, x265, and even HEVC, is a developing science currently. You will want to re-encode everything again when new features are implemented/improved. And again. And again. This is why I still pretty much use x264/DivX/MPEG-2 today for serious stuff, just like I used DivX in the early days of x264 - because the encode times of a mature codec are fast, the settings are stable, the headaches are few, and the output will play anywhere, and its quality/bitrate is competitive (if not better in some cases) with that of a developing next-gen codec in its early development.

If anything changes, fine. I still have the Source (which was #1).

It's perfectly fine to play around with x265 and experiment, but that's the best thing you can do with x265 at the time of this post, and it will contribute to your encoding efforts of the future what you practice today. However, I do not advise a full-scale encoding project with x265 today.

3) Yes, if you could squeeze a bit of bitrate savings out of x265, great. But at what cost? Longer encoding times, re-encodes, endless experimentation, etc, and, again, where will you play the content? Even the current playback/decoding options for x265 are, at best, annoying. Maybe they'll play fine in a few years, but it doesn't matter because you will be re-encoding again in the meantime (see #2).

I know you mention HDD space is like money, but even the word "cost" can include many other things too.

4) Using constant quality is a mindset, and a philosophy, and one that brings on maturity in this hobby. And it's much more efficient, not only timewise, but in quality.

You talk about file size, and you are averse to the unpredictability of constant quality. Well, I guarantee you this - a good constant quality algorithm, such as that in x264, and in DivX/Xvid, will give you the smallest file size possible for a given quality. Traditional 2-pass methods won't - they will virtually always either give you too much bitrate for the quality you want, or too low a quality for the bitrate you want.

And not only does constant quality save you tons of time using only one pass, it will save you tons of time in endless self-bickering. You will hate your life constantly testing, testing, testing and wondering which bitrate is best. I personally just run constant quality once and get what I get and move on.

Two-pass methods are either a thing of the past, or if a "fit-it-on-a-certain-medium" is important, otherwise they are useless. Also, an encoder without constant quality is useless too IMO.

It's your life, and do whatever you see fit, but hopefully we can save you many, many headaches down the road.

EDIT: I was using the expression "Constant Quality" generically here, which could be similarly --crf (x264), CBR (CCE), target quantizer (DivX/Xvid), or CQ with HCenc.

[THRobinson]

Your #2 point... I've already fallen into that habit... I have re-encoded Back to the Future, and Indiana Jones easily 4x now... I learn something, I encode more, and I become more picky.... and each time I grab it and re-encode it again.

Where I disagree is with the comment "constant quality save you tons of time using only one pass" ... which I agree with, IF drive space wasn't a concern. 1-pass is faster than 2-pass, unless you have to re-encode the same thing more than twice to get the size/quality you're after. I wish there was some sorta 'quick scan' that would run through the file and give a rough estimate in size.

I'll revisit the x265 maybe next year... I honestly have no idea how long it's been out. When I saw it mentioned online I thought it was a typo until I Google'd it.

Now that I have a faster computer (replaced my old Core2Quad a month ago) I'll revisit the CQ... when I was using my old system, 8-10h a movie was too much time to spend to have to redo it a few times to get the right size/quality. Using a CBR I'm down to 2h, so, CQ may be even faster. But I do recall when I was researching this stuff a year ago, all the upsides to using CQ... but the random file-size killed it for me. Faster computer... time for a revisit.

Which means, next year at this time... I'll be researching some new way of encoding, and probably end up revisiting x265.

Thanks for the help guys...

[PuzZLeR]

Your #2 point... I've already fallen into that habit... I have re-encoded Back to the Future, and Indiana Jones easily 4x now... I learn something, I encode more, and I become more picky.... and each time I grab it and re-encode it again.

Told ya. And as x265 is developing expect lots and lots more re-encodes with it.

Where I disagree is with the comment "constant quality save you tons of time using only one pass" ... which I agree with, IF drive space wasn't a concern.

You actually save space with CQ in that it's more efficient. And newbies, for some unholy reason, seem to always think it bloats file sizes, when the opposite is true.

Consider this:

If CQ gives you a file size that ended up a bit bigger than you would have liked, at the quality YOU selected, then what that means is that if you used a smaller bitrate with 2-pass then it's guaranteed to look worse than what you wanted. In fact, it may even look terrible. So, was it worth it to save bitrate? Try it and see what I mean.

If a file size ends up smaller with CQ than a bitrate you would have selected with 2-pass, then you have saved bitrate - AND gotten the quality you wanted.

Either way you win with CQ, and it could even save you HDD space in the long run. And if your encodes turn out to be a bit more space consuming, who cares? At least you have guaranteed the quality you wanted. Why save space for crappy video?

(Also consider that you can get 8TB drives as of this posting.)

1-pass is faster than 2-pass, unless you have to re-encode the same thing more than twice to get the size/quality you're after. I wish there was some sorta 'quick scan' that would run through the file and give a rough estimate in size.

Yes indeed, there IS such a method - it's called CQ encoding.

That's the whole point. Why mess around with bitrate testing? Just run it through CQ and there's your answer - the guesswork is completely taken out of it. CQ gave you the quality you wanted, and it gave it to you at the lowest bitrate possible for it, and your encode is ready, and your work is done. Isn't life grand?

I'll revisit the x265 maybe next year... I honestly have no idea how long it's been out. When I saw it mentioned online I thought it was a typo until I Google'd it.

It's exciting to have x265, yes, but at the moment it's simply not ready for prime-time. However, we can all have fun with playing with it in the meantime, and our efforts will only lead to better encodes in the future when x265 is indeed ready.

Now that I have a faster computer (replaced my old Core2Quad a month ago) I'll revisit the CQ... when I was using my old system, 8-10h a movie was too much time to spend to have to redo it a few times to get the right size/quality. Using a CBR I'm down to 2h, so, CQ may be even faster. But I do recall when I was researching this stuff a year ago, all the upsides to using CQ... but the random file-size killed it for me. Faster computer... time for a revisit.

Which means, next year at this time... I'll be researching some new way of encoding, and probably end up revisiting x265.

Thanks for the help guys...

You can visit CQ even now. And who cares about varied bitrates? That's video for you - each clip is different. Sticking with the same bitrate for all video would be like trying to fit every human being into the same clothing size.

And I'd take advantage of the faster processing to do my encodes with x264, or with other mature format, which is ready NOW. Today, with a modern processor, the total encoding time to do all my video (which is LOTS) would take mere weeks with x264, and with the sole one-pass of CQ. It's really that easy. This is a very small amount of time, and frivolous if formats indeed change.

Compare this to the mega amount of time you'd need for x265.

As well, I still have the Source, so I don't lose quality if I have to re-start.

Maybe what you may consider is a change in philosophy here.

EDIT: I was using the expression "Constant Quality" or "CQ" generically here, which could be similarly --crf (x264), CBR (CCE), target quantizer (DivX/Xvid), or CQ (Constant Quantizer) with HCenc.

[_Al_]

Maybe it is difficult for whomever starts to encode to kind of take in that CQ really watches for quality, that could be counter intuitive, because how would some software be able to control quality of video, right, ..., but it does, it compares differences with original so to speak.

[THRobinson]

Damn... long response.

I know CQ saves space, I'm not arguing that one... kinda like VBR for MP3s, more bitrate when needed, less when not, overall a smaller size. Though for MP3's I just run at 320kbps and not worry about it. My only problem with CQ is the unknown outcome. 9/10 times I can run an encode for a movie choosing a bitrate, and comes out how I want and the size I want on the first go. CQ... could be 3GB? 8GB? 14GB?

CQ... my only issue with it is, I can have 2 movies, both exactly 120min long... I can run both with the same settings in CQ, and I'll come out with one movie 3GB in size, and the other 8GB in size... outcome (size wise) is too random for me. If drive space wasn't an issue... I'd run a few tests, and from that I'd probably pick something like 18 for movies I love, 22 for movies that are kinda ok... or something like that.

I'm running a test now with my test file. High budget action film with lots of action, effects, light scenes and dark scenes etc... figured was the best way to test. Encode time ETA seems to be about the same as my 4000kbps preset... about 2h, and my preset uses 2-pass so, maybe 1-pass is faster but on a very low quality setting? like 30? I'm trying at the default 20 and another at 22, x264... see how it looks and what the end size will be.

Again... I agree CQ is better... as mentioned I looked into it last Fall. But... until drive space is no longer an issue, my philosophy is fine. If I only want to spend 4GB worth of space on a movie, I don't want to run the CQ encoding over and over and over again to get the best quality I can get at 4GB.

Yes indeed, there IS such a method - it's called CQ encoding

I'm not following what you mean... if I click CQ (at least in VidCoder) there is no quick scan (by quick I mean under 1min) that then gives me a rough output size. I clicked CQ set to 20, and the "quick scan" is taking 2 hours.

[_Al_]

Yes indeed, there IS such a method - it's called CQ encoding

I'm not following what you mean... if I click CQ (at least in VidCoder) there is no quick scan (by quick I mean under 1min) that then gives me a rough output size. I clicked CQ set to 20, and the "quick scan" is taking 2 hours.

using constant quality in Vidcoder, you set some value, like 18 and then choose just range in frames, or time range, say you are interested in particular minute in a video , so you know where you stand at with the quality and size,...meaning roughly, because as you know CQ distributes bitrate regarding quality. But that minute or 30s or so can give you an idea if you have not done that previously. In time you might guess what you are going to get.

This you cannot do with 2pass, you'd need to encode the whole video to know what you'd get.

[stax76]

I wish there was some sorta 'quick scan' that would run through the file and give a rough estimate in size.

There is a feature called comprehensibility check in Gordian Knot and StaxRip.

Well, I tried Hybrid last night... didn't like it at all... not a user friendly app, especially compared to VidCoder/Handbrake. Followed some YouTube how-to's but even then, way too many tabs and settings to shuffle through.

You can also try StaxRip for GPU encoding.

[ValenNC]

Well, I tried Hybrid last night... didn't like it at all... not a user friendly app, especially compared to VidCoder/Handbrake. Followed some YouTube how-to's but even then, way too many tabs and settings to shuffle through.

Ran a few tests... did my usual x264@4000kbps, then ran 3 x265's (3000kbps, 3500kbps, 4000kbps) and for me, looking in the backgrounds at grain and the edges of faces, I think to get the same results as the x264 file, I'll be between 3600-3800kbps with x265.

Sat there last night skipping through video and comparing for a long while and well, not as happy with the results as I thought I would be. I was expecting to be down closer to 3000kbps. So, for me/my test... the amount of space I save per file (200mb) wasn't worth the giant jump in time it takes to produce the file. I was hoping maybe nearer the 600-800mb range.

LOL, yea Hybrid's is I guess what you would call an enthusiasts encoder for which I've not seen it's equal in terms of shear number of features and tools which on the down side can make it intimidating. The key feature I like is that it provides a GUI for AviSynth giving you access to some really great tools. For your application, that's not really going to be necessary.

I think you did miss something though, from the post it sounds like you picked x.265 as the video handler, what you should have picked to test NVENC is the NVENC video handler and then under the NVENC tab select h.265. Otherwise you weren't using NVENC and were using x.265.

[THRobinson]

Ran some tests with the CQ... for my test movie, CQ25 made a file that was 3.97GB, and using 2-pass with a bitrate of 4000kbps it was 4.01GB, so, pretty close in size.

Quality wise though, the CQ wasn't very good. It may be better in high action scenes? I don't know, but, when its just someone talking, not much movement, the background you can especially see where quality falls apart... instead of small dots of grain, it's distorted blobs and kinda distracting. It almost seems that for CQ to work well, the less complex scenes will have to average at 4000kbps and everything else higher, resulting in a bigger file size.

Anyone have that issue? Creating a file with CQ the same size as CBR file, some scenes are worse?

In the still scenes it's noticeable, but actions scenes it's not... but given all the movement and changes in faster moving scenes, it's harder to tell anyways.

I used the 10min selection for a few other tests, though for guessing final size, it's not any good... taking 3 clips all 10min long each from 3 random spots will give 3 different file sizes... which I understand why... but goes back to my earlier comment, CQ needs some sorta quick-scan to estimate a file size. Based on the tests I'd have to go from CQ25 to CQ22, which based on the test file size would jump me up to about 6GB in size for the file such that still scenes look as good as the 4GB file I made using CBR.

:S