x265 HEVC Encoder

[LoRd_MuldeR]

Looks like "high bitdepth" build is currently broken:
4>x265-static.lib(asm-primitives.obj) : error LNK2019: unresolved external symbol "unsigned char (* x265::IntraFilterType)[35]" (?IntraFilterType@x265@@3PAY0CD@EA)
referenced in function "void __cdecl x265::intra_allangs<2>(unsigned short *,unsigned short *,unsigned short *,unsigned short *,unsigned short *,int)" (??$intra_allangs@$01@x265@@YAXPEAG0000H@Z)
build\vc12-x86_64\Release\x265.exe : fatal error LNK1120: 1 unresolved externals

The only place I can see "IntraFilterType" being defined is in "predict.h" where it is defined as static.

Therefore it's clear that using "extern" like this, in "asm-primitives.cpp", won't work:
#if HIGH_BIT_DEPTH
extern unsigned char IntraFilterType[][35];
[...]

(Though simply including "predict.h" in "asm-primitives.cpp" doesn't work either)

[filler56789]

rev 1.2+518, 8-bit depth, shows a compiler warning with GCC 4.8.1 under MSYS
(sadly I remembered to copy the warning message after I had closed the CLI window :o )

[a5180007]

Maybe this warning (obtained with MSVC 1800) :
warning C4701: potentially uninitialized local variable 'lowmode' used x265\source\encoder\slicetype.cpp line 1714
EDIT : also warning C4800: 'const unsigned char' : forcing value to bool 'true' or 'false' (performance warning) x265\source\encoder\predict.cpp line 78

[LigH]

Yes, the warning about "lowmode". Not the const though.

I just reported both (lowmode warning and linker error) to the mailinglist.

[Darius510]

Is there any way to throttle down the intensity of encoding? My CPU is overclocked and stable in normal use, even stable with synthetic stress tests...but x265 is so intense and creates so much heat that it'll crash the entire system with an hour or two. Even something as mild as an option to switch it to 90% encoding speed would probably make a huge difference.

[x265_Project]

Is there any way to throttle down the intensity of encoding? My CPU is overclocked and stable in normal use, even stable with synthetic stress tests...but x265 is so intense and creates so much heat that it'll crash the entire system with an hour or two. Even something as mild as an option to switch it to 90% encoding speed would probably make a huge difference.

We don't have a command that monitors and limits the actual CPU %, but there are a couple of ways that you can throttle x265 back a bit on a multi-core PC.

--threads <n> - controls the number of parallel threads that x265 will allow. Normally this defaults to the # of threads your processor can support (equal to the # of cores, or the # of cores x 2 for a hyper-threaded processor). If you dial this back x265 will leave some threads for the rest of your system, and if you aren't running anything else this should cool things off a bit.

--no-wpp - this would turn off wavefront parallel processing. It would likely dial back performance, but it's not as definitive as --threads.

-- frame-threads <n> - controls the number of frames that will be processed in parallel. Dialing this back would reduce CPU utilization, but it's better to just adjust --threads.

If you're technically inclined you may want to look at dialing back the clock frequency of your CPU, and/or improving your CPU cooling. If you haven't done so, you may want to open your case and carefully vacuum any dust off your CPU heat sink and other internals.

[foxyshadis]

All the fast-intra related compiling problems are fixed now. Thanks, guys!

[Darius510]

We don't have a command that monitors and limits the actual CPU %, but there are a couple of ways that you can throttle x265 back a bit on a multi-core PC.



--threads - controls the number of parallel threads that x265 will allow. Normally this defaults to the # of threads your processor can support (equal to the # of cores, or the # of cores x 2 for a hyper-threaded processor). If you dial this back x265 will leave some threads for the rest of your system, and if you aren't running anything else this should cool things off a bit.



--no-wpp - this would turn off wavefront parallel processing. It would likely dial back performance, but it's not as definitive as --threads.



-- frame-threads - controls the number of frames that will be processed in parallel. Dialing this back would reduce CPU utilization, but it's better to just adjust --threads.



If you're technically inclined you may want to look at dialing back the clock frequency of your CPU, and/or improving your CPU cooling. If you haven't done so, you may want to open your case and carefully vacuum any dust off your CPU heat sink and other internals.


Thanks for the suggestions. I tried limiting threads, but since my i7 is hyperthreaded, dropping to 7 threads results in 3 loaded cores and one slightly less loaded core. I'd need to go all the way down to three threads to essentially get it to lay off an entire core at any given time, but then it's way, way too slow.

Cooling isn't an issue either, I've got a CPU cooler that's literally the size of my 7 month old baby's head and no less than 12 fans in the case.

x265 raises my CPU temp about 10C over x264, I'm assuming it extensively uses AVX instructions?

Perhaps this shouldn't be the job of any application/algorithm, but x265 is so hard on a CPU that some built in method to encode at less than full load would be very useful. I worry about all those poorly cooled PCs out there! :p

[x265_Project]

Thanks for the suggestions. I tried limiting threads, but since my i7 is hyperthreaded, dropping to 7 threads results in 3 loaded cores and one slightly less loaded core. I'd need to go all the way down to three threads to essentially get it to lay off an entire core at any given time, but then it's way, way too slow.

Cooling isn't an issue either, I've got a CPU cooler that's literally the size of my 7 month old baby's head and no less than 12 fans in the case.

x265 raises my CPU temp about 10C over x264, I'm assuming it extensively uses AVX instructions?

Perhaps this shouldn't be the job of any application/algorithm, but x265 is so hard on a CPU that some built in method to encode at less than full load would be very useful. I worry about all those poorly cooled PCs out there! :p
I know it's like Prime95 on steroids, but we run it around the clock on many machines without any issue at all. Your CPU has thermal management that is supposed to handle 100% utilization of all cores, adjusting the clock frequency as needed to prevent problems. I'm thinking that either you've got a defective CPU or a thermal issue.

If you'll forgive me for going on this tangent (I don't want to insult your intelligence)... for the benefit of others... even if you have a great heat sink, if the thermal paste wasn't applied correctly you could have air pockets, and that could lead to crashes. If you're a PC builder, I find what works best for consistently low CPU temps is to apply thermal paste in a star pattern (a larger drop of thermal paste in the middle, with lines radiating outward to the corners and sides)... kind of like this...
http://docs.oracle.com/cd/E19121-01/sf.x4200/819-1157-23/figures/Maint-26.jpgIn this way, as you place the cooler on the CPU, the air has a clear path to escape as the paste spreads, and it still gets all the way to the corners. You'll get some excess coming out the sides, but that's easy to wipe up.
See http://www.overclockers.com/applying-thermal-grease/ or https://www.youtube.com/watch?v=EyXLu1Ms-q4 for visual proof on why this pattern works better than pre-spreading the thermal paste. On an older PC I found that I could lower my idle temp by more than 10 degrees C once I figured this out.

