x265 HEVC Encoder

[Boulder]

This question is probably too vague to give a good answer to, but here goes: what features of x264 are still missing or are not at least as good in x265? I'd like to start testing the codec at some point for my OpenELEC media needs but I don't know which things I need to follow more closely before taking the first step.

[jlpsvk]

@Boulder....

I have ended up with OpenELEC 5.0 / KODI 14 with software decoding of HEVC (for now, until GPU with HW HEVC decode will rise up) and using 10-bit x265 1.4.244. At CRF20 it has half the size and for me better quality than x264 at CRF20. :)

[Boulder]

The same/similar settings? I was just reading about the banding issues you reported and thought that there is something to do there in x265. What about encoding performance, how much does the time increase with x265 on your rig at this point compared to x264?

[jlpsvk]

These are my actual encode settings in MeGUI (I replaced EXE and DLL in it with the 10bit recent version):

--preset medium --crf 20.0 --frame-threads 3 --no-open-gop --psy-rd 1.0 --aq-mode 1 --aq-strength 1.0 --psy-rdoq 1.0 --keyint 240 --min-keyint 23
--pmode --range full --weightp --weightb --deblock -3:-3 --rd 4 --me 2 --pme --vbv-maxrate 0 --vbv-bufsize 0

So these are very similar to x264 i think. 10bit x265 has NO BANDING issues and I am totally satisfied with that. :)

[lotusgg]

I'm having trouble with color banding with this cli
avs4x265.exe --preset veryslow --crf 16 --tune grain --pmode --pme 00000.avs episode1.hevc
The source is anime blu-ray stream and it's bitrate is 48mbit.
How can I fix the banding and mantain the moving digital grain(just like TV noise pattern) without doubling the size?

Edit:
Forget it, it's actually on the source and I was just refusing to belive.

[Boulder]

What about encoding performance, how much does the time increase with x265 on your rig at this point compared to x264?

Out of interest, I compiled an x265 (64bit, high bit-depth) executable and compared one script I've used (1000 frames, resolution 1280x528). x264 processed about 5.6 fps while x265 managed 1.3 fps. There's room for improvement but it was not as slow as I feared. Switching from preset veryslow to slower speeded things up quite a lot over that 1.30 fps.

I run a decent i5-4670K @ 3.9GHz so it's not the fastest chip there is, there's also a motion-compensated denoising script to slow things down.

[jlpsvk]

Check my x265 settings. :) Raising preset with CRF mode gives only smaller size... (not too much smaller)...with those encode params I am getting about 7-10 fps encode with x265.

[Boulder]

Check my x265 settings. :) Raising preset with CRF mode gives only smaller size... (not too much smaller)...with those encode params I am getting about 7-10 fps encode with x265.Has anyone performed any subjective tests regarding this matter? That is, for the same CRF, do presets in the range slow-slower-veryslow just create an increasingly smaller file with approximately the same quality level?

[oopsipoo]

Regarding banding, could it be a decoder issue?

i have come across an issue where i recoded a 2.5 hour movie with quality 18 (on the scale, i dont know what its called) and default speed. The problem is seek, if i was to jump to anywhere after say 1hour into the movie, ram useage spikes and MPC freezes. this has happened with some other HD videos, but not (as yet) with sd video of long duration.

Just thought i might let you guys know

[lotusgg]

testing on small samples may be better.
Raising CRF and AQ is basic when it comes to "balancing where the bits should be" for better efficiency and visual quality.
Also, psy-rd may hurt color gradients and detail on dark scenes, so I mostly let it at 0 or at a very low value.

[dev0]

I have a question about encode times. I am encoding with x265 for some time now. When doing bluray sources with very slow preset and ~16-17 CRF or 2-pass 8000-10000 kbps, encode speed is around 12-25 times slower than x264. How much this will change before releasing the final version ? Because 4 hour encode vs 100 hours encode is a really big difference.

[Atak_Snajpera]

@dev0
What you do does not make sense. At 8-10mbps even x264 shines. You do not need x265 with insanly slow preset for this task. My advice. Use CQ mode with some reasonable high value (22-24) instead of 2pass. Use default preset.
BTW
So called final realase won't give you big difference in speed.

[jlpsvk]

That encode time at VERY SLOW is normal.

Try this command and you could change the ratefactor.

