x265 HEVC Encoder

[Selur]

I didn't get what you just said. Rephrase?

qcomp = Quantizer curve compression factor.
0.0 => Constant Bitrate, 1.0 => Constant Quantizer.
Quantizer is not the same as Quality or RateFactor.

It's interesting that psy-RD and psy-RDOQ increased quality so much, I thought it was a noise-retainer?

You thought wrong. If you are interested in it you should read up on what rate distribution (=RD) really means. And how the rate control in x264&x265 works.

.. you post a new encode with proper decoder?

removing '-vsync 0' from the decoder call, fixes the frame count:

ffmpeg -y -loglevel fatal -threads 8 -i "input.avs" -an -sn  -vsync 0 -r 6010000/100000  -pix_fmt yuv420p  -strict -2 -f yuv4mpegpipe - | x265 ..

Due to not having the time to play around with your sample I probably will not look further into improving the quality.
My guess is that the best way to improve quality more is probably to remove some of the details before processing using avisynth or similar filtering (no need to stress the codec to try to retain stuff which simply can't be retained at such a low bitrate - high rate control).
(10bit encoding will also help)

[-Habanero-]

qcomp = Quantizer curve compression factor.
0.0 => Constant Bitrate, 1.0 => Constant Quantizer.
Quantizer is not the same as Quality or RateFactor.

That's correct, yes. You wondered why I used 0.7 and I explained that I wanted something leaning towards constant quality but not completely because action scenes don't exactly need to be the same as everything else. Are you suggesting I need to use 1.0 or what?

You thought wrong. If you are interested in it you should read up on what rate distribution (=RD) really means. And how the rate control in x264&x265 works.

Yeah I'm gonna have to. But as I understand it, these are psychovisuals, that they artificially make things look better by adding noise where high-entropy detail would've otherwise been squashed by the compression.

Due to not having the time to play around with your sample I probably will not look further into improving the quality.
My guess is that the best way to improve quality more is probably to remove some of the details before processing using avisynth or similar filtering (no need to stress the codec to try to retain stuff which simply can't be retained at such a low bitrate - high rate control).
(10bit encoding will also help)

My primary concern was the fact that it was doing worse than x264 when this wasn't the case a year ago but the psychovisuals and increased me-range did largely mitigate this. This wasn't the only sample where it happened either. I noticed a drop in quality in a music video as well but I will turn on RDOQ this time and see what happens. I'm probably not gonna increase the me-range because I don't think this is beneficial for normal footage. Is it?

[Selur]

Are you suggesting I need to use 1.0 or what?

I suggest don't change the value unless you know what you are doing. Messing with the rate control normally isn't a wise idea.

But as I understand it, these are psychovisuals, that they artificially make things look better by adding noise where high-entropy detail would've otherwise been squashed by the compression.

' by adding noise ' -> no

I'm probably not gonna increase the me-range because I don't think this is beneficial for normal footage. Is it?

for 8bit arcade like encoding it can help (doesn't hurt)

using 10bit:

ffmpeg -y -loglevel fatal -threads 8 -i "C:\Users\Selur\Desktop\ng2.avi" -map 0:0 -an -sn  -vf crop=256:216:0:8 -r 6010000/100000  -strict -2 -pix_fmt yuv420p10  -strict -2 -f yuv4mpegpipe - | x265 --preset veryslow --pmode --pme --input - --output-depth 10 --y4m --allow-non-conformance --ctu 32 --merange 100 --keyint -1 --bframes 16 --ref 16 --crf 41.10 --nr-intra 500 --nr-inter 500 --psy-rdoq 15.00 --aq-mode 2 --aq-strength 1.50 --range full --colormatrix bt470bg --output "H:\Temp\06_25_18_3010_01.265"

----
what you could also try is using --keyint -1

[LigH.de]

The purpose of psychovisual algorithms is to spare bitrate by coarser quantization (in relation to the normal metric, e.g. Rate Distortion factor) in areas where you will probably not recognize more distortions easily, and spend the obtained reserve by finer quantization in other areas where distortions would be more noticable.

Keeping grain better is merely a side effect of finer quantization being available where a reserve could be achieved by "moving energy from one area to another".

[-Habanero-]

Man, my mistake is treating x265 like it's some linearly updated version of x264 when it isn't. Everything I know seems to be wrong. I tested qcomp and it wasn't doing anything I expected but I'll have to experiment at higher bitrates.

for 8bit arcade like encoding it can help (doesn't hurt)

No, I mean for normal footage like the music video I mentioned.

Your encode looks good but it crashed when I tried to open it with Avisynth so I give up. Your setup is weird.

The purpose of psychovisual algorithms is to spare bitrate by coarser quantization (in relation to the normal metric, e.g. Rate Distortion factor) in areas where you will probably not recognize more distortions easily, and spend the obtained reserve by finer quantization in other areas where distortions would be more noticable.

Keeping grain better is merely a side effect of finer quantization being available where a reserve could be achieved by "moving energy from one area to another".

That just sounds like the description of VBR or mb-tree. "Take bitrate from places that dont need it to feed others". Does it make sense to take away details in order to retain noise? I'd rather the noise be gone.

[LigH.de]

The problem of noise is that it is mainly "high frequencies". Just like details. Too coarse quantization may flatten out high frequencies, no matter whether they mean details or noise. The decision where high frequencies are interesting details, and where they are unnecessary noise, is quite hard. Psychovisual algorithms are one of several approaches to let the results appear more convenient. But only their developers may really understand what they do in detail... Your task is to test them and decide if they do a good job in your case.

[Selur]

Your encode looks good but it crashed when I tried to open it with Avisynth so I give up. Your setup is weird.

Did you try LwLibavSource? (my guess is you use FFVideoSource or don't dither it for preview)
Also remember the last if 10bit so you probably have to convert it to might need to convert it to 8bit using dithering,...

LWLibavVideoSource("C:\Users\Selur\Desktop\ng2.mkv",cache=false,stacked=true,format="YUV420P10",repeat=true)
f3kdb_dither(stacked=true,input_depth=10)

to preview or compare it to an 8bit encode,...

[-Habanero-]

Man, what am I doing wrong? On a different video I am still getting worse results than x264 and I did use 100 merange as well as 10 psy-rdoq. This time the CRF is 24 rather than 40 so it's not a super low bitrate I'm testing anymore. Higher rdoq brought lower quality.

avs4x26x.exe --x26x-binary x265 met.avs --pass 2 --bitrate 108 --preset veryslow --psy-rdoq 10.00 --ref 16 --bframes 16 --keyint 600 --rc-lookahead 250 --allow-non-conformance -o "metx265.hevc"

The only thing I didn't try yet is 10-bit. It would be a bit of an unfair comparison since my low-end codec is XviD which doesn't have 10-bit encoding. Oh well. Since when was comparing XviD to x264 ever fair?

[Selur]

Depending on the video some denoising&co might help,....

[-Habanero-]

**** me, I forgot to upload it.
https://www.sendspace.com/file/pf6fxb

I tried 10-bit encoding and curiously it was worse quality than 8-bit with the same settings. I'm confused.

[aymanalz]

For x265 encoding speed, do the Intel 6th gen (Skylake) processors have any advantage over 4th gen (Haswell)? Any new instruction sets that make it faster, or may make it faster in future? I know that 4th gen processors are significantly faster than anything prior, due to the AVX2 instruction set. I'm looking at buying either one of these, with comparable processor frequencies.

[SameSelf]

Short answer: yes, of course. Should you upgrade though? Long answer: it depends on which Haswell and Skylake you are talking about. Your profile says you have an i5. Search the web for benchmarks. On average I would think a straight Haswell to Skylake i5 upgrade would offer about 30% to 40% faster fps for 4K x265 which is a significant reduction in encode times. But ironically, upgrading to a Haswell i7 would probably offer an even bigger step change in fps. Even upgrading to a Sandybridge i7 would offer you an increase over your current i5. So in case you can't see where I am going with this, your limiting factor right now is not the Haswell per se, but the fact that it is an i5 with no hyperthreading.

If I were you, I would seriously consider upgrading your i5 to an i7-4790K. You can sell the i5 on ebay. Keep your motherboard, ram, and everything else. So it becomes a fairly economical upgrade with a significant bump in speed.

At this point, the only compelling reason to upgrade to Skylake from Haswell is if you feel limited by the number of PCI-e lanes, the lack of M.2/NVM ssd boot support, or some combination of other esoteric factors like that. IOW, upgrading your pc these days is simply not worth it for the cpu alone.

[aymanalz]

^^
Hmm, I wasn't aware that my profile says I have an i5. I'll have to edit that. Actually I have an ivybridge i7, quad core. So my doubt is whether to purchase a Haswell or Skylake i7. For comparable frequencies, the Haswells are priced lower. So the question is, would I have a considerable benefit in buying the more expensive skylake?

From all the reviews and benchmarks I've seen, going from Ivybridge (which I have now) to Haswell makes a big difference in encoding frame rate. This is consistent with what the developers have stated here, that processors with AVX2 will perform well, due to optimized assembly code. Which is why I'm wondering if skylake has similar benefits, of new instruction sets that x265 can take advantage of.

[SameSelf]

Upgrading to either Haswell or Skylake from an IB i7 in a quest for marginally faster fps is a waste of money. There is only one real solution: moving to an extreme sku.

http://www.anandtech.com/show/10337/the-intel-broadwell-e-review-core-i7-6950x-6900k-6...-to-10-cores/6

[El Heggunte]

Upgrading to either Haswell or Skylake from an IB i7 in a quest for marginally faster fps is a waste of money. There is only one real solution: moving to an extreme sku.

http://www.anandtech.com/show/10337/the-intel-broadwell-e-review-core-i7-6950x-6900k-6...-to-10-cores/6

Good post

[El Heggunte]

Just copying some interesting info from the x265 thread @ doom9

yes..there's some quality improvement even in low bitrate. kudos for that

Cli (626fcbac7ffb):

ffmpeg -i input.mkv -f yuv4mpegpipe -pix_fmt yuv420p - | x265.exe --y4m --bitrate 500 --preset veryslow --ctu 32 --max-tu-size 16 --tu-intra-depth 2 --tu-inter-depth 2 --me umh --rdpenalty 1 --psy-rd 2.5 --recursion-skip --rc-lookahead 90 --aq-mode 2 --ref 3 --deblock -3:-3 --no-rect --no-amp --no-b-intra --no-weightb --no-psy-rdoq --no-rdoq-level --no-strong-intra-smoothing --no-sao --output output.mkv -

Cli (836a870): (rskip is enabled by default in preset veryslow)

ffmpeg -i input.mkv -f yuv4mpegpipe -pix_fmt yuv420p - | x265.exe --y4m --bitrate 500 --preset veryslow --ctu 32 --max-tu-size 16 --tu-intra-depth 2 --tu-inter-depth 2 --me umh --rdpenalty 1 --psy-rd 2.5 --rc-lookahead 90 --aq-mode 2 --ref 3 --deblock -3:-3 --no-rect --no-amp --no-b-intra --no-weightb --no-psy-rdoq --no-rdoq-level --no-strong-intra-smoothing --no-sao --output output.mkv -

Have also noticed a speed drop here. Commits compared, 78ffb67 with 836a870. ~7%

Preset : Medium
Custom Command line :
--me 3 --ref 4 --aq-mode 2 --aq-strength 3 --rdoq-level 1 --psy-rdoq 5 --rc-lookahead 80 --no-rskip

Better compare either the same build with one option enabled and disabled, or two builds with both the same options; you may be surprised how much more changed between two releases, and then you can't decide if the reason of an output or speed difference is this one option you changed, or all the other code differences...

In such a case where the meaning of an option changed slightly, one may need to compare four tests (both builds with option enabled and disabled).

I have compared between 2 specific commits using the same options and using the same test files. Have run the tests 3 times each with the commits i mentioned above above and the latest commit is a little slower.

Got a friend 2 do some quick tests also and he say the same thing about the latest commit. It's slower.

Yes. At preset veryslow, if you compare the older --recursion-skip and the current --rskip (enabled by default), you will find a small loss in speed, but a huge gain in quality. Essentially, the newer rskip aims to keep the same quality as the older no-recursion-skip, without the 40%+ performance loss.

There should be no impact at medium preset though...

[LigH.de]

Here is the place to report the announcement...

x265 version 2.0 has been released. This release supports many new features as well as support for ARM assembly optimizations for most basic pixel and ME operations, as well as SAO cleanups and a fully tested reconfigure functionality.

Full documentation is available at http://x265.readthedocs.org/en/stable/

=========================================== New Features =========================================

• uhd-bd: Enable Ultra-HD Bluray support
• rskip: Enables skipping recursion to analyze lower CU sizes using heuristics at different rd-levels. Provides good visual quality gains at the highest quality presets.
• rc-grain: Enables a new ratecontrol mode specifically for grainy content. Strictly prevents QP oscillations within and between frames to avoid grain fluctuations.
• tune grain: A fully refactored and improved option to encode film grain content including QP control as well as analysis options.
• asm: ARM assembly is now enabled by default, native or cross compiled builds supported on armv6 and later systems.

==================================== API and Key Behaviour Changes ==================================

• x265_rc_stats added to x265_picture, containing all RC decision points for that frame
• PTL: high tier is now allowed by default, chosen only if necessary
• multi-pass: First pass now uses slow-firstpass by default, enabling better RC decisions in future passes
• pools: fix behaviour on multi-socketed Windows systems, provide more flexibility in determining thread and pool counts
• ABR: improve bits allocation in the first few frames, abr reset, vbv and cutree improved

=============================================== Misc ==============================================

• An SSIM calculation bug was corrected

Addendum: x265 is capable of triggering this Centos kernel bug causing a deadlock, mostly observed on large multi-socketed servers. Please update your kernels to kernel-2.6.32-504 or above to avoid that risk.

[-Habanero-]

What am I doing wrong? x265 is consistently producing worse quality than x264.
https://www.sendspace.com/file/88ikq2

Also note to developers: 2pass is worse than CRF on scenes that fade to black.

[ben45]

X265 is very slow! i get ~ 80fps with x264 but x265 is under 10fps

[LigH.de]

What am I doing wrong?

Not telling us any details. Like ... the complete command lines. Here, not in a download archive.
_

X265 is very slow!

Yes. It does a magnitude more calculations, even with some faster presets. No surprise. Using a modern CPU with AVX2 instructions helps a lot.

[-Habanero-]

I reloaded machine state so I lost the command line, but if I were to encode again this is what it would be:

x265 -D 10 "TouhouAnime.y4m" --crf 32 --preset veryslow --ref 16 --bframes 16 --rc-lookahead 100 --allow-non-conformance -o "TouhouAnime.hevc"

And I use Megui for x264, this is the logged commandline:

"C:\Program Files\megui\tools\x264\x264.exe" --crf 32.2 --deblock 1:1 --keyint 240 --bframes 16 --b-adapt 2 --ref 16 --qpmin 10 --qpmax 51 --rc-lookahead 250 --aq-mode 2 --merange 24 --me umh --direct auto --subme 11 --partitions all --trellis 2 --no-fast-pskip --no-psy --sar 1:1 --output "M:\TouhouAnime.mkv" "M:\TouhouAnime.avs"

[LigH.de]

Pretty nonsensical: You cannot compare a similar CRF value of x264 and x265, they have a different magnitude – at the very least they will result in different bitrates which makes any opinion regarding quality void.

Furthermore, your options are far from sensible relations among each other. Placebo squared. If you have "touhou" material, spend plenty of bitrate so that you can afford --no-sao to avoid "smoothing all objects" which is a feature for low bitrates and certailnly has an expectable side effect of detail loss.

[-Habanero-]

Pretty nonsensical: You cannot compare a similar CRF value of x264 and x265,

Not what I'm doing.

Furthermore, your options are far from sensible relations among each other.

How?

If you have "touhou" material, spend plenty of bitrate so that you can afford --no-sao to avoid "smoothing all objects" which is a feature for low bitrates and certailnly has an expectable side effect of detail loss.

The issue here is that x264 at the very same bitrate provided better quality than x265 and my question is why. Please actually look at what I uploaded. The videos are 1.7 MB each so they won't take long.

[LigH.de]

My first guess: Because SAO is made for strong detail reduction to keep web videos looking halfway convenient, but only with natural content. Artifical content needs more details to keep up sharp edges and grainy textures.

[-Habanero-]

SAO... doesn't that have something to do with deblocking? I do realize now I use 1:1 deblocking in x264 like I've done for a decade but only used the default 0:0 in x265 but I honestly don't see this improving quality.

What did you mean by "your options are far from sensible relations among each other" in the previous post?

[sneaker]

Oh, I did the same test last year.

[-Habanero-]

Oh, I did the same test last year.

And as predicted, your encode is better quality than mine despite being way older. Sigh.
WHAT. AM. I. DOING. WRONG?

[aymanalz]

Oh, I did the same test last year.

And as predicted, your encode is better quality than mine despite being way older. Sigh.
WHAT. AM. I. DOING. WRONG?

Well first of all, a CRF of 32. That will look terrible. Lower it. Or use 2-pass encode at a certain bitrate for both x264 and x265, and then compare quality. Chances are, x265 will look much better.

Since you want to know how the two codecs compare at similar bitrates, that would be the sensible thing to do. CRF is not the same for both.

[sneaker]

He did use the same bitrate.

[gregoor]

Hello beautiful people of the internet,

this seems like the right place to ask: Are there are any quality GPU HEVC encoders out there that don't use NVENC? It seems like the NVENC support of my card is very limited but I'm not satisfied with the perf I've been getting from ffmpeg or MediaCoder in CPU mode.