Do you have a BIOS utility to monitor CPU temperatures? What kind of idle temp are you seeing? What do you see at full load?

I'm not sure how easy it would be to add a feature to monitor and throttle CPU utilization, but I can check into this.

[foxyshadis]

Is there any way to throttle down the intensity of encoding? My CPU is overclocked and stable in normal use, even stable with synthetic stress tests...but x265 is so intense and creates so much heat that it'll crash the entire system with an hour or two. Even something as mild as an option to switch it to 90% encoding speed would probably make a huge difference.

Your overclock's not as stable as you think, but summer hits me pretty hard, too. Besides the hardware problems Tom's explained well, I'd go into your BIOS and look for heat-throttling capability first; that's the best and lowest-level way to attack the problem before it can get bad. It'll throttle until your CPU cools down, then ease up until it heats up again. If you don't have that, a windows program to emulate it is TThrottle (http://efmer.com/b/eFMer_programs), but that one doesn't always work.

Here's another option: BES (http://mion.faireal.net/BES/), which can limit CPU usage, but only manually.

[Blue_MiSfit]

Yeah, remove the overclock :D

You're pushing your hardware too hard.

[Darius510]

I know it's like Prime95 on steroids, but we run it around the clock on many machines without any issue at all. Your CPU has thermal management that is supposed to handle 100% utilization of all cores, adjusting the clock frequency as needed to prevent problems. I'm thinking that either you've got a defective CPU or a thermal issue.



If you'll forgive me for going on this tangent (I don't want to insult your intelligence)... for the benefit of others... even if you have a great heat sink, if the thermal paste wasn't applied correctly you could have air pockets, and that could lead to crashes. If you're a PC builder, I find what works best for consistently low CPU temps is to apply thermal paste in a star pattern (a larger drop of thermal paste in the middle, with lines radiating outward to the corners and sides)... kind of like this...