--preset medium --crf 20.0 --frame-threads 3 --no-open-gop --psy-rd 1.0 --aq-mode 1 --aq-strength 1.0 --psy-rdoq 1.0 --keyint 240 --min-keyint 23
--pmode --range full --weightp --weightb --deblock -3:-3 --rd 4 --me 2 --pme --vbv-maxrate 0 --vbv-bufsize 0

[dev0]

That encode time at VERY SLOW is normal.

Try this command and you could change the ratefactor.

--preset medium --crf 20.0 --frame-threads 3 --no-open-gop --psy-rd 1.0 --aq-mode 1 --aq-strength 1.0 --psy-rdoq 1.0 --keyint 240 --min-keyint 23
--pmode --range full --weightp --weightb --deblock -3:-3 --rd 4 --me 2 --pme --vbv-maxrate 0 --vbv-bufsize 0

Thanks but this is not acceptable by my eye and is not the quality of output i need.


@dev0
What you do does not make sense. At 8-10mbps even x264 shines. You do not need x265 with insanly slow preset for this task. My advice. Use CQ mode with some reasonable high value (22-24) instead of 2pass. Use default preset.
BTW
So called final realase won't give you big difference in speed.

Thank for your opinion, but i disagree and for me it makes sense. My eye can see difference between 8000 kbps and 16000 kbps encode. Maybe average Joe doesn't see any difference, but i do and people that watch my encodes do too. I didn't ask if it has sense for you. I asked if encode times at that preset will be the same in future or not.
I watched and analysed thousands of x264 encodes, i've encoded hundreds. If you can't see a difference between CRF 22-24 vs CRF 16 then you have a problem with your eyes.

[Atak_Snajpera]

@dev
You did not understand. At high bitrates like yours difference in quality between x264 and x265 is marginal. I do not understand why you use x265 at all! x265 only shines at 4k and very low bitrates. h.265/HEVC standard in general was designed for such high resolutions ( hence default CU=64 ).

Because 4 hour encode vs 100 hours encode is a really big difference.
In this case you are only wasting time, energy and money.

[x265_Project]

That encode time at VERY SLOW is normal.

Try this command and you could change the ratefactor.

--preset medium --crf 20.0 --frame-threads 3 --no-open-gop --psy-rd 1.0 --aq-mode 1 --aq-strength 1.0 --psy-rdoq 1.0 --keyint 240 --min-keyint 23
--pmode --range full --weightp --weightb --deblock -3:-3 --rd 4 --me 2 --pme --vbv-maxrate 0 --vbv-bufsize 0
jlpsvk - I wouldn't recommend turning on --pme. At this point, it will probably slow things down. I also don't recommend --psy-rd at full 1.0 strength, but this is a matter of personal taste, and with a higher bit rate it shouldn't cause problems. I wouldn't manually set --frame-threads. On your machine it would probably end up at 3 anyhow, but on many-core servers this setting could restrict performance unnecessarily.

Tom

[foxyshadis]

Unless there's a reason you absolutely have to use HEVC, it would be more useful in this scenario as a nearly-as-good, half-the-size variant. If that isn't useful to you, stick with what's already working well.

Also remember that the slower you go, the less benefits you get. Going from slow to very slow, maybe it's worth the extra hours to save, say, 50 kbps when you're encoding to 500 kbps, but would it ever be worth saving 50 kbps at 16000? It doesn't work exactly like that, but the general principle holds.

[jlpsvk]

@x265_Project
Why not psy-rd 1.0? I am using CRF, and psy-rd and psy-rdoq should be for fine detail retention...or?

[x265_Project]

@x265_Project
Why not psy-rd 1.0? I am using CRF, and psy-rd and psy-rdoq should be for fine detail retention...or?

Personally, I find that lower values of psy-rd (0.2 or 0.3) give the best result at lower bit rates. At more generous bit rates you can use higher values. Psy-rdoq 1.0 should be fine. Feel free to run a couple of experiments to understand the effect of psy-rd and psy-rdoq and what values give you the most optimal result.

Tom

[jlpsvk]

@x265_Project
I am using it for BD backup, now using CRF 20. Is it possible to compare CRF value to x264? i.e. x265 CRF20 = x264 CRF18 or so? :) Not in matter of size and bitrate, but in matter of visual quality. CRF 18 in x264 is considered as almost transparent.

[benwaggoner]

