x265 HEVC Encoder

[a5180007]

Any news about the artefact mentionned by Ligh (piece of umbrella shown 7 frames earlier)? Is this a bug?

http://i.imgur.com/xuqj1oq.png
Animated PNG 3.58 MB

[1.3+219] x265 --b-adapt 0 --bframes 16 park_joy_1080p.y4m -o pj.hevc

Although --b-apdapt 0 --bframes 16 cannot be considered a standard encoding, x264 does not show anything like this with the same parameters.
EDIT : this might explain the amount of 'ghosting' in x265
In this excerpt, the same artefact is visible for the upper umbrella, but also for the tip of the right wing of the central man, the knee of the leftmost woman...

[lotusgg]

how to hi444p on x265?

[foxyshadis]

how to hi444p on x265?

A lot slower than 420, but otherwise working fine.

[lotusgg]

A lot slower than 420, but otherwise working fine.

Speed is no much problem.
Btw, can I upsample 4:2:0 to 4:4:4?

[LigH]

Of course you can. But it won't improve quality afterwards, once it had chroma subsampling 4:2:0. It will only decrease compressibility.

[LigH]

Another week gone, therefore: x265 1.3+240-1c172c1822e4 (https://www.mediafire.com/download/gfe2noicoaj3h2g/x265_1.3+240-1c172c1822e4.7z)

[Atak_Snajpera]

Which one looks better for you? (--rd 4 --psy-rd 1.0 --psy-rdoq 1.0 --aq-mode 1/2 --aq-strength 2 )

Sample 1 (https://mega.co.nz/#!oQEjES4Q!Wu--TwRUSm4J9L-BOIRgWzLRHCxpspnqO6wH7FG8HHk)
Sample 2 (https://mega.co.nz/#!cEkxGRia!AgbeGp6DnXrIBR2czBg7Sj8WV6U1zRN9ZIrrNm-D3o0)

[sneaker_ger]

From awful laptop display: 1 has less banding/flat blocks.

[Gravitator]

Which one looks better for you?
A! Why such a big difference?

[Atak_Snajpera]

It looks like --aq-mode 2 sucks alot. No idea why devs decided to use mode 2 as default.

[LigH]

So it seems that AQ mode 2 is currently worse in x265; but may it possibly be based on the differences between HEVC and AVC in general (so you can't take it over from x264 so easily), or may it rather just be a mistake in the specific implementation in x265? ... Do you get a similar relation with x264 and the same clip?

[a5180007]

Already mentioned months ago http://forum.doom9.org/showthread.php?p=1687406#post1687406. aq=2 increases ssim.

[ErazorTT]

Why is there no way to change the qcomp? Is this by purpose? I see that in the source code it does exist.. :confused:

[sneaker_ger]

In light of the recent aq-mode discussions I decided to try out some variations with the lighthouse sample (http://217.160.126.132/lighthouse_lossless.mp4).

The biggest problem: there are so many possible combinations - I cannot test them all.

Binaries: 1.3+330 ICL from Chromashift

All use --preset slow, 2pass and --bitrate 4000. The bitrate was not always hit but banding isn't usually affected by slight bitrate variations anyways and I was too lazy to fix the problems. The rest of the settings can be deducted from the file names:
aq1/2 == --aq-mode 1/2
rd1 == --psy-rd 1.0
rdoq1 == --psy-rdoq 1.0
str2 == --aq-strength 2.0

Output files, file sizes, screenshot package, logs: https://mega.co.nz/#F!AgdRCSjC!Dr-4__tm9xMTvUdL4I8-Zw

Source screenshot:
http://abload.de/img/290_orgqtsuz.png

8 bit:

http://abload.de/img/aq2_8bit0000002rdrz.png
http://abload.de/img/aq1_8bit000000ixcoq.png
http://abload.de/img/aq2_str2_8bit000000w0jds.png
http://abload.de/img/aq1_str2_8bit000000q2fkm.png
http://abload.de/img/aq2_rd1_8bit000000t5i70.png
http://abload.de/img/aq1_rd1_8bit0000008lizc.png
http://abload.de/img/aq2_rd1_str2_8bit0000h3j1n.png
http://abload.de/img/aq1_rd1_str2_8bit0000vofjw.png
http://abload.de/img/aq2_rd1_rdoq1_8bit0004sfdh.png
http://abload.de/img/aq1_rd1_rdoq1_8bit00060dx3.png
http://abload.de/img/aq2_rd1_rdoq1_str2_8bw6fxx.png
http://abload.de/img/aq1_rd1_rdoq1_str2_8boyeh0.png

10 bit:

http://abload.de/img/aq2_10bit0000009cdzl.png
http://abload.de/img/aq1_10bit000000rdfi2.png
http://abload.de/img/aq2_str2_10bit0000009ejnc.png
http://abload.de/img/aq1_str2_10bit000000fmf8i.png
http://abload.de/img/aq2_rd1_10bit0000003kfef.png
http://abload.de/img/aq1_rd1_10bit0000007viu7.png
http://abload.de/img/aq2_rd1_str2_10bit000y3kde.png
http://abload.de/img/aq1_rd1_str2_10bit0001ucq8.png
http://abload.de/img/aq2_rd1_rdoq1_10bit00dqdko.png
http://abload.de/img/aq1_rd1_rdoq1_10bit00jvdoc.png
http://abload.de/img/aq2_rd1_rdoq1_str2_102vefx.png
http://abload.de/img/aq1_rd1_rdoq1_str2_106wefk.png

[xxxxx]

my aq mode/strenght related tests (http://forum.videohelp.com/threads/367339-HEVC-test-samples)

[plonk420]

i've noticed some blocking @ 55 seconds of this clip as i work my way lower in crf-values

x265 settings: veryslow, 4 bframes, rd mode 4

x265 (https://mega.co.nz/#!CFoggJxS!BhQbZlu8zEwdMlkMMRJbln1O7B3Ve2tz7psQTqU1ydk) - image (http://i3.minus.com/i6tyfSWni4jBL.png) (edit: i just noticed it doesn't look as bad in MPC as it does in VLC as i was screenshotting)

x264 (https://mega.co.nz/#!OVh2nCTJ!EKGtw5tn_i1nsFWFJ2iMp-yFlVb4BO42gZsEWMJvD8g)

also, is there an equivalent of x264's --deblock -3:-3 for x265?

[LigH]

Two more builds as "last week's results". There is a lot more parallelization going on. The last version (1.3+362) has different compiler warnings by GCC, depending on the variant...

x265 1.3+331-b6d49505b179 (https://www.mediafire.com/download/su08d4em8l2jd86/x265_1.3+331-b6d49505b179.7z)
x265 1.3+362-4b7c473c3ef4 (https://www.mediafire.com/download/zk9dmh9gc0v3nu7/x265_1.3+362-4b7c473c3ef4.7z)

[BlockABoots]

I think it is time to take a look at settings used in presets. I've tested those presets with first 10 min of Drive movie (http://www.imdb.com/title/tt0780504/?ref_=nv_sr_1).
Frame size after cropping: 1920x800
My CPU: Intel Xeon E5-2690 ( 8C / 16T )
Common command line: --crf 20 --min-keyint 24 --keyint 240
NOTE: In order to achieve max cpu usage and encoding speed in x265 I was encoding two 1 min chunks at the same time. (10 chunks total)

http://i.imgur.com/rV4FQGi.png

As you can see difference in encoding speed is marginal between superfast and fast. Also there is huge drop from fast to medium (almost 2x)

and for comparison ...

http://i.imgur.com/XAFTyUj.png

Does encoding at faster speeds effect the quality or does it just effect the file size of the output file?

[Sharc]

Does encoding at faster speeds effect the quality or does it just effect the file size of the output file?
Basically, encoding at faster speeds means:
- reducing the quality for the same file size
- increasing the file size for the same quality

But keep in mind that same crf does not mean same quality.

[kotuwa]

Zones

Is there any switch or method in x265 to specify zones like --zones in x264 ?

!?

[huhn]

rule 8...

I can't find it here: http://x265.readthedocs.org/en/latest/cli.html

so I guess it is not implemented.
simple work around:
just cut the parts with a program like avisynth trim() and put them together with a muxer like mmg after encoding each part with the desired settings.

[LigH]

Another "last week's result": x265 1.3+378-f26e81eb555a (https://www.mediafire.com/download/jbaicgklf62q8ax/x265_1.3+378-f26e81eb555a.7z)

[agressiv]

How are people handling banding? x265 seems to struggle with this more than just about anything.

Without ballooning up bitrates or using 10-bit, what are you guys using that isn't the following:

--rd 4 --psy-rd 1.0 --psy-rdoq 1.0 --aq-mode 1 --aq-strength 2

If I don't use these settings (mainly --aq-mode 1 and --aq-strength 2) - banding is atrocious.

However, in some scenes, your bitrate can be greater than a comparable x264 encode, which handles banding much better it seems.

Here is a 30 second original sample (from blu-ray) I'm using:

https://mega.co.nz/#!2Aw02IbJ!zD0w6nQ4cQM5brbteu2W7QstS8uTmCRNI1Gwnz1mE3M
(https://mega.co.nz/#!2Aw02IbJ!zD0w6nQ4cQM5brbteu2W7QstS8uTmCRNI1Gwnz1mE3M)

[xkinn123]

How are people handling banding? x265 seems to struggle with this more than just about anything.

Without ballooning up bitrates or using 10-bit, what are you guys using that isn't the following:



If I don't use these settings (mainly --aq-mode 1 and --aq-strength 2) - banding is atrocious.

However, in some scenes, your bitrate can be greater than a comparable x264 encode, which handles banding much better it seems.

Here is a 30 second original sample (from blu-ray) I'm using:

https://mega.co.nz/#!2Aw02IbJ!zD0w6nQ4cQM5brbteu2W7QstS8uTmCRNI1Gwnz1mE3M
(https://mega.co.nz/#!2Aw02IbJ!zD0w6nQ4cQM5brbteu2W7QstS8uTmCRNI1Gwnz1mE3M)

have you tested it on anime?
It's the best way for me to check the banding problem.

[schweinsz]

Does encoding at faster speeds effect the quality or does it just effect the file size of the output file?
Could you list the speed of the slow configuration of the x265?

[xooyoozoo]

If I don't use these settings (mainly --aq-mode 1 and --aq-strength 2) - banding is atrocious.

However, in some scenes, your bitrate can be greater than a comparable x264 encode, which handles banding much better it seems.

Here is a 30 second original sample (from blu-ray) I'm using:

https://mega.co.nz/#!2Aw02IbJ!zD0w6nQ4cQM5brbteu2W7QstS8uTmCRNI1Gwnz1mE3M
(https://mega.co.nz/#!2Aw02IbJ!zD0w6nQ4cQM5brbteu2W7QstS8uTmCRNI1Gwnz1mE3M)

Testing that clip with x264, I think aq-mode 2 also looks worse than aq-mode 1, but of course it's not that big a deal because x264 seems to be naturally better with banding. Still, I can only assume x264 made the right decision all those years ago when they made AQ1 the default.

Increasing the aq strength in x265 made the banding much better, but it comes at the expense of detailed regions. It also feels "wrong" to do this, because the bands shouldn't need to leech precious bits from other places, as just a little bit of random noise and motion would go a long way.

Psy-rdo/rdoq doesn't seem to do much to alleviate the problem either. :/

[LigH]

Another week of patches: x265 1.3+619-7eab67ffff81 (https://www.mediafire.com/download/d255rajml4k5amo/x265_1.3+619-7eab67ffff81.7z)

[nuon]

Here a size comparison what size reduction you get when adding CPU Cycles by choosing slower presets.
Fullhd game sequence of Borderlands2, 33sec duration, quantisation strenght 28.

[LigH]

Barely interesting: The same CRF for different presets is not guaranteed to reduce the size with each step, and even more not made with this only purpose (it may be a probable side effect at most). Notice a slight exception for preset superfast, and an equal value between presets veryfast and faster.

[BadFrame]

Just tried buiding x265 and testing it for the first time in quite a while, have to say I'm impressed with the improvements both in speed and quality from when I last tried it (admittedly quite some time ago), kudos to the x265 developers !

Also did a test of building it using PGO (profile-guided optimization) and got a 7-8% performance increase compared to the standard release build, indicating that there is likely a lot more performance to be had when more c code is converted to hand-written optimized assembly.

[mchartier]

Just tried buiding x265 and testing it for the first time in quite a while, have to say I'm impressed with the improvements both in speed and quality from when I last tried it (admittedly quite some time ago), kudos to the x265 developers !

Also did a test of building it using PGO (profile-guided optimization) and got a 7-8% performance increase compared to the standard release build, indicating that there is likely a lot more performance to be had when more c code is converted to hand-written optimized assembly.

Please post this PGO build :)

[x265_Project]

We are doing some fairly major code refactoring, improving parallelization and performance. Early results are very encouraging. It will take another couple of weeks to complete the current phase of development, which started several months ago. In the meantime, it is probably a bit too early to spend too much energy on other compiler optimizations, as things are still changing fast. We'll share more details when we hit the next milestone.

Tom

[x265_Project]

Just tried buiding x265 and testing it for the first time in quite a while, have to say I'm impressed with the improvements both in speed and quality from when I last tried it (admittedly quite some time ago), kudos to the x265 developers !

Also did a test of building it using PGO (profile-guided optimization) and got a 7-8% performance increase compared to the standard release build, indicating that there is likely a lot more performance to be had when more c code is converted to hand-written optimized assembly.
With the caveats above... we really appreciate feedback like this. Can you share more details on your build/compiler environment and how you created your PGO build?

Thanks!
Tom

[BadFrame]

With the caveats above... we really appreciate feedback like this. Can you share more details on your build/compiler environment and how you created your PGO build?

Of course, let's see (from memory here), I configured with 'shared' disabled, I don't think this affects PGO in any major way but I was going to try building with LTO aswell (Link Time Optimization) and it works better on a single static binary.

Then I did a quick and dirty after doing the normal release build, and just edited CMakeCache.txt to change the following to:

CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -march=native -DNDEBUG -fprofile-generate -fprofile-dir=/mnt/ram

CMAKE_C_FLAGS_RELEASE:STRING=-O3 -march=native -DNDEBUG -fprofile-generate -fprofile-dir=/mnt/ram

CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING=-O3 -march=native -DNDEBUG -fprofile-generate -fprofile-dir=/mnt/ram

did a make clean and built the binary to be used for profile gathering, this binary runs slower than a usual binary since it gathers a lot of runtime information when running, I encoded a small clip using --preset slower --crf 10 IIRC, when it was done encoding, the binary automatically dumps the runtime data in the path chosen (in my case /mnt/ram)

then another make clean, and another quick and dirty edit of CMakeCache.txt to change the following to:

CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -march=native -DNDEBUG -fprofile-use -fprofile-correction -fprofile-dir=/mnt/ram

CMAKE_C_FLAGS_RELEASE:STRING=-O3 -march=native -DNDEBUG -fprofile-use -fprofile-correction -fprofile-dir=/mnt/ram

CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING=-O3 -march=native -DNDEBUG -fprofile-use -fprofile-correction -fprofile-dir=/mnt/ram

followed by 'make' to generate the final binary with optimization improvements made based upon the runtime data gathered (no more guesswork for the compiler when it comes to loop unrolling, branch prediction etc).

after that I did a benchmark against the 'normal' release build (-O3 -DNDEBUG IIRC) and the PGO build was 7-8% faster.

Oh, and this was on Arch Linux 64-bit, using GCC 4.9 toolchain on a core i5.

And thanks again for the great work you guys are doing on x265!

[BadFrame]

Please post this PGO build :)

Most people here seem to be running Windows, I'm on Linux so I don't know if there is any point to posting a 64-bit Linux binary (typically if you run Linux you can build it yourself) ?

If you are using Windows I know that Visual Studio has PGO, although IIRC it's disabled in the (free) express version.

[xxxxx]

We are doing some fairly major code refactoring, improving parallelization and performance. Early results are very encouraging. It will take another couple of weeks to complete the current phase of development, which started several months ago. In the meantime, it is probably a bit too early to spend too much energy on other compiler optimizations, as things are still changing fast. We'll share more details when we hit the next milestone.

Tom

Are you working on the banding issue too?

[LigH]

Another "weekly": x265 1.3+788-3a8f6f685436 (https://www.mediafire.com/download/l04ia05amurzn97/x265_1.3+788-3a8f6f685436.7z)

[foxyshadis]

New build v1.3+865 (https://dl.dropboxusercontent.com/u/54412753/doom9/x265-1.3%2B865.7z) with new option --deblock that works just like x264's. Now you can test --deblock -1 or -2 and see if that improves film noise. Now's your chance to play with it and see if any bugs are present before the final release. Should be pretty stable, lots of bugfixes have gone into it recently and 1.4 appears to be right around the corner! Speed and quality have both improved since 1.3.

Built with VC12, x64 only, be sure to get the 2013 runtime (http://www.microsoft.com/en-us/download/details.aspx?id=40784) if you don't already have it.

Edit: Stealth update to 1.3+865 with more little bug fixes.

[upyzl]

thx @BadFrame for sharing

for whom want to test PGO vs Normal on Windows (only 64bit, 8bpp):
https://mega.co.nz/#!Z9NDQJrI!yRTwD2BWxA8pA8McfS616f1USPnKtViIoBf3dzQc2bU

compiled by gcc 4.8.3 (msys)
without -march change (for user compatibility)
use --crf 15 --preset slow on a short clip for PGO

I think improve configure to support PGO compile should be better, like x264


BTW, I try to do it by using VS2013pro by following http://msdn.microsoft.com/en-us/library/xct6db7f.aspx "Building an Application with PGO" - Building with PGO at the Command Line (add /GL to CXX_FLAG & C_FLAG and add /ltcg:pgi to EXE_LINKER_FLAG)
but the instrumented exe cannot do encoding (of course no .pdc file created)...

[easyfab]

I try on my I2600K

compiled by gcc 4.9.1 (msys)
source 800*480 600 frames

standard build without -march : 26.5 fps
with -march=corei7-avx -mtune=corei7-avx : 26.8 fps
with -march=corei7-avx -mtune=corei7-avx + PGO : 27.5 fps

~3% better with PGO vs -march alone

[BadFrame]

I think improve configure to support PGO compile should be better, like x264

Yes, it's certainly simpler as it is automated there, just 'make fprofiled <video to be used while profiling>' and wait.

That said I don't know if it affects x264 performance in any real way these days since basically every performance hotspot in x264 has been converted in to highly optimised hand-tuned assembly (which of course the compiler can't improve, PGO or not).


BTW, I try to do it by using VS2013pro by following http://msdn.microsoft.com/en-us/library/xct6db7f.aspx "Building an Application with PGO" - Building with PGO at the Command Line (add /GL to CXX_FLAG & C_FLAG and add /ltcg:pgi to EXE_LINKER_FLAG)
but the instrumented exe cannot do encoding (of course no .pdc file created)...

Sorry, I haven't used VS for ages so I can't really help you there :/ , I just know that it has PGO support (sometimes it's called FDO 'feedback driven optimization' but it means the same thing as PGO 'profile guided optimization'), also the Intel Compiler has PGO support, Clang/LLVM however does not.

[BadFrame]

s
standard build without -march : 26.5 fps
with -march=corei7-avx -mtune=corei7-avx : 26.8 fps
with -march=corei7-avx -mtune=corei7-avx + PGO : 27.5 fps


Just a quick note, -march sets -mtune, so you can drop -mtune from the options when you use -march.

-mtune is meant to be used if you want to make binaries which will work everywhere (well, within the cpu architecture as in 32-bit or 64-bit) but be 'tuned' for a particular cpu architecture, -march however will directly target a cpu architecture and make use of it's cpu specific extensions (sse1-4, avx, etc) which will make the resulting binary incompatible with cpu's that doesn't support those extensions.

[easyfab]

To make PGO building a little more easier than editing CMakeCache.txt and as I'm not a cmake expert I created 2 folders : 1 for -fprofile-generate and 1 for -fprofile-use
and add
SET(CMAKE_C_FLAGS "-O3 -march=corei7-avx -mtune=corei7-avx -DNDEBUG -fprofile-generate -fprofile-dir=xxx " CACHE STRING "c flags" )
SET(CMAKE_CXX_FLAGS "-O3 -march=corei7-avx -mtune=corei7-avx -DNDEBUG -fprofile-generate -fprofile-dir=xxx" CACHE STRING "c++ flags")
... in toolchain folder1 and
SET(CMAKE_C_FLAGS "-O3 -march=corei7-avx -mtune=corei7-avx -DNDEBUG -fprofile-use -fprofile-correction -fprofile-dir=xxx " CACHE STRING "c flags" )
... in toolchain folder2 than a little script:

cd folder1
make-Makefiles.sh && make
x265 ....
cd folder2
make-Makefiles.sh && make

[easyfab]

Just a quick note, -march sets -mtune, so you can drop -mtune from the options when you use -march.

-mtune is meant to be used if you want to make binaries which will work everywhere (well, within the cpu architecture as in 32-bit or 64-bit) but be 'tuned' for a particular cpu architecture, -march however will directly target a cpu architecture and make use of it's cpu specific extensions (sse1-4, avx, etc) which will make the resulting binary incompatible with cpu's that doesn't support those extensions.

Thanks for the note, I will remove -mtune in the future

[upyzl]

Sorry, I haven't used VS for ages so I can't really help you there :/ , I just know that it has PGO support (sometimes it's called FDO 'feedback driven optimization' but it means the same thing as PGO 'profile guided optimization'), also the Intel Compiler has PGO support, Clang/LLVM however does not.
ah... for I did not say clearly, I just show my (should be wrong)way of doing, not your fault

and thx for the info :cool:

[plonk420]

New build v1.3+865 (https://dl.dropboxusercontent.com/u/54412753/x265-1.3%2B865.7z) with new option --deblock that works just like x264's. Now you can test --deblock -1 or -2 and see if that improves film noise. Now's your chance to play with it and see if any bugs are present before the final release. Should be pretty stable, lots of bugfixes have gone into it recently and 1.4 appears to be right around the corner! Speed and quality have both improved since 1.3.
*snip*

thanks! will have to rerip The Game after my current round of encodes to test this out, but very very happy to see this feature! :D

[Kurtnoise]

x265 1.4 is a regularly scheduled release, mostly focused on performance
enhancements. There was a large refactor of the analysis code that
exposed further parallelism without sacraficing any compression
efficiency. In general, 1.4 should have slightly better compression
efficiency than 1.3 for the same encodes.

The refactors also generally lowered the memory requirements and made
the faster presets more compute efficient.

The two most important new features are --pmode (parallel mode decision)
and --pme (parallel motion estimation).

= --pmode : param.bDistributeModeAnalysis =

This feature will distribute mode analysis for each CU. The more modes
that must be analyzed, the more effective this feature becomes. So the
slow preset that enables rectangular prediction modes benefits from
pmode more than medium preset, and the slower modes which use RD level
6 benefit from pmode even more since they enable AMP predictions and
evaluate the rate distortion cost of each mode.

The output of --pmode encodes should have slightly better compression
than those with it disabled, since certain early outs are impossible
with --pmode and thus all modes are measured naievely.

= --pme : param.bDistributeMotionEstimation =

This feature will distribute the motion estimations for each CU that has
more than 2 references. Its effectiveness is proportional to the number
of references, but this feature can often be a net performance loss as
the overhead of involving other CPU cores is often more expensive than
the parallelism benefit.

The output of the encode is completely unaffected by --pme.

Both --pme and --pmode are only useful when x265 is otherwise unable to
fully saturate the CPU cores, and both can also at times result in lower
performance on multi-socket machines (depending on the situation) since
we are not yet keeping work localized to neighbor CPUs.

= Also in 1.4 =

As a result of the refactor work, none of the original HM classes or
source files remain in x265.

Temporal motion vector predictions (previously hard-coded to always be
enabled) are now runtime selectable (param.bEnableTemporalMvp) but still
default to being enabled in all presets.

Frame based SAO analysis was removed (frame based SAO signaling did not
make it into the final HEVC spec), and --sao-lcu-bounds=<0|1> was
renamed to --[no-]sao-non-deblock (param.bSaoNonDeblocked)

Some inconsistencies in the analysis logic were fixed. --amp is now
respected in RD levels 2, 3, and 4 (previously only in 5 and 6).
--b-intra is now respected in all RD levels. --fast-cbf, which has only
ever effective at RD levels 5 and 6, is no longer enabled uselessly in
the fastest presets.

--weightb is now enabled by default at presets slower, veryslow, and
placebo.

--cu-lossless was changed to only attempt a lossless encode of the best
lossy encode method. This made --cu-lossless a much less expensive
encode option to have enabled, and hopefully made the feature more
robust and maintainable.

The upper threshold for --psy-rdoq was raised to 50 (from 10) since the
higher values were found to be beneficial for sources with high
frequency noise (film grain).

The default thread pool size logic was updated to account for the
addition of --pmode and --pme (if WPP is disabled but --pmode or --pme
are enabled, a thread pool is still allocated).

In 1.4 there also appeared an incomplete analysis re-use feature. This
will be completed and further improved in the coming weeks.

......

[foxyshadis]

Scheduling 1.4 for Halloween was awesome. :D

https://dl.dropboxusercontent.com/u/54412753/doom9/x265-jack.png

[filler56789]

build 1.4+5-eebb372eec89 @

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2354182#post2354182

[a5180007]

Hi all,

The upper threshold for --psy-rdoq was raised to 50 (from 10)

So what is the recommended --psy-rdoq value for general purpose encoding, is it still 1.0 ?