http://docs.oracle.com/cd/E19121-01/sf.x4200/819-1157-23/figures/Maint-26.jpgIn this way, as you place the cooler on the CPU, the air has a clear path to escape as the paste spreads, and it still gets all the way to the corners. You'll get some excess coming out the sides, but that's easy to wipe up.

See http://www.overclockers.com/applying-thermal-grease/ or https://www.youtube.com/watch?v=EyXLu1Ms-q4 for visual proof on why this pattern works better than pre-spreading the thermal paste. On an older PC I found that I could lower my idle temp by more than 10 degrees C once I figured this out.



Do you have a BIOS utility to monitor CPU temperatures? What kind of idle temp are you seeing? What do you see at full load?



I'm not sure how easy it would be to add a feature to monitor and throttle CPU utilization, but I can check into this.


I get idle temps around 25-30C. Load temps in a game like crysis 3 maybe 60C. A synthetic stress test, maybe 70-80C. These are very good temps for an OCed Haswell. But X265....90-95C. The only thing that can surpass it is an AVX based stress test like linpack, but nobody seriously uses those with AVX-capable chips because the workload is so unrealistic and people fear it'll burn their chips out. x265 is kind of in a class of its own here. Sure, the chip itself will throttle back at 95C, but I think you'd have a hard time finding people comfortable with running a CPU at 95C for extended periods.

[Atak_Snajpera]

x265 is suppose to use everything you've got in your cpu. Afterall we want faster encoding speed right? if your cpu is not able to survive linpack stress test then your overclocked cpu has nothing but empty MHzs.

[Darius510]

x265 is suppose to use everything you've got in your cpu. Afterall we want faster encoding speed right? if your cpu is not able to survive linpack stress test then your overclocked cpu has nothing but empty MHzs.


I'd say it's supposed to do what it's programmed to do, and we may not all want the same thing. But I'm not here to start a fight or change anyone's mind, just looking to solve a problem on my end.

Is there any way to disable AVX support? I have a feeling that's the root cause of the extreme temps.

Either way, I am really impressed with x265 - I can cut a blu ray rip to nearly half it's size or less and all that seems lost is a little bit of film grain. Realistically, how much better can it get from here?

Also, I did come across some paper where a technique was described that reused some of the motion information from an h264 file to drastically speed encoding to h265...is that on the roadmap for x265?

[LigH]

Respect... :D

I wonder if you can disable AVX support by masking it in this parameter:
--[no-]asm <bool|int|string> Override CPU detection. Default: auto
Unfortunately, you may have to dig a bit deeper to find a relevant CPU feature mask string.

[Atak_Snajpera]

Either way, I am really impressed with x265 - I can cut a blu ray rip to nearly half it's size or less and all that seems lost is a little bit of film grain. Realistically, how much better can it get from here?

You can achieve even better results with x264. At very high bitrates ~15-20Mbps (half of regular blu-ray movie) x264 currently retains more details than x265. You do not need all those fancy algos/tools/whatever x265 has for that! x265 is only useful in crazy low bitrates like ~1 Mbps for 1080p.