They are ballpark similar, assuming a pretty large ballpark. Maybe +-2? Probably more in some cases. And of course this will vary with content and subjective preferences. I'd say x264 is still somewhat more consistent than x265, although the gap has shrunk a lot.

[dev0]

@dev
You did not understand. At high bitrates like yours difference in quality between x264 and x265 is marginal. I do not understand why you use x265 at all! x265 only shines at 4k and very low bitrates. h.265/HEVC standard in general was designed for such high resolutions ( hence default CU=64 ).


In this case you are only wasting time, energy and money.

You didn't understand, as i said before i didn't ask for anything more than future encode times at settings i mentioned, without your added value... But if you really ask then i will tell you, but i thought it's obvious.. AT THE MOMENT the main reason is space saving, there is NO other reason to use it, period.

[uneedme]

You didn't understand, as i said before i didn't ask for anything more than future encode times at settings i mentioned, without your added value... But if you really ask then i will tell you, but i thought it's obvious.. AT THE MOMENT the main reason is space saving, there is NO other reason to use it, period.

The efficiency will not ameliorate much on the same set, but people's hardware will be geared up gradually. X264 gets its usage popularity over decades. Should not you boost your hardware level, you will not get the results you want. Then you should stick to the x264 by now......

[LigH]

x265 1.4+304-50a2071500dc (https://www.mediafire.com/download/dx28c3g8qzzi1t1/x265_1.4%2B304-50a2071500dc.7z)

CBR is no "tuning" anymore, but a stricter ABR rate control mode. Can be enforced now with separate option "--[no-]strict-cbr". Previously published option "--ratetol" is gone again.

[STaRGaZeR]

What's the reason of the washed out results compared to x264 anyway? Noob here, but doesn't H.265 provide extra compression options on top of what H.264 did? For example, you have much larger transforms at your disposal, but you are not forced to use them. Could x265, by not using some H.265 features, approach the result of x264? Or does the extra efficiency always come together with the washed out look?

Currently x265 reminds me of a more or less pure lowpass filter. Which is nice from a signal processing standpoint, close to no artifacts other than the loss of high frequencies, but not so good as a product to be consumed by the human eye.

[LoRd_MuldeR]

What's the reason of the washed out results compared to x264 anyway? Noob here, but doesn't H.265 provide extra compression options on top of what H.264 did? For example, you have much larger transforms at your disposal, but you are not forced to use them. Could x265, by not using some H.265 features, approach the result of x264? Or does the extra efficiency always come together with the washed out look?

Currently x265 reminds me of a more or less pure lowpass filter. Which is nice from a signal processing standpoint, close to no artifacts other than the loss of high frequencies, but not so good as a product to be consumed by the human eye.

One thing that you have to keep in mind is: video encoding is all about making decisions! That's because there's an infinite number of possibilities to encode the very same source clip. Determining the "best" decision is not trivial at all! There are way too many possible combinations to test them all. So some "smart" heuristics are required. But even if you could test all possible decisions, how do you know which one is the "best"? Simply picking the one that gives the smallest "error" compared to the source clip, e.g. in terms of SAD (Sum of Absolute Differences), is no good idea. That's because the choice that gives the smallest "error" may be extremely expensive, in terms of "bit cost". Consequently, a good encoder needs to find the "best" trade-off between "error" and "bit cost". This is called RDO (Rate Distortion Optimization). Of course this is a computationally intensive task. And here we are not even talking about "Psy" optimizations and the like yet :rolleyes:

All this stuff is extremely complex. It needs years of optimization and fine-tuning, in order to get visually pleasing results. Remember how many years it took to get x264 to the point where it is now! Now, moving to a new compression standard, e.g. from AVC to HEVC, doesn't necessarily mean that you have to re-start everything from the scratch. Still, many of the "optimizations" that have been developed for AVC over all the years can not be applied to HEVC in a "1:1" fashion. Some optimizations may no longer be useful for HEVC, some optimizations may require a major overhaul/re-tuning before they can work with HEVC, and for certain HEVC-specific "challanges" it may be necessary to conceive completely new solutions.

This all doesn't happen in no time! Rome wasn't built in a day... ;)

(BTW: Having "extra compression options" available means that there are even more possibilities that you have to take into account in your decision making. And it means that there are even more ways to shoot yourself in the foot ^^)

[GrandAdmiralThrawn]

Hey,

