x265 HEVC Encoder

[x265.cc]

Someone must have stolen the private key or hijacked the server. Ouch. Good idea to wait until the situation is cleared up.

I've revoked it my self. As you can see i switched from 4096 bit RSA to 384 bit ECC (~7680 bit RSA) certificate.

Actually i was a bit slow with replacing it on my nginx, so you saw the "revoked" message.

Sorry for the inconvenience

It requires a rather strong HTTPS cipher

Yep, thats true. If somebody uses an outdated browser* he cant access my site(s).


*Chrome =< 29 / Firefox =< 26 / IE =< 10 / Opera =< 17 / Safari =< 6

[MeteorRain]

Duh I know! it is very obvious. I asked about a certain site that automatically compile and upload new versions (like some x264 ones) rather than looking in a forum post to see one post out of hundreds that has a downloadable binaries. :(

I compile modified versions, every couple days.

You can find patched version in my signature.
And you can find the patches on my bitbucket repo.

(And since I'm using the latest version of Opera 12, the ssl cipher is still RSA based.)

[need4speed]

Hi,
sorry for jumping in and hoping this is the right place to ask: been messing around with HEVC since awhile and using staxrip since dont have much time to learn all tricks for command line (sorry...).
I'm mainly using HEVC to recode and store tv series, from different sources but the idea is to spare some disk space.
Basically I tend to recode in 720p, keeping quality as high as possible.
HEVC is working great, and staxrip is a big help being very intuitive.
Question now would be:
At the moment staxrip is still relying on HEVC version 1.7.something, and reading around here there are several newer releases, 1.8.etc
So how can I update HEVC (x265) in staxrip?
As for codec there's a folder with the executable only, but in the7z files downloaded from here (thanks a ton for the hard work btw) there are also some dll's file I'm not quite sure with to do with.
Launching Staxrip the task log reports the 1.8.whatever version as expected (swapping exe file in the proper folder) but I'm quite puzzled sinc haven't done anything with DLL's.
ANY help welcome and thanks in advance!
A.
PS Aplogies for my english, hope si intelligible

[LigH]

As long as there are no fundamental changes in the command line options set, you may indeed just replace the x265.exe any GUI would use.

Which replacement to use, has been asked in another forum recently, so I will quote here the verbose reply:

The x265_ml.exe is the "static multilib build" which does not need any additional DLLs. If you want to reduce the number of files and only encode, use this as your only EXE file with any name you like (most probably x265.exe).

The other files are only included for completeness' sake; e.g. for the case that someone wants to reduce the size of a release archive by omitting some functionality (include only the EXE for one bitdepth per default) and offering additional bitdepths as optional downloadable DLLs, or wants to write a different application which would use the DLLs as pluggable encoders.

x265_ml.exe = static multilib build, includes 8 + 10 + 12 bit depth encoder (possibly the only one most people need)
x265_main.exe = only 8 bit depth encoder included; may require x265_main10.dll or x265_main12.dll if used with -D 10 or -D 12
x265_main10.exe = only 10 bit depth encoder included; may require x265_main.dll or x265_main12.dll if used with -D 8 or -D 12
x265_main12.exe = only 12 bit depth encoder included; may require x265_main.dll or x265_main10.dll if used with -D 8 or -D 10


tl;dr: Use x265_ml.exe (no additional DLLs required) as your new x265.exe (preferably the 64-bit version if applicable).

[need4speed]

As long as there are no fundamental changes in the command line options set, you may indeed just replace the x265.exe any GUI would use.

Which replacement to use, has been asked in another forum recently, so I will quote here the verbose reply:



tl;dr: Use x265_ml.exe (no additional DLLs required) as your new x265.exe (preferably the 64-bit version if applicable).

Got it.
Thanks for the quick reply.
Already done that, although had to rename the exe file (64bit folder).
Would love to use handbrake or CL on my main linux system but Handbrake has no available triggers for advanced settings in HEVC and have no idea how to use CL on linux (and how to install/compile codec itself).
Any tutorial or howto available for linux systems?
Basically trying to get rid of windows once and for all!

many thanks again!
BTW; there's no 12bit option available (staxrip) with newer exe version. 8 or 10 only in deph filed. Or am I doing something wrong?

[LigH]

StaxRip may have restricted its GUI to offer only 8 or 10 bit, because 12 bit precision should have little relevance in "amateur" cases and used to be "experimental" for a longer time.

The x265 project has a compiling guide on BitBucket (https://bitbucket.org/multicoreware/x265) which is also their Hg (Mercurial - a git variant) server. In general, "clone" the sources, change into the subdirectory of the "build" directory which matches your environment, and use the shell scripts there. I customized these a bit for my workflow, but in general, they are pure source builds without additional patches.

To use x265 on the command line, you may better use a feature-rich ffmpeg build including libx265, or you would have to pipe YUV4MPEG (or raw YUV, in conjunction with more CLI parameters) into x265 as separate encoder, it doesn't support any other input yet. Maybe try Selur's "Hybrid" converter, it is multi-platform for the portable features.

[stax76]

@need4speed
@LigH

Next StaxRip release will have the 12 bit option and a few other x265 improvements.

[RBF]

BIG TEST VP9 / x264 / x265 (http://blog.cherepovets.ru/serovds/2015/10/27/bigtest_vp9_264_265/)

[~ VEGETA ~]

what does Yuuki mod add to the encoder?

plus,

x265_ml.exe = static multilib build, includes 8 + 10 + 12 bit depth encoder (possibly the only one most people need)

where to download this version? and if it includes 8,10, and 12 bit encoding in the same exe... what is the command line to use each of them?

[stax76]

what does Yuuki mod add to the encoder?

plus,



where to download this version? and if it includes 8,10, and 12 bit encoding in the same exe... what is the command line to use each of them?

LigH posts binary links regularly, the static multilib build is called x265_ml.exe and the switch is --output-depth, -D 8|10|12

http://x265.readthedocs.org/en/latest/cli.html#cmdoption--output-depth

[MeteorRain]

what does Yuuki mod add to the encoder?
lavf input
mp4/mkv output muxer
--tune lp by littlepox optimized for animation
some other cosmetic stuff

[need4speed]

@need4speed
@LigH

Next StaxRip release will have the 12 bit option and a few other x265 improvements.

Good news, many thanks!
Really it's out of curiosity, 10bit seems to work ok although using some tweaks it's about 8fps which seems to be a bit slow but not such a big deal.
What is not really clear is the subpel refinement in the motion search panel. sorry, I don't mean to ask a lot of questions but the more I read about some settings the less I understand :)
A lot of different opinions and a lot of tests done but there seems to be no final word on a lot of settings. Again, have tried myself and, aside from encoding fps rate, cant really tell the difference.
In my own case it's
1) Re-encoding 1080p tv shows to 720p to save some disk space.
2) re-encoding BR tv series iso.

Thanks again for the help and the big effort!!

Btw, here's my settings for 1080p->720p tv shows

x265 [info]: HEVC encoder version 1.8+60-6563218ce342
x265 [info]: build info [Windows][GCC 5.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [warning]: Specifying a decoder level with constant rate factor rate-control requires
x265 [warning]: enabling VBV with vbv-bufsize=10000kb vbv-maxrate=10000kbps. VBV outputs are non-deterministic!
x265 [info]: Main 10 profile, Level-3.1 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(45 rows)
x265 [info]: Coding QT: max CU size, min CU size : 16 / 8
x265 [info]: Residual QT: max TU size, max depth : 16 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : umh / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 15 / 3 / 1
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 2 / 0 / 0
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 16 / 1
x265 [info]: Rate Control / qCompress : CRF-16.0 / 0.80
x265 [info]: VBV/HRD buffer / max-rate / init : 10000 / 10000 / 0.900
x265 [info]: tools: rd=3 psy-rd=0.70 rdoq=1 psy-rdoq=5.00 signhide tmvp
x265 [info]: tools: fast-intra strong-intra-smoothing deblock(tC=-1:B=-1)

[LigH]

where to download this version?

They are inside the 7-zip archives (usually recommendable version in bold green):

Weekly with a few bug fixes

x265 1.8+60-6563218ce342 (GCC 4.9.2) (https://www.mediafire.com/download/dp8nbc881q055og/x265_1.8+60-6563218ce342.GCC492.7z)
x265 1.8+60-6563218ce342 (GCC 5.2.0) (https://www.mediafire.com/download/a8y52fjyjae83po/x265_1.8+60-6563218ce342.GCC520.7z)

Listing archive: x265_1.8+60-6563218ce342.GCC520.7z

--
Path = x265_1.8+60-6563218ce342.GCC520.7z
Type = 7z
Physical Size = 3650115
Headers Size = 510
Method = LZMA2:26 LZMA:20 BCJ2
Solid = +
Blocks = 1

Date Time Attr Size Compressed Name
------------------- ----- ------------ ------------ ------------------------
2015-10-27 13:27:40 D.... 0 0 1.8+60-6563218ce342.GCC520
2015-10-27 13:27:40 D.... 0 0 1.8+60-6563218ce342.GCC520\Win32
2015-10-27 13:27:40 D.... 0 0 1.8+60-6563218ce342.GCC520\Win64
2015-10-27 12:49:50 ....A 3094229 3649605 1.8+60-6563218ce342.GCC520\Win32\libx265_main.dll
2015-10-27 12:49:50 ....A 1379541 1.8+60-6563218ce342.GCC520\Win32\libx265_main10.dll
2015-10-27 12:49:50 ....A 1378005 1.8+60-6563218ce342.GCC520\Win32\libx265_main12.dll
2015-10-27 12:49:50 ....A 3843258 1.8+60-6563218ce342.GCC520\Win32\x265_main.exe
2015-10-27 12:49:50 ....A 2132666 1.8+60-6563218ce342.GCC520\Win32\x265_main10.exe
2015-10-27 12:49:50 ....A 2131130 1.8+60-6563218ce342.GCC520\Win32\x265_main12.exe
2015-10-27 12:49:51 ....A 6291642 1.8+60-6563218ce342.GCC520\Win32\x265_ml.exe
2015-10-27 12:49:52 ....A 4703872 1.8+60-6563218ce342.GCC520\Win64\libx265_main.dll
2015-10-27 12:49:52 ....A 5388928 1.8+60-6563218ce342.GCC520\Win64\libx265_main10.dll
2015-10-27 12:49:53 ....A 5393024 1.8+60-6563218ce342.GCC520\Win64\libx265_main12.dll
2015-10-27 12:49:51 ....A 5485665 1.8+60-6563218ce342.GCC520\Win64\x265_main.exe
2015-10-27 12:49:52 ....A 6170721 1.8+60-6563218ce342.GCC520\Win64\x265_main10.exe
2015-10-27 12:49:52 ....A 6174817 1.8+60-6563218ce342.GCC520\Win64\x265_main12.exe
2015-10-27 12:49:54 ....A 15927393 1.8+60-6563218ce342.GCC520\Win64\x265_ml.exe
------------------- ----- ------------ ------------ ------------------------
2015-10-27 13:27:40 69494891 3649605 14 files, 3 folders

Sometimes I wonder ... you seem to talk about the content of my archives one day, but seem to never have looked into them the other day?! :confused:

[Rogatti]

Got it.

Any tutorial or howto available for linux systems?
Basically trying to get rid of windows once and for all!


Install X265 - 10bit
hg clone https://bitbucket.org/multicoreware/x265 x265
cd x265/build/linux/
cmake -G "Unix Makefiles" -D HIGH_BIT_DEPTH:BOOL=ON ../../source
make -j4
sudo make install

Down FFMPEG
git clone git://source.ffmpeg.org/ffmpeg.git ffmpeg


sudo apt-get install libfaac-dev libmp3lame-dev libtheora-dev libvorbis-dev libopencore-amrnb-dev libopencore-amrwb-dev libgsm1-dev zlib1g-dev libgpac-dev libx264-dev libxvidcore-dev libass-dev libfdk-aac-dev....

via synaptic## libvpx-dev - libopus-dev....

Configuring ffmpeg
$ ./configure --prefix=/usr/local --enable-gpl --enable-version3 --enable-nonfree --enable-shared --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfaac --enable-libfdk_aac --enable-libgsm --enable-libmp3lame --enable-libass --enable-libvpx --enable-libtheora --enable-libvorbis --enable-ffplay --enable-libx264 --enable-libxvid --enable-libx265 --enable-libfreetype --enable-libopus --enable-x11grab --enable-libfdk-aac
$ make -j4
$ sudo make install
$ sudo ldconfig -v
***************************
$ which ffmpeg
$ ffmpeg -encoders|grep -E "mp3|xvid|aac|gsm|amr|x264|x265|theora|vorbis"

voilà....

[need4speed]

Install X265 - 10bit
hg clone https://bitbucket.org/multicoreware/x265 x265
cd x265/build/linux/
cmake -G "Unix Makefiles" -D

voilà....
Ugh, thanks a ton!
Will try on a vm first. Not too sure I've grabbed all the steps but for sure will give it a go.
Just one point: once a newer codes version is out how can I update?
Many many thanks again.
Btw: since I'm setting up a vm to test any specific choice as for distro?

Inviato dal mio GT-N7100 utilizzando Tapatalk

[LigH]

Instead of making only the 10 bit binary, you may prefer running the build/linux/multilib.sh to have the "Holy Trinity" ;) of 8+10+12 bit encoders packed into one common libx265.a to be installed.

To stay up to date in the "default" development branch (updated more often with fixes, sporadically merged with the "stable" branch):

hg pull --cwd x265 -u -r default

from the directory where your x265 working directory is contained (possibly your '~' home).

[birdie]

BIG TEST VP9 / x264 / x265 (http://blog.cherepovets.ru/serovds/2015/10/27/bigtest_vp9_264_265/)

x264 > x264 grain > vp9 > x265 > x265-grain

From what my eyes can see. x265 is the blurriest of them all, VP9 looks decent and sometimes it produces a better picture than x264, but overall x264 is the best, especially at high bitrates.

[Jamaika]

x265 is the blurriest of them all,...
x265 can sharpen (http://forum.doom9.org/showthread.php?t=172778) but then you need to have a super fast computer.
...VP9 looks decent and sometimes it produces a better picture than x264, but overall x264 is the best, especially at high bitrates.
It's a matter of taste. VP9 isn't a preserved bitrate.

[foxyshadis]

x265 can sharpen but then you need to have a super fast computer.

Did you look at the comparison? x265 was given 5-8 times as long to run as x264, with preset veryslow. How much more do you want to slow it down?

Something is very off about x265 tune grain, in several comparisons it's significantly blurrier than the non-grain. I think more care should have been taken to select a frame that was a P frame across all encodes, although tune grain is specifically supposed to reduce the ratio between P and B frames, but it shouldn't be that much worse.

I will note that it's not as simple as x264 > x265; if you look at areas that x264 has to smooth, it does so in a very ugly fashion. The noisy sky in scene three shows that; it's very objectionable at 4k and 8k, and marginal at 16k. While x265 smooths away all of the grain, the overall effect looks better. Trying to use tune grain makes it look ugly and patchy again.

Of course, I find comparing extreme noise retention to be somewhat begging the question. It's a foregone conclusion that x264 retains more noise (and introduces more of its own), but that much noise is an undesirable artifact in itself. Much more disconcerting is the softer details wherever there's true detail. It's most obvious in parkjoy, where x265 just picks some objects to retain in fidelity (mostly trees), and some to ignore and blur out completely (the group, especially the man in the sailor hat, but some far background trees), no matter how it's tuned.

[LigH]

I will note that it's not as simple as x264 > x265; if you look at areas that x264 has to smooth, it does so in a very ugly fashion.

I compared a tight bitrate encode of a probably quite easily compressible scene in x265 (CRF 30) with the same, 2x, 3x, and even 4x the bitrate of the x265 result in x264 already quite some time ago. May have to repeat that with the current encoders...

My samples on MediaFire (https://www.mediafire.com/#ldwl20fppplbx) – compare in_to_tree_1080p50.x265-crf30.mp4 with in_to_tree_1080p50.x264_br~x265-crf30[_x?].mp4

IMHO, x265 was able to smooth out the sky quite conveniently, while x264 surprised with rather annoying blocking. I'll be curious which tuning may improve these results.

[nandaku2]

Did you look at the comparison? x265 was given 5-8 times as long to run as x264, with preset veryslow. How much more do you want to slow it down?

Something is very off about x265 tune grain, in several comparisons it's significantly blurrier than the non-grain. I think more care should have been taken to select a frame that was a P frame across all encodes, although tune grain is specifically supposed to reduce the ratio between P and B frames, but it shouldn't be that much worse.

I will note that it's not as simple as x264 > x265; if you look at areas that x264 has to smooth, it does so in a very ugly fashion. The noisy sky in scene three shows that; it's very objectionable at 4k and 8k, and marginal at 16k. While x265 smooths away all of the grain, the overall effect looks better. Trying to use tune grain makes it look ugly and patchy again.

Of course, I find comparing extreme noise retention to be somewhat begging the question. It's a foregone conclusion that x264 retains more noise (and introduces more of its own), but that much noise is an undesirable artifact in itself. Much more disconcerting is the softer details wherever there's true detail. It's most obvious in parkjoy, where x265 just picks some objects to retain in fidelity (mostly trees), and some to ignore and blur out completely (the group, especially the man in the sailor hat, but some far background trees), no matter how it's tuned.

The comparisons are interesting; an English webpage would be helpful.
The expectations from tune grain are very different from whats its designed to do. tune grain is not designed to retain detail, tune grain is not designed to give a sharper image. x265's tune grain (which was initially ported from x264, but then modified substantially), is designed to work on sources with film grain, and aims at preserving some of the grain as uniformly as possible through the sequence for all slicetypes. Using it on fairly clean sources like parkjoy and crowdrun is unwarranted.

[foxyshadis]

The comparisons are interesting; an English webpage would be helpful.
The expectations from tune grain are very different from whats its designed to do. tune grain is not designed to retain detail, tune grain is not designed to give a sharper image. x265's tune grain (which was initially ported from x264, but then modified substantially), is designed to work on sources with film grain, and aims at preserving some of the grain as uniformly as possible through the sequence for all slicetypes. Using it on fairly clean sources like parkjoy and crowdrun is unwarranted.

My expectation for tune grain is that if there isn't any grain, it won't lose any detail, within reason. Indeed, it seems to work exactly that way in parkjoy; the exact image is different but the sharpness is identical between default and tune grain. (Even if the group's detail loss is staggering either way.)

It just seems like tune grain leads to unnecessarily soft detail everywhere in the other encodes, even though it doesn't seem to contribute to additional detail. My guess is that with tune grain the sky is just sucking up all the bits in both sequences, leaving the details in the rest of the frame starved; the sky in each is very noisy. In quite a few movies shot on cheap film stock, the sky is where the worst of the grain is by far, while also being the least interesting part of the frame. I guess that puts you in a hard spot if you want to keep grain generally without wasting so much of your bit budget on the sky (and yet not stealing so much from it that it creates banding, either).

[Jamaika]

Of course, I find comparing extreme noise retention to be somewhat begging the question. It's a foregone conclusion that x264 retains more noise (and introduces more of its own), but that much noise is an undesirable artifact in itself. Much more disconcerting is the softer details wherever there's true detail. It's most obvious in parkjoy, where x265 just picks some objects to retain in fidelity (mostly trees), and some to ignore and blur out completely (the group, especially the man in the sailor hat, but some far background trees), no matter how it's tuned.
Test extreme noise retention Jamaika
https://www.sendspace.com/filegroup/aFL0OnfrO01atCMw5pUiagQ7fsfOJAuF
PS. Comparative test is useless. For codec VP9 at bitrates equal to 4000 kbps it amounts to 7378 kbps. What I can in this case compare?

Edit: Equating to 4700 kbps bitrate for pass=1
https://www.sendspace.com/filegroup/gqoofCSILpxL5KAWh2YIw59xgsBJMvH4
VP9 1.4-1351 {good/cpu-used=1/sharpness=2/aq-mode=1/tune-content=screen/threads=4/bitrate=2600}
http://i65.tinypic.com/29zxze9.png
X264 2638 komisar {deblock=-3:-3/psy-rd=2.00:0.7/aq-strength=1.2/me=umh/preset veryslow/threads=4/bitrate=4700}
http://i66.tinypic.com/107rt5v.png
X265 1.8.0.71 x265.cc {no-b-intra/no-sao/rect/no-amp/no-temporal-mvp/no-signhide/no-strong-intra-smoothing/rd=6/psy-rd=0.3/rdoq-level=2/psy-rdoq=50.0/me=umh/aq-strength=1.0/deblock=-3:-3/preset veryslow/no-open-gop/no-hrd/bitrate=4700}
http://i66.tinypic.com/4hsj7t.png
original
http://i66.tinypic.com/30x7x2w.png

[x265_Project]

Hey everyone. It's time to refresh our default performance presets. Our team is reviewing and testing everything, but I thought we should reach out here to get feedback from more experts. Behold, the power of open source development. It's unbeatable.

First, let's make it clear what our requirements are for our 10 performance presets. Basically, these are 10 points along the speed versus compression efficiency curve. Compression efficiency = subjective visual quality / bit rate. We want these 10 presets to be points where (for most video content, at any reasonable bit rate) you would get the maximum visual quality at a given bit rate and performance level. Stated another way, at one of these presets you would get the maximum speed for the desired level of efficiency.

Some key presets... and the way we think of them...
Ultrafast = speed at all costs. Efficiency will be low, but not unreasonable. For the most part, we don't recommend using Ultrafast, but it's there for people who really need speed.
Superfast = fastest possible speed with ok quality. One of our "realtime" presets. If you are doing real-time encoding, we would like you to be able to use superfast or veryfast and be pleased with the efficiency.
Veryfast = a higher quality "realtime" preset.
Fast = one of two midpoint presets (along with medium). Slightly faster than medium, but with efficiency that is almost as good.
Medium = our default preset. This should produce very good efficiency (rough estimate is ~ 10% higher bit rate than veryslow), while running at a reasonable speed.
Veryslow = our highest quality preset without requiring a sanity check. Veryslow should produce the highest reasonably possible quality.
Placebo = as the name suggests, this preset is for people who enjoy the placebo effect. You'll believe that you're getting higher quality than veryslow, but the difference in quality is expected to be very small. This preset will run EXTREMELY slow. As speed is not a priority, we will turn on every possible capability of x265.

We expect to turn on some of the new features that we've developed, including lookahead slices, limit-refs, and a new feature called limit-modes. All of these are designed to help x265 run faster, with very little tradeoff in efficiency. On the new Skylake processor, and especially on dual Xeon systems these changes deliver big improvements in speed at various presets. But you should see improvements on most any platform.

After making things run faster, we can tune up various presets to further improve quality (for example, we may be able to increase the number of reference frames after using limit-refs to limit the impact, and the end result would ideally be higher performance and higher quality).

On the subject of "softness", we have developers looking at improvements to Sample Adaptive Offset (SAO) in order to minimize any loss of detail from this algorithm. We're looking at a number of other possible algorithmic improvements, but your feedback (as we've already seen on this thread) is helpful. We're not talking about your suggestions for --tune grain... let's start with optimal quality and detail retention for all x265 presets, and then we can look at how to handle grainy content afterwards.

Thanks,
Tom

[Jamaika]

Some key presets... and the way we think of them...
Ultrafast = speed at all costs. Efficiency will be low, but not unreasonable. For the most part, we don't recommend using Ultrafast, but it's there for people who really need speed.
Superfast = fastest possible speed with ok quality. One of our "realtime" presets. If you are doing real-time encoding, we would like you to be able to use superfast or veryfast and be pleased with the efficiency.
Veryfast = a higher quality "realtime" preset.
Faster = ....
Fast = one of two midpoint presets (along with medium). Slightly faster than medium, but with efficiency that is almost as good.
Medium = our default preset. This should produce very good efficiency (rough estimate is ~ 10% higher bit rate than veryslow), while running at a reasonable speed.
Slow = ....
Slower = ....
Veryslow = our highest quality preset without requiring a sanity check. Veryslow should produce the highest reasonably possible quality.
Placebo = as the name suggests, this preset is for people who enjoy the placebo effect. You'll believe that you're getting higher quality than veryslow, but the difference in quality is expected to be very small. This preset will run EXTREMELY slow. As speed is not a priority, we will turn on every possible capability of x265.
And it is good that the codecs are ten point of quality for X264/X265. Anyone can set it so that the computer will be able to work or perhaps some we want to achieve quality. You want to have a better quality it uses --pass 1,2,3, ...:D

PS. In the X264 always I set veryslow even for YouTube, Vimeo.
For placebo options don't trust, sometimes I see the quality is worse than veryslow.
After making things run faster, we can tune up various presets to further improve quality (for example, we may be able to increase the number of reference frames after using limit-refs to limit the impact, and the end result would ideally be higher performance and higher quality).
We look forward humbly to new solutions.:cool:

[x265_Project]

For placebo options don't trust, sometimes I see the quality is worse than veryslow.
This could be attributed to the reverse-placebo effect. :)

[LigH]

There may also be a discrepancy between objective quality retention (measurable with mathematical metrics) and subjective quality impression (related to psychovisual effects). Or brief: Less perfection may look better to some.

[need4speed]

Thanks for all the efforts. Just starting some additional tests for TV shows 1080p to 720p and BR to 720p.
My own personal opinion is no matter the bitrate the final image is still too much blurred.
One question about SAO: I disable it, always. Is this wrong? I mean, 5 minutes samples don't show any significative difference. Sao enabled or disabled. There are other settings to work together with as for Sao?

Inviato dal mio GT-N7100 utilizzando Tapatalk

[x265_Project]

I will note that it's not as simple as x264 > x265; if you look at areas that x264 has to smooth, it does so in a very ugly fashion. The noisy sky in scene three shows that; it's very objectionable at 4k and 8k, and marginal at 16k. While x265 smooths away all of the grain, the overall effect looks better. Trying to use tune grain makes it look ugly and patchy again.

Of course, I find comparing extreme noise retention to be somewhat begging the question. It's a foregone conclusion that x264 retains more noise (and introduces more of its own), but that much noise is an undesirable artifact in itself. Much more disconcerting is the softer details wherever there's true detail. It's most obvious in parkjoy, where x265 just picks some objects to retain in fidelity (mostly trees), and some to ignore and blur out completely (the group, especially the man in the sailor hat, but some far background trees), no matter how it's tuned.
Foxyshadis makes a good point here - one that's obvious in the still images posted by Jamaika... that the "detail" that is apparently retained by x264 is inaccurate (spatial accuracy, versus the actual source picture). This issue isn't noticeable if you are looking at an object that has some random texture (leaves on a tree, grass, etc.). Who would notice if some of the leaves on the tree are in slightly different positions than the original picture, or if groups of leaves don't wave smoothly in the breeze? But take a look at the faces of the runners. Accurately capturing the position and shape of the eyes, nose and mouth is important. Every runner in the picture looks significantly better in the x265 frame. We don't want more detail, whether it's accurate detail or not. We only want accurate detail, and accurate motion.

[Jamaika]

This is true. I emphasize only that you need a super fast computer. I noticed again that in the aforementioned record commands for X265, I have a problem with the cuts in the film. There are turmoil pixels.

[LigH]

Weekly build: A few bug fixes, speed ups, and:

--[no-]limit-modes Limit rectangular and asymmetric motion predictions. Default 0

When enabled, limit-modes will limit modes analyzed for each CU using cost metrics from the 4 sub-CUs. When multiple inter modes like --rect and/or --amp are enabled, this feature will use motion cost heuristics from the 4 sub-CUs to bypass modes that are unlikely to be the lowest. This can significantly improve performance when --rect and/or --amp are enabled at minimal compression efficiency loss.

So I believe "Default 0" means: There's no limit! (https://www.youtube.com/watch?v=RkEXGgdqMz8)

x265 1.8+76-bd8237a5d782 (GCC 4.9.2) (https://www.mediafire.com/download/dp8nbc881q055og/x265_1.8+60-6563218ce342.GCC492.7z)
x265 1.8+76-bd8237a5d782 (GCC 5.2.0) (https://www.mediafire.com/download/8lfmcbw72it48mo/x265_1.8+76-bd8237a5d782.GCC520.7z)

[Barough]

Thnx 4 the weekly build LigH :)

[shinchiro]

I waited for --rd-refine option to be finalized/pushed. :) Last time I tried, it brings noticeable quality improvement but the tradeoff with speed isnt really worth

[Jamaika]

We expect to turn on some of the new features that we've developed, including lookahead slices, limit-refs, and a new feature called limit-modes. All of these are designed to help x265 run faster, with very little tradeoff in efficiency. On the new Skylake processor, and especially on dual Xeon systems these changes deliver big improvements in speed at various presets. But you should see improvements on most any platform.
For limit-modes film FullHD 11s converted 13min,
Without limit-modes film FullHD 11s converted 16min.
:thanks:
PS I see that there is a problem with the initial movie playback. They are jerks.

[benwaggoner]

For limit-refs film FullHD 11s converted 13min,
Without limit-refs film FullHD 11s converted 16min.
:thanks:

Anyone try --limit-modes yet?

[benwaggoner]

Hey everyone. It's time to refresh our default performance presets. Our team is reviewing and testing everything, but I thought we should reach out here to get feedback from more experts. Behold, the power of open source development. It's unbeatable.

...We expect to turn on some of the new features that we've developed, including lookahead slices, limit-refs, and a new feature called limit-modes. All of these are designed to help x265 run faster, with very little tradeoff in efficiency. On the new Skylake processor, and especially on dual Xeon systems these changes deliver big improvements in speed at various presets. But you should see improvements on most any platform.

After making things run faster, we can tune up various presets to further improve quality (for example, we may be able to increase the number of reference frames after using limit-refs to limit the impact, and the end result would ideally be higher performance and higher quality).
You've already identified the low-hanging fruit from my perspective. One question I've had is if slower shouldn't have --amp or --rect, or if slow should add --weightb. It seems like weighted b-frames helps real world content more at a lower CPU hit. However, if --limit-modes makes amp/rect a lot cheaper, maybe they should be on by default at lower levels.

Enabling more refs via --limit-refs 3 sounds great for >slow. Certainly placebo and perhaps veryslow should use the maximum supported refs per level restrictions.

Also, it seems like --frame-threads is often higher than needed to saturate processors, and can cause quality issues with noisy content. So looking for how to reduce that to the minimum needed for maximum throughput might make sense. And certainly they should be lower for the faster presets, perhaps with --pmode turned on in some cases to recapture some speed.

Automatically turning on --pmode with lots of cores and lower frame sizes could also help speed, with the cost of some determinism.

Adding --qg-size 32 for the slower presets is probably good.

[Jamaika]

Anyone try --limit-modes yet?
For limit-refs=3 and limit-modes film FullHD 11s converted 9min. (Core i5 2500K, Windows 10)
https://www.sendspace.com/filegroup/EMduvLXLfVdmbCcfMqj4RM1yF7z3wAq8O7CAh2qCfTeRw7tjELSNXo5HU09GsFOhVE36zC0sJ4I
PS They aren't jerks. That's great!

[benwaggoner]

For limit-refs=3 and limit-modes film FullHD 11s converted 9min.


PS They aren't jerks. That's great!


From 16 min to 9 min? If there really is minimal.quality loss, that's a big win! That'd allow going up around one preset level

[x265_Project]

Note that limit-modes is only useful for presets that used --rect and --amp. Here are our performance test results on a Haswell processor (Core i7 4770K I believe... will double check today) with and without limiting refs and modes with the veryslow preset...


Before
x265_b.exe --input parkrun_ter_720p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test_b.hevc
encoded 504 frames in 223.08s (2.26 fps), 3596.14 kb/s, Avg QP:37.29, Global PSNR: 30.707, SSIM Mean Y: 0.8688587 ( 8.823 dB)

After
x265.exe --input parkrun_ter_720p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --limit-modes 1
encoded 504 frames in 186.35s (2.70 fps), 3610.14 kb/s, Avg QP:37.35, Global PSNR: 30.692, SSIM Mean Y: 0.8687821 ( 8.820 dB)

x265.exe --input parkrun_ter_720p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --limit-refs 1
encoded 504 frames in 188.32s (2.68 fps), 3604.27 kb/s, Avg QP:37.31, Global PSNR: 30.712, SSIM Mean Y: 0.8689656 ( 8.826 dB)

x265.exe --input parkrun_ter_720p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --limit-refs 1 --limit-modes 1
encoded 504 frames in 165.63s (3.04 fps), 3610.51 kb/s, Avg QP:37.34, Global PSNR: 30.691, SSIM Mean Y: 0.8686912 ( 8.817 dB)

----------------------------------------------------------------------------------------------------------------------------------------------
Before
x265_b.exe --input ducks_take_off_1080p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test_b.hevc
encoded 500 frames in 795.40s (0.63 fps), 9513.58 kb/s, Avg QP:37.92, Global PSNR: 30.459, SSIM Mean Y: 0.8214006 ( 7.481 dB)

After
x265.exe --input ducks_take_off_1080p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --limit-modes 1
encoded 500 frames in 556.86s (0.90 fps), 9553.70 kb/s, Avg QP:37.92, Global PSNR: 30.458, SSIM Mean Y: 0.8214283 ( 7.482 dB)

x265.exe --input ducks_take_off_1080p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --limit-refs 1
encoded 500 frames in 625.53s (0.80 fps), 9518.09 kb/s, Avg QP:37.91, Global PSNR: 30.457, SSIM Mean Y: 0.8213568 ( 7.480 dB)

x265.exe --input ducks_take_off_1080p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --limit-refs 1 --limit-modes 1
encoded 500 frames in 513.12s (0.97 fps), 9564.23 kb/s, Avg QP:37.92, Global PSNR: 30.457, SSIM Mean Y: 0.8213727 ( 7.481 dB)

---------------------------------------------------------------------------------------------------------------------------------------------------
Before
x265_b.exe --input parkrun_ter_720p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test_b.hevc --bitrate 6000
encoded 504 frames in 273.06s (1.85 fps), 5097.33 kb/s, Avg QP:35.53, Global PSNR: 31.691, SSIM Mean Y: 0.8935050 ( 9.727 dB)

After
x265.exe --input parkrun_ter_720p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --bitrate 6000 --limit-refs 1
encoded 504 frames in 231.13s (2.18 fps), 5094.89 kb/s, Avg QP:35.54, Global PSNR: 31.687, SSIM Mean Y: 0.8933111 ( 9.719 dB)

x265.exe --input parkrun_ter_720p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --bitrate 6000 --limit-modes 1
encoded 504 frames in 228.21s (2.21 fps), 5099.24 kb/s, Avg QP:35.60, Global PSNR: 31.671, SSIM Mean Y: 0.8932938 ( 9.718 dB)

x265.exe --input parkrun_ter_720p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --bitrate 6000 --limit-modes 1 --limit-refs 1
encoded 504 frames in 199.34s (2.53 fps), 5098.16 kb/s, Avg QP:35.61, Global PSNR: 31.667, SSIM Mean Y: 0.8931659 ( 9.713 dB)


----------------------------------------------------------------------------------------------------------------------------------------------------
Before
x265_b.exe --input ducks_take_off_1080p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test_b.hevc --bitrate 6000
encoded 500 frames in 659.57s (0.76 fps), 6054.60 kb/s, Avg QP:40.14, Global PSNR: 29.542, SSIM Mean Y: 0.7802421 ( 6.581 dB)

After
x265.exe --input ducks_take_off_1080p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --bitrate 6000 --limit-refs 1
encoded 500 frames in 524.01s (0.95 fps), 6053.17 kb/s, Avg QP:40.15, Global PSNR: 29.537, SSIM Mean Y: 0.7800589 ( 6.577 dB)

x265.exe --input ducks_take_off_1080p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --bitrate 6000 --limit-modes 1
encoded 500 frames in 469.41s (1.07 fps), 6056.95 kb/s, Avg QP:40.18, Global PSNR: 29.535, SSIM Mean Y: 0.7798592 ( 6.573 dB)

x265.exe --input ducks_take_off_1080p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --bitrate 6000 --limit-modes 1 --limit-refs 1
encoded 500 frames in 433.19s (1.15 fps), 6058.14 kb/s, Avg QP:40.19, Global PSNR: 29.529, SSIM Mean Y: 0.7796667 ( 6.569 dB)

x265.exe --input ducks_take_off_1080p50.y4m --preset veryslow --hash=1 --no-info --psnr --ssim -o test.hevc --bitrate 6000 --limit-modes 1 --limit-refs 3
encoded 500 frames in 340.68s (1.47 fps), 6057.80 kb/s, Avg QP:40.19, Global PSNR: 29.519, SSIM Mean Y: 0.7789705 ( 6.555 dB)

[x265_Project]

From 16 min to 9 min? If there really is minimal.quality loss, that's a big win! That'd allow going up around one preset level
Yes, we think so. As you can see from the test data above, with --preset veryslow --limit-refs 3 --limit-modes, you get 2x the speed of --veryslow, with fairly minimal quality impact. So anyone who was previously using --preset slower would probably get a better result using --preset veryslow, --limit-refs 1,2 or 3, and --limit-modes.

[nandaku2]

Also, it seems like --frame-threads is often higher than needed to saturate processors, and can cause quality issues with noisy content. So looking for how to reduce that to the minimum needed for maximum throughput might make sense. And certainly they should be lower for the faster presets, perhaps with --pmode turned on in some cases to recapture some speed.

Hmm, dial down framethreads, raise looakhead-slices, this might be worth trying, although at the below-medium presets, the gains from lookahead-slices aren't as significant.

Automatically turning on --pmode with lots of cores and lower frame sizes could also help speed, with the cost of some determinism.

pmode has been tricky that way, while utilization shoots up, we havent seen any speed gains from it yet. The cost of duplicating and sharing context across threads destroys any utilization benefits.

Adding --qg-size 32 for the slower presets is probably good.

This has been turned on for a while.

[littlepox]

For preset testing, probably we can rely heavily on objective metrics like psnr/ssim. for example, if ref=5/umh/25 has a better psnr/ssim than ref=3/star/57, with almost equal or even faster speed, then we'd probably recommend ref=5/umh/25 in any suitable condition.

However for tunings --tune film/grain/animation, where we need to focus on speed-irrelevant parameters like aq/psy/qcomp/crf, the only reliable metric is the human eyes, even at high bit-rate.

Currently I agree that --preset shall be studied before --tune, because this benefits future tests time-wisely.

[Boulder]

Is it possible to build x265 with Visual Studio 2015 Express? Or is the 2013 the latest supported edition without having to edit the configuration files?

[Motenai Yoda]

what about scaling-list off (default) vs default (no default) ?

[Ma]

Is it possible to build x265 with Visual Studio 2015 Express? Or is the 2013 the latest supported edition without having to edit the configuration files?

For VS 2015 there are no build scripts, so you should modify scripts from vc12* folders.

I attached my builds scripts for example. They works in subdirectory of x265 folder (I created 'x265\ma' folder) with cmake, mercurial, yasm and 7z on path.

[Motenai Yoda]

For VS 2015 there are no build scripts, so you should modify scripts from vc12* folders.
just copy vc12-x86_64, rename it as vc14-x86_64
open each one bat with notepad, replace all 12 with 14, then all 14b with 12b, save, done.

[Boulder]

just copy vc12-x86_64, rename it as vc14-x86_64
open each one bat with notepad, replace all 12 with 14, then all 14b with 12b, save, done.Thanks to both of you, I ended up using this trick which worked fine :)

[zbutsam]

I ran a few tests comparing the encoding speed using the new switches --limit-modes and --limit-refs 3.

I got a 8-10% improvement in preset medium and 60-70% improvement in preset slow both in SD and HD sources. I used --crf 20 and I run the test on an Intel 2500K. I didn't run any slower presets but the results seem promising. Also, I didn't notice any quality degradation.

[Barough]

I ran a few tests comparing the encoding speed using the new switches --limit-modes and --limit-refs 3.

I got a 8-10% improvement in preset medium <snip>

Got around 15 % speed improvement here on Preset Medium and didn't noticed any quality reduction.

[x265_Project]

what about scaling-list off (default) vs default (no default) ?
What about it? What effect do you observe on speed and visual quality when using --scaling-list default? What presets would you suggest that we change?