I'd say it's supposed to do what it's programmed to do, and we may not all want the same thing. But I'm not here to start a fight or change anyone's mind, just looking to solve a problem on my end.
The problem is in your heatsink and too much overclocked cpu. Despite my efforts I'm unable to go above 68 C even with two x265 running at the same time!

http://i.cubeupload.com/qH0JN4.png

[Darius510]

You can achieve even better results with x264. At very high bitrates ~15-20Mbps (half of regular blu-ray movie) x264 currently retains more details than x265. You do not need all those fancy algos/tools/whatever x265 has for that! x265 is only useful in crazy low bitrates like ~1 Mbps for 1080p.


The problem is in your heatsink and too much overclocked cpu. Despite my efforts I'm unable to go above 68 C even with two x265 running at the same time!

http://i.cubeupload.com/qH0JN4.png


The Haswell architecture on my 4790K is very different from the sandy bridge on yours. Haswell is much hotter under load, especially when overclocked and using AVX apps. Also a big deal was made in the enthusiast community about how they switched the thermal interface between the die and the heat spreader after sandy bridge, which limits the thermal performance. They attempted to address the issue with the latest chips but it's still a fundamental limitation of the architecture, and this is apparently an increasing problem as they shrink the process further and further every year. I own one of the best HSFs you can buy, a Noctua D14....trust me, if you saw this thing you wouldn't be questioning it's capability.

http://www.legitreviews.com/images/reviews/1212/noctua_nhd14_014.jpg

Right now I'm testing with 7 threads and it seems 5-10C cooler, so hopefully that solves the problem....I'll know by whether it's still running this time tomorrow. :p

[Atak_Snajpera]

I own one of the best HSFs you can buy, a Noctua D14....trust me, if you saw this thing you wouldn't be questioning it's capability.

LOL! I also have Noctua D14 on my xeon :) This thing is soooo big that I can't even close my case :)

[mastrboy]

It's not just AVX instructions that heats a Haswell a lot more than former CPU's, it's anything that hits hard on the FPU.

Though it looks like Broadwell's lid will be soldered on, which should improve temperatures.
Not sure how happy overclockers who delid will be about that :p

(Also a owner of the Noctua D14, thanks to Haswell)

[filler56789]

Is there any way to disable AVX support? I have a feeling that's the root cause of the extreme temps.

Tweak and recompile :devil: the source-code :D

[x265_Project]

The Haswell architecture on my 4790K is very different from the sandy bridge on yours. Haswell is much hotter under load, especially when overclocked and using AVX apps. Also a big deal was made in the enthusiast community about how they switched the thermal interface between the die and the heat spreader after sandy bridge, which limits the thermal performance. They attempted to address the issue with the latest chips but it's still a fundamental limitation of the architecture, and this is apparently an increasing problem as they shrink the process further and further every year. I own one of the best HSFs you can buy, a Noctua D14....trust me, if you saw this thing you wouldn't be questioning it's capability.

http://www.legitreviews.com/images/reviews/1212/noctua_nhd14_014.jpg

Right now I'm testing with 7 threads and it seems 5-10C cooler, so hopefully that solves the problem....I'll know by whether it's still running this time tomorrow. :p
Righteous cooler dude.

Your 4970k has a TDP of 88 watts. Overclocked, you are using more power and generating more heat. But obviously your massive cooler is not pulling the > 100 watts of heat out as fast as it is being generating. Unless you're trying for 5 GHz, the Noctua D14 should be able to dissipate 125 watts or more, and it should be able to do this at sane CPU temps (under 70° C). So it seems like you have a heat transfer problem. Look at the temps that other people are reporting with overclocked 4790k's and this cooler...
http://www.newegg.com/Product/Product.aspx?Item=N82E16835608018
I hate to keep coming back to this, but if you pre-spread your thermal compound, you could have trapped air bubbles, and that would explain what you're seeing. I had the same problem, and when I removed and reapplied thermal compound the right way, my temps dropped by more than 10 degrees C at idle, and 20 degrees C at load. I would definitely not be comfortable running my CPU at anything above 70 degrees C sustained. If your thermal compound was applied properly you are overclocking past what your CPU can handle. You'll get a better overall result by bringing your clock speed back down to something reasonable versus limiting the # of x265 threads.