I just tried to build x265 for the first time, and I have a simple question (I believe it to be simple at least).

Currently, I'm linking x264 against libav at compile time to be able to feed it any kind of input I like. Just like with the precompiled Windows builds available too. I have searched this thread for something similar in x265, but it seems no such option is available yet.

To make this more clear, I am not using x264 as a library, but the command line tool instead, and in the future I'd like to use x265 in the same way.

Some people suggested avs2yuv, I'm guessing to pipe decoded, raw YUV input into the x265 CLI program on Windows. I mean, that's ok I guess, haven't tried that yet.

I would still like to know if the developers are planning to make it possible in the future to link x265 against libav (or ffmpeg) directly, so you can throw pretty much any input video at it without any "unnecessary" glue layers in between?

Thanks!

[LigH]

No affirmative answer from me, I'm no developer, but ... probably yes; in a rather distant future though. First the kernel. I wouldn't expect that before, let's say, version 2.0, in their "progressive milestone" numbering.

For now, go the other way round: Use an ffmpeg which includes libx265.

[LigH]

A really whole lotta patches during the few last days:

x265 1.4+380-9d26082ca7b3 (https://www.mediafire.com/download/5lqoaqjq9j65uq0/x265_1.4+380-9d26082ca7b3.7z)

[GrandAdmiralThrawn]

I'm still happily using x264, so I don't have to hop over to x265 right now. Just curious about the long-term goals, and since x265.org doesn't really have much information, I thought I'd try here and maybe start fooling around a bit with it to check it out.

I guess I'd rather go with avs2yuv instead of linking in the other direction. Hm, may still need to do that on Linux/BSD though, not sure if I wanna do wine+AviSynth+avs2yuv there.

I guess x264 started in the same way, without anything but raw input support, right?

Thanks.

[LigH]

If your video source can be made available in YUV4MPEG format (*.y4m), x265 will prefer that, either as physical file or piped (e.g. out of ffmpeg). Just don't miss the "--y4m" parameter to tell x265 to interpret the header.

[GrandAdmiralThrawn]

My video sources are all files, which will usually be H.264/AVC, VC-1 or MPEG-2. Rarely anything else.

I haven't considered pipes though.. So I could just decode with the ffmpeg command line tool, and pipe its y4m output directly into x265, and it will get the relevant information from the y4m header?

Like frame rate, resolution, progressive/interlaced, etc?

[LigH]

That's the plan, and it already works this way in many cases, e.g. also in the "Hybrid" cross-platform video converter GUI by Selur.

[qyot27]

I guess x264 started in the same way, without anything but raw input support, right?
It would have, yes, but it also added alternative inputs really early on. AVI and AviSynth were added in March 2005, yuv4mpeg was added in March 2006, the rewritten AviSynth input was committed in October 2009, and FFMS and LAVF input were committed together in January 2010. In February 2013, the AviSynth input was extended to allow using AvxSynth on Linux and OSX.

x265's commit log starts in March 2013, which was 22 months ago. x264's SVN commit log begins in June 2004 (the CVS history is probably lost to the mists of time), so by the 22-month mark, it already supported AVI, AviSynth, and y4m.

But you also have to account for x265 having different development priorities. High bit depth was made available in x265 at an extremely early stage, it took years to get >8bit in x264.

[mandarinka]

Note that x265 really wants to run in x64 mode, which would make real avisynth support a bit limited in usefulness.

Using avs2yuv is easy enough and doesn't have much downsides, so I can understand why the dev team doesn't explore native avisynth support.

[x265_Project]

What's the reason of the washed out results compared to x264 anyway? Noob here, but doesn't H.265 provide extra compression options on top of what H.264 did? For example, you have much larger transforms at your disposal, but you are not forced to use them. Could x265, by not using some H.265 features, approach the result of x264? Or does the extra efficiency always come together with the washed out look?

Currently x265 reminds me of a more or less pure lowpass filter. Which is nice from a signal processing standpoint, close to no artifacts other than the loss of high frequencies, but not so good as a product to be consumed by the human eye.
Can you share your command line?

To increase the retention of spatial detail, add --psy-rd 0.3 --psy-rdoq 1.0 to your command line. You can experiment with higher psy-rd and psy-rdoq strengths, but at some point (depending on the bit rate and other settings), if psy-rd strength is set too high you may notice temporal artifacts (the movement/position of objects is no longer accurate). A reasonable level of psy-rd will counteract the natural tendency of the encoder to low-pass filter the content.

[jlpsvk]

@STaRGaZeR
Yes....do what x265_Project says. :) And don't forget to put --rd 4 to command line, as it's needed for --psy-rdoq.