[Darius510]

Righteous cooler dude.



Your 4970k has a TDP of 88 watts. Overclocked, you are using more power and generating more heat. But obviously your massive cooler is not pulling the > 100 watts of heat out as fast as it is being generating. Unless you're trying for 5 GHz, the Noctua D14 should be able to dissipate 125 watts or more, and it should be able to do this at sane CPU temps (under 70° C). So it seems like you have a heat transfer problem. Look at the temps that other people are reporting with overclocked 4790k's and this cooler...

http://www.newegg.com/Product/Product.aspx?Item=N82E16835608018

I hate to keep coming back to this, but if you pre-spread your thermal compound, you could have trapped air bubbles, and that would explain what you're seeing. I had the same problem, and when I removed and reapplied thermal compound the right way, my temps dropped by more than 10 degrees C at idle, and 20 degrees C at load. I would definitely not be comfortable running my CPU at anything above 70 degrees C sustained. If your thermal compound was applied properly you are overclocking past what your CPU can handle. You'll get a better overall result by bringing your clock speed back down to something reasonable versus limiting the # of x265 threads.


I'll double check the mounting and thermal paste later today, I don't think it's the issue though. I should also mention that outside temps are 80-90, I leave the PC in an enclosed room and I'm running 4.6ghz/1.35V. So there's a lot of things contributing to the high temps at the moment, but I'm still testing the limits so to speak - if I find it can survive an hours long encode under the worst conditions, I'll feel confident that it'll be stable under more reasonable ones. I could prob drop the temps 10C by cracking a window. With the AC on temps are much more reasonable. :p

I just mean to point out that all other things being equal, x265 is far and away the most stressful real world application I've encountered. Outside of x265 hardly anything will break 70C for more than a moment. Unlike a lot of people here, I'm only going to be encoding on occasion, so I'd rather find a way for x265 to fit in with my current configuration than design around an infrequent use case.

[benwaggoner]

Your overclock's not as stable as you think, but summer hits me pretty hard, too. Besides the hardware problems Tom's explained well, I'd go into your BIOS and look for heat-throttling capability first; that's the best and lowest-level way to attack the problem before it can get bad. It'll throttle until your CPU cools down, then ease up until it heats up again.
For my 12-core Sandy Bridge workstation, I would get hard crashes after some hours of full-bore encoding until I set the BIOS fan speed to High. That was louder, but way more stable.

[benwaggoner]

You can achieve even better results with x264. At very high bitrates ~15-20Mbps (half of regular blu-ray movie) x264 currently retains more details than x265. You do not need all those fancy algos/tools/whatever x265 has for that! x265 is only useful in crazy low bitrates like ~1 Mbps for 1080p.
That totally doesn't match my results. I start seeing advantages in x265 over x264 below about 10 Mbps CBR for challenging 1080p content, and definitely by 5 Mbps.

Without --tune film x265 needs more command line parameters than x264 to get best results, though.

[benwaggoner]

--no-wpp - this would turn off wavefront parallel processing. It would likely dial back performance, but it's not as definitive as --threads.
Note that turning off WPP really reduced the threadability of decoding, which likely almost certainly result in slower decoding in software, particularly at large frame sizes. I would shy away from that for thermal management as it triggers a big change in the output bitstream.

[Darius510]

For my 12-core Sandy Bridge workstation, I would get hard crashes after some hours of full-bore encoding until I set the BIOS fan speed to High. That was louder, but way more stable.


Was that non-overclocked with the stock cooling?

[Blue_MiSfit]

Guys, we all love our hardware (and I espeically <3 my SANs) but let's try to keep the thread on track :)

[Atak_Snajpera]

That totally doesn't match my results. I start seeing advantages in x265 over x264 below about 10 Mbps CBR for challenging 1080p content, and definitely by 5 Mbps.

Without --tune film x265 needs more command line parameters than x264 to get best results, though.

I see obvious differences between 1 - 2 mbps for 1080p. With higher bitrates 4 mbps and more difference is too small to notice. I don't use cbr I use 2-pass mode for my tests.

[x265_Project]

Guys, we all love our hardware (and I espeically <3 my SANs) but let's try to keep the thread on track :)
Blue_MiSfit - the open question here is whether x265 can run fine on any hardware without some sort of CPU utilization monitoring and throttling. I believe the answer is yes, it can... but we want to understand the issue. Debugging the hardware config helps us clear up the question.

[Darius510]

Blue_MiSfit - the open question here is whether x265 can run fine on any hardware without some sort of CPU utilization monitoring and throttling. I believe the answer is yes, it can... but we want to understand the issue. Debugging the hardware config helps us clear up the question.


Right, that's why I asked if he was running everything stock...because I suspect x265 has the potential to cause issues on everyday machines. In any case I think it would only be a small percentage that's affected, but there is precedent - I've used crypto mining applications that actively monitor temperature and control fan speed to ensure it doesn't get out of hand. In a lot of ways they're very similar, since they also punish a GPU by running at maximum capacity for extended periods of time.

Granted, the actual monitoring is probably a feature best left to an application and not the codec, but some sort of wait or throttle function in the encoder will probably be needed to facilitate that.

[fumoffu]

Haswell and Ivy Bridge CPUs often have problems with high temps after OC.
If you're not scared (and have cash for new CPU, just in case :p) you can try this: https://www.youtube.com/watch?v=XXs0I5kuoX4

[foxyshadis]

Interesting that AVX2 (or maybe SSE4 in general?) causes such extraordinary power use. I was gearing up to start encoding actual movies, so I guess I'll have to monitor my laptop's heat. It's definitely useful information for Haswell owners, even non-overclockers.

[Dark Eiri]

Blue_MiSfit - the open question here is whether x265 can run fine on any hardware without some sort of CPU utilization monitoring and throttling. I believe the answer is yes, it can... but we want to understand the issue. Debugging the hardware config helps us clear up the question.

Absolutely every software is capable of running fine on absolutely every CPU, if it's a proper mantained machine. The hardware itself should work at it's maximum potential just fine. It's designed for doing exactly that.

If it's overclocked beyond it's limits or badly cooled, it's absolutely not the software's fault. It's either the user's fault for not doing it right or a faulty piece of hardware. Either way, it should not be a concern of the software. The only thing that would make it NOT run fine is some freezing bug in the code itself.

The CPUs are made to be stressed. If someone's CPU cannot handle having it's full potential used, it's their problem, not x265 in the slightest.

[NikosD]

Let's not exaggerate about x265' s ability to produce high temps.

Yes, for such a common (?) task of video encoding in H.265 format the heat produced is high.

My Core i7-4790 with stock cooler in high ambient temp, went fast at around 100 degrees (Celsius) and throttled the turbo frequency.

So from 3.8GHz went 3.7 and then 3.6, then again 3.7 etc.

If I run even more demanding CPU stress apps like Prime95 v28. 5 first option (Small FFT's) or Linx latest version in very high settings, then the CPU starts at 3.6 (never reaches turbo freq) and throttles 3.5, 3.4, 3.3 and then I just close the app because I feel pity for the CPU :)

Prime95 uses FMA3 and for Haswells produces maxTDP for me, even more than max TDP from Intel's spec.

It's a 84W TDP CPU, consuming ~100W during Prime95 test.

There are definitely problems with Ivy/Haswell CPUs with the internal IHS and the heat spreader, which all these apps (including x265 project) just bring them to surface.

[easyfab]

@x265_Project

What is your position about the command line synthax compared to x264 because I thought it was similar ? Should it be ? especially shortcut ?

Because during my tests "x264 2-pass vs x265 2-pass", I copy/paste my x264 command line. Problem : for x264 -p is the shortcut for --pass and for x265 it's the shortcut for --preset .
And yes, It took me some time to find out why x265 sucks so much in 2-pass ;)