[x265_Project]

@STaRGaZeR
Yes....do what x265_Project says. :) And don't forget to put --rd 4 to command line, as it's needed for --psy-rdoq.

You would only need to add --rd 4 if you were running --preset medium or a faster preset (fast, faster, etc.)... but this would slow down a faster preset considerably, so you might as well use --preset slow.

[foxyshadis]

One thing that you have to keep in mind is: video encoding is all about making decisions! That's because there's an infinite number of possibilities to encode the very same source clip. Determining the "best" decision is not trivial at all! There are way too many possible combinations to test them all. So some "smart" heuristics are required. But even if you could test all possible decisions, how do you know which one is the "best"? Simply picking the one that gives the smallest "error" compared to the source clip, e.g. in terms of SAD (Sum of Absolute Differences), is no good idea. That's because the choice that gives the smallest "error" may be extremely expensive, in terms of "bit cost". Consequently, a good encoder needs to find the "best" trade-off between "error" and "bit cost". This is called RDO (Rate Distortion Optimization). Of course this is a computationally intensive task. And here we are not even talking about "Psy" optimizations and the like yet :rolleyes:

All this stuff is extremely complex. It needs years of optimization and fine-tuning, in order to get visually pleasing results. Remember how many years it took to get x264 to the point where it is now! Now, moving to a new compression standard, e.g. from AVC to HEVC, doesn't necessarily mean that you have to re-start everything from the scratch. Still, many of the "optimizations" that have been developed for AVC over all the years can not be applied to HEVC in a "1:1" fashion. Some optimizations may no longer be useful for HEVC, some optimizations may require a major overhaul/re-tuning before they can work with HEVC, and for certain HEVC-specific "challanges" it may be necessary to conceive completely new solutions.

This all doesn't happen in no time! Rome wasn't built in a day... ;)

(BTW: Having "extra compression options" available means that there are even more possibilities that you have to take into account in your decision making. And it means that there are even more ways to shoot yourself in the foot ^^)
I'm kind of sick of this apologetic "it's super hard, just keep waiting!" explanation every time someone compares it to x264, when it'd be more useful to just recommend when to use x264 and how to get the most out of x265 while it is what it is. x264 didn't need years of tuning, it needed months from the introduction of its psy algorithms (aq and later psy) to mostly perfect them while x265 got to practically start with them. The years in between were mostly lack of interest. Further visual tuning isn't a given, it may never happen, since speed, memory size, and code quality are the primary goals of x265 right now. We have to evaluate the encoder as it is, not as we hope it might be someday.

I don't blame them for focusing on speed, though. That'll bring more users and more benefits to current users than a bit more detail at medium sizes.

[Tommy Carrot]

I don't blame them for focusing on speed, though. That'll bring more users and more benefits to current users than a bit more detail at medium sizes.

I'm not sure i agree. If the visual quality is not convincingly better, what's the incentive to use x265 anyway? Doesn't matter how much they improve the encoding speed, it'll still be much slower than x264, not to mention you can play h.264 basically on anything.

I believe improving the visual quality should be the most important objective. Once they conclusively beat x264 on all bitrate range, then should they spend more effort on speed optimization.

[x265_Project]

Encoding video ALWAYS involves a trade-off between efficiency and speed. Wherever you want to be on this curve, we want x265 to be the encoder of choice.

Foxyshadis - Encoding efficiency (visual quality at any target bit rate) has always been our #1 priority. It will always be our #1 priority. We want to produce the encoder that people want to use over all possible alternatives - because it produces the best encodes. So we're always working on improving encoding efficiency.

Producing the fastest encoder at any target efficiency level is our next priority. Whether you need our encoder for offline or real-time applications, everyone who uses x265 wants it to faster... much faster. We've got many parallel efforts underway to improve performance. Some people will see these performance improvements and choose to run with higher quality settings, so in some ways performance equals quality.