[qyot27]

I know it was discussed a bit earlier, but what was/is the conclusion about whether certain features (like --ctu) need to be configured differently for different resolutions? Are higher CTU sizes always a higher precision option, or is there a point of diminishing returns for the larger sizes on smaller resolutions like 480p, or was that simply a speed vs. quality decision?

And just out of curiosity on the subject of RExt, which pieces/features need to be adjusted against the updated spec (which I assume has been released already, because it said it was supposed to be July and at least FFmpeg added support for decoding of non-4:2:0 content around the same time) so that the warning about non-compliancy is no longer necessary?

[LoRd_MuldeR]

Looks like "high bitdepth" build is currently broken:

The only place I can see "IntraFilterType" being defined is in "predict.h" where it is defined as static.

Therefore it's clear that using "extern" like this, in "asm-primitives.cpp", won't work:
#if HIGH_BIT_DEPTH
extern unsigned char IntraFilterType[][35];
[...]

(Though simply including "predict.h" in "asm-primitives.cpp" doesn't work either)

Looks like this has been addressed:
* https://bitbucket.org/multicoreware/x265/commits/3d3bc732b9e738909f9e5c79caf50c9098c9c25e
* https://bitbucket.org/multicoreware/x265/commits/7da2b731de3009f45b557001e660a7cde62c6cf1

[x265_Project]

@x265_Project

What is your position about the command line synthax compared to x264 because I thought it was similar ? Should it be ? especially shortcut ?

Because during my tests "x264 2-pass vs x265 2-pass", I copy/paste my x264 command line. Problem : for x264 -p is the shortcut for --pass and for x265 it's the shortcut for --preset .
And yes, It took me some time to find out why x265 sucks so much in 2-pass ;)
Our position is that x265 syntax should mirror x264 syntax wherever possible. Thanks for the tip. I'll ask the dev team to review this.

[x265_Project]

I know it was discussed a bit earlier, but what was/is the conclusion about whether certain features (like --ctu) need to be configured differently for different resolutions? Are higher CTU sizes always a higher precision option, or is there a point of diminishing returns for the larger sizes on smaller resolutions like 480p, or was that simply a speed vs. quality decision?
64x64 CTUs allow for higher encoding efficiency, but this also increases the number of possible block sizes and shapes that will be evaluated during motion estimation. Your results will vary depending on your content, but it's easy to run a couple of comparison tests to see the cost/benefit of --ctu 64 vs. --ctu 32.
And just out of curiosity on the subject of RExt, which pieces/features need to be adjusted against the updated spec (which I assume has been released already, because it said it was supposed to be July and at least FFmpeg added support for decoding of non-4:2:0 content around the same time) so that the warning about non-compliancy is no longer necessary?
It's not always easy to follow / understand how these standards bodies work. My understanding is that the range extension draft was consented on July 11th by the study group, but not yet approved and released by the ITU or MPEG. So, effectively they are approved, but they are not yet published as an updated version of the HEVC/H.265 spec. When MPEG's HEVC standards are fully approved they show up here... http://mpeg.chiariglione.org/standards/mpeg-h/high-efficiency-video-coding ... and the matching ITU H.265 standards show up here... http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=11885. The new HM 16 reference encoder was just tagged, and it merges HM 15.0 with RExt 8.1, and so there is no turning back now. We've been keeping up with the RExt standards and supporting them for many months. If you are running tests, please let us know if you see any issues (for example, x265 encodes that don't decode perfectly with the latest HM decoder).

[xkinn123]

I felt my usual settings got slower...
what happened? Did you change your algorithm, x265_Project?

[LoRd_MuldeR]

I felt my usual settings got slower...
what happened? Did you change your algorithm, x265_Project?

This project is constantly evolving, so you cannot expect that your "usual settings" will always produce the same output or always run at the same speed.

It's probably the best to stick with the Preset system, since the Presets are updated/adjusted as needed during the development...

[xkinn123]

This project is constantly evolving, so you cannot expect that your "usual settings" will always produce the same output or always run at the same speed.

It's probably the best to stick with the Preset system, since the Presets are updated/adjusted as needed during the development...
Thank you.

Do you have any documentation explain about Psy-RDO and how it works?
I'm curious.

[LigH]

It has been documented rather briefly a lot of times; unfortunately, the topic seems to be complex enough to be explainable only to people who studied digital signal processing... You should have understood at least what "quantization" means, and how transformations to a frequency spectrum work. Then you will possibly learn that the quantization is altered based on the relation between lower and higher frequency parts of the spectrum, and the total amplitude in each "macroblock" or Coding Unit... I guess.

Briefly said: If there is enough contrast, then it doesn't need to be very exact, to spare a bit more for areas with little contrast, where a lack of precision would become more obvious.

[x265_Project]

I felt my usual settings got slower...
what happened? Did you change your algorithm, x265_Project?
We improve our algorithms all the time, but for most people with most settings performance should be getting faster. It would help if you could share your command-line syntax and your results (ideally, the summary data that is logged in a CSV file).

[x265_Project]

Heads up!! We're going to adjust Psy-RD and Psy-RDOQ strength scaling to provide a more typical range of values. Although both of these algorithms are off by default, if you are using them, you will need to adjust your strength values going forward.

Steve has pushed some (what we hope to be) final tunings of the two new psycho-visual optimization features. The features are still disabled by default, but the recommended values are now 1.0 for both.

http://x265.readthedocs.org/en/stable/cli.html#psycho-visual-options

Please try them out.

The stable branch has been merged with default in preparation of a 1.3 tag, which should happen early this week.

[raine]

Are we going to get detailed documentation for presets? In the old PDF version, I remember it was nicely tabulated.

@Darius510 I can suggest lower TDP processors (<=45W) when you buy a CPU next time. My Haswell never caused any problems at full loads even with the default Intel fan and questionable out-of-the-box thermal paste. Also saves energy. And here's a conjecture: using a 45W-TDP 2.7 GHz CPU could be faster than using a 88W-TDP 4 GHz with limited threads+AVX/AVX2 disabled (and it's is definitely much less noisy and energy-saving).

[NikosD]

The problem is that I bought Core i7-4790 with a TDP of 84W and the actual power is 100W during stress tests and close to 84W during x265 encoding.

We can't trust Intel based on TDP to predict thermal behavior.

[x265_Project]

Are we going to get detailed documentation for presets? In the old PDF version, I remember it was nicely tabulated.
Presets are documented here...
http://x265.readthedocs.org/en/default/presets.html
However, it is easier to read the presets table here...
https://bitbucket.org/multicoreware/x265/src/default/doc/reST/presets.rst

[a5180007]

@x265_Project, before 1.3 tagging, it would be better to change the --help (1.2+555-866f213 below) :

--psy-rd <0..2.0> Strength of psycho-visual rate distortion optimization, 0 to disable. Default 0.000000
--psy-rdoq <0..2.0> Strength of psycho-visual optimization in quantization, 0 to disable. Default 0.000000

[LoRd_MuldeR]

@x265_Project, before 1.3 tagging, it would be better to change the --help (1.2+555-866f213 below) :

--psy-rd <0..2.0> Strength of psycho-visual rate distortion optimization, 0 to disable. Default 0.000000
--psy-rdoq <0..2.0> Strength of psycho-visual optimization in quantization, 0 to disable. Default 0.000000

What exactly would you change?

To my understanding, the range for these options will remain 0.0 to 2.0. They only have been tuned so that a value of 1.0 should give visually pleasing results now. And they're still disabled by default.