Lord Mulder - You're right, x265 had the advantage of using x264 (and the HM) for a head start, and this certainly helped us add valuable features much faster than we otherwise would have been able to do. But the x265 project is different than the x264 project in a number of ways. The key difference is that x265 is backed by a commercial company with multiple commercial customers funding the effort at a very significant level right from the start. This investment has enabled us to put a very large team together, greatly accelerating the pace of development. So although HEVC is significantly more complex than AVC, I think the pace of x265 development is faster than what the very talented x264 team was able to do in the early years.

x265 will celebrate it's 2nd birthday in March this year, while many of our competitors have been working on their HEVC encoders for more than 4 years. But we're getting very positive feedback from our customers and prospective customers, who tell us that we're winning the head to head shootouts against our competition.

We owe much of our success to the x264 team, both for the fantastic code base that we were able port to x265, and for their help and guidance along the way. Being open source is a key advantage. Our code is reviewed and we receive suggestions and patches from experts worldwide. Customers know that x265 is by far the most widely used HEVC encoder, and so any bugs are more likely to be found and reported, leading to a more robust encoder than commercial implementations. We have the x264 team (and VideoLAN, FFMPEG, etc) to thank for building a great reputation for open-source encoders, and for showing us the way.

[Boulder]

Foxyshadis - Encoding efficiency (visual quality at any target bit rate) has always been our #1 priority. It will always be our #1 priority. We want to produce the encoder that people want to use over all possible alternatives - because it produces the best encodes. So we're always working on improving encoding efficiency.
From what I've read and experienced myself while testing (very small tests), there seems to be a great difference between x264 and x265 what comes to retaining the noise etc. that is in the source.

I am not sure whether it is intentional, that is, people want to see a clean image instead of the analog or digital noise, or not, but it is clearly one thing which is keeping me from using x265 for now. I posted my examples in this post: http://forum.doom9.org/showthread.php?p=1705500#post1705500. Due to this, it's difficult to compare how well x265 compares to x264 regarding the actual efficiency. What I mean is to test "Can I use the same CRF value in x265 and not notice the difference to x264 and save NAS diskspace".

I have not experimented with the psy-rd or psy-rdoq options at this point. In my opinion they should be implemented in tunings like x264 does, because most of the users (including myself) should not touch the parameters at all. I also do not want to tune the parameters according to the source every time I encode something as x264 doesn't require that to provide good quality results.

Please don't mistake my post as a rant - I am merely presenting some opinions and wish to hear if there are any possibilities to improve things in the near future. I am very hopeful that x265 will be my encoder of choice at some point.

[LigH]

When comparing different video encoding algorithms, never forget: They are different. They have different purposes. It is no surprise that they create different results. There are different optimal algorithms for different purposes.

HEVC was mainly developed to be able to broadcast UHD resolutions via DVB. Video complexity must be reduced, details must vanish to achieve this goal. Any HEVC encoder will try its best to make the loss as little annoying as possible, but the bandwidth is limited, and you can't fool Claude Shannon's laws of information and entropy. Video compression is a compromise, not magic.

[Boulder]

That is what I "feared". There is no free lunch and in this case your lunch is paid by the detail loss.

Maybe the x265 team should bring this thing more to the front, the name itself implies that it is a successor to x264 while it is more like a step-brother. Of course, I understand the small Spinal Tap analogy there also is but anyone who knows the movie, knows what that means :D

However, at some point commercial encodes might not require this detail loss, especially if 4K wants to get to our home theatres to replace Blu-rays etc.

[x265_Project]

Yes, I think we're getting to the point where we will be able to add --psy-rd and --psy-rdoq to the x265 performance presets, which should mean that for most presets, as with x264, psycho-visual optimizations will be on by default. We wanted to wait until we had stabilized the algorithms, and then we needed to do assembly-code optimizations in order to insure that they don't slow down encodes too much.

[STaRGaZeR]

Can you share your command line?

To increase the retention of spatial detail, add --psy-rd 0.3 --psy-rdoq 1.0 to your command line. You can experiment with higher psy-rd and psy-rdoq strengths, but at some point (depending on the bit rate and other settings), if psy-rd strength is set too high you may notice temporal artifacts (the movement/position of objects is no longer accurate). A reasonable level of psy-rd will counteract the natural tendency of the encoder to low-pass filter the content.

I'm just messing around with several options at the moment, thanks for the suggestions.

The point of my post was that if someone had tested which options or which methods only available in HEVC give x265 its characteristic lowpass look. For example:

- More intra decision modes in HEVC vs. AVC: unlikely this would cause any washout.

- Transforms: HEVC has 4x4, 8x8, 16x16 and 32x32 transforms, AVC only 4x4 and 8x8. The bigger the transform, potentially the more washed out result. Has anybody tried to limit x265 to 8x8 transform size, if that's even possible, and see what happens? Compression efficiency would suffer for sure, but what about the image quality? I haven't seen such tests in the forum.

- The same with any other improvement in HEVC vs AVC.

[benwaggoner]

When comparing different video encoding algorithms, never forget: They are different. They have different purposes. It is no surprise that they create different results. There are different optimal algorithms for different purposes.
For different kinds of problems perhaps. But in the same class you get new algorithms that replace old ones by being better at everything. An optimal .7z LZMA2 is always smaller than an optimal a .zip Deflate file other that compatibility with stuff that can only open .zip.

I anticipate that HEVC encoders will pass the point where they always look at least as good as H.264 encoders at the same bitrate, and generally a lot better at typical bitrates. Including in detail preservation.

HEVC was mainly developed to be able to broadcast UHD resolutions via DVB. Video complexity must be reduced, details must vanish to achieve this goal. Any HEVC encoder will try its best to make the loss as little annoying as possible, but the bandwidth is limited, and you can't fool Claude Shannon's laws of information and entropy. Video compression is a compromise, not magic.
DVB may have been a scenario but certainly wasn't the primary one, if there even is one. HEVC is designed to scale from lossless archival files to <100 Kbps streams for mobile devices. It's scenarios are a slight superset of H.264.

Also, the Shannon limit only applies to lossless encoding (CABAC in H.264 and HEVC). There's no equivalent theoretical maximum for bitrate required for a given psychovisual experience. If my career has taught me one thing, is that over the long term codecs get better than I imagined was possible. <1 bbp was considered crazy talk once upon a time. Moore's Law is a wonderful thing.

By the time I retire I expect we can deliver the same quality as we have today at <<25% of current best bitrates.

In no way is HEVC designed or constrained to preserve less detail than H.264. It's just that H.264 encoders have many more years of refinement behind them. Certainly x265 today handily outperforms x264 when it was the same age.

[Tommy Carrot]

In no way is HEVC designed or constrained to preserve less detail than H.264. It's just that H.264 encoders have many more years of refinement behind them. Certainly x265 today handily outperforms x264 when it was the same age.

I think the reason some of us is a bit 'sceptical' about x265 is because the efficiency/visual quality just hasn't improved for a long time. When i compare the quality of the latest build to several month old ones, it just isn't conclusively better (with the psy-rd off, it often loses to more than a year old builds). I get that improving the visual quality of something as complex as HEVC is a very difficult task, but x264 was always steadily improving quality-wise in the first few years (albeit from a lower starting point).

[Asmodian]

I think the reason some of us is a bit 'sceptical' about x265 is because the efficiency/visual quality just hasn't improved for a long time. When i compare the quality of the latest build to several month old ones, it just isn't conclusively better (with the psy-rd off, it often loses to more than a year old builds). I get that improving the visual quality of something as complex as HEVC is a very difficult task, but x264 was always steadily improving quality-wise in the first few years (albeit from a lower starting point).

I am not sure I agree with that, my memories of the beginning years of x264 involve a lot of people worried about detail loss compared to Xvid. We also thought x264 might never be able to keep detail as well as Xvid. If is funny how these x265 vs x264 comparisons seem almost identical to how I remember the early x264 vs Xvid comparisons. Déjà Vu ;)

How many years did it take x264 to be better than Xvid at all bitrates? I remember long periods of only speed improvements for x264 as well.

[poisondeathray]

I am not sure I agree with that, my memories of the beginning years of x264 involve a lot of people worried about detail loss compared to Xvid. We also thought x264 might never be able to keep detail as well as Xvid. If is funny how these x265 vs x264 comparisons seem almost identical to how I remember the early x264 vs Xvid comparisons. Déjà Vu ;)

How many years did it take x264 to be better than Xvid at all bitrates? I remember long periods of only speed improvements for x264 as well.

I agree completely! Very close similarities.

Also with RMVB. Both h264 and RMVB in those early days had that "plastic doll" look

Remember how slow AVC was for both decoding and encoding compared to xvid? That was even before dual cores

There was no benefit to switching from xvid those early days