x265 HEVC Encoder

[Selur]

Sadly 4:2:2 encoding causes x265 to crash and 4:4:4 encoding still produces artifacts when fed through ffmpeg (to be frank this one is more ffmpegs fault).

[Boulder]

Originally Posted by pradeeprama

x265 version 2.3 has been released. This release contains new algorithms that improve visual quality, encoding efficiency, and performance.

1. New SSIM-based RD-cost computation for improved visual quality, and efficiency; use --ssim-rd to exercise.

I was wondering, is this observation based on metrics or visual comparison? Also what about --tune grain, would this option have adverse effects there?

[Selur]

"SSIM-based RD-cost computation" -> sounds like metrics based

[Boulder]

I was wondering about the "improved visual quality" -statement as it's generally considered a fact that visual comparison is needed in addition to any metrics

[LigH]

New milestone (stable merge build): x265 v2.3

x265 2.3+2-912dd749bdb5 (mostly identical to v2.2+36)
_

Of course, SSIM-RD uses the SSIM metric to optimize rate distortion. The previously used metric will have been simpler than that, though, so chances are good that many people would agree with improved quality. But don't hesitate to organize a mass ABX test

[Sagittaire]

@ dev team

x265 introduce specifical optimisation for new AMD Rysen CPU?

Originally Posted by Sagittaire

@ dev team

x265 introduce specifical optimisation for new AMD Rysen CPU?

We're still in the early phase of evaluating and optimizing performance on Ryzen. Nothing that I can report at this time.

[Selur]

What does 'analyze-src-pics' do?

Enalbe motion estimation with source frame pixels, in this mode, motion estimation can be computed independently.

Didn't really help in whether this is more of a testing feature, whether this is should boost compressibility,...

[Barough]

x265 v2.3+6-db913efb1a59 (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.3+6-db913efb1a59
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

https://bitbucket.org/multicoreware/x265/commits/branch/default

[mandarinka]

Originally Posted by x265_Project

We're still in the early phase of evaluating and optimizing performance on Ryzen. Nothing that I can report at this time.

In case you are adding AMD core detection for Ryzen, could you also add a detection for Excavator?
Currently that core suffers about 4% performance hit due to using AVX2 which is available but slow on it. I think all you would need to do is add a condition to the CPU detection code that disables AVX2 use if both AVX2 and and AMD XOP instruction extensions are detected on the CPU. (Zen doesn't have XOP supposedly.) Or there might be other ways to check for Excavator more intelligently, I'm no expert by far

Originally Posted by Selur

"SSIM-based RD-cost computation" -> sounds like metrics based

Originally Posted by Boulder

I was wondering about the "improved visual quality" -statement as it's generally considered a fact that visual comparison is needed in addition to any metrics

Guys.... duh. Every encoder decision, including the current Psy RDO in x264 and x265, has to use some metric. Encoder being a computer program has no other way to do it. The difference is just that the current metrics were less complex, SSIM is probably replacing difference calculating tools like SAD/SATD.
To check the visual results and decide if you like them is your job, the program can't do it for you.

[littlepox]

If someone wish to use a method not being any metric, you must do the following:

1. the encoder encodes a block in several ways, then present the pictures to you;
2. you evaluate the quality of the pictures and assign them some marks
3. the encoder takes you evaluation and compute rate/distortion trade-off
4. go back to 1 with another block to encode


This is then a true "Human-eyes tuned rd"

[Boulder]

Originally Posted by mandarinka

Guys.... duh. Every encoder decision, including the current Psy RDO in x264 and x265, has to use some metric. Encoder being a computer program has no other way to do it. The difference is just that the current metrics were less complex, SSIM is probably replacing difference calculating tools like SAD/SATD.
To check the visual results and decide if you like them is your job, the program can't do it for you.

I was more or less interested in whether the devs had already had some visual comparison done or if the comparisons are purely based on metrics. I'm more than happy to accept the opinion of the majority what comes to visual quality, that's why I use presets But what that option actually does to --tune grain concerning keeping noise/grain is a bit unclear as I'm not that deep into the technical things.

Originally Posted by Selur

What does 'analyze-src-pics' do?

Didn't really help in whether this is more of a testing feature, whether this is should boost compressibility,...

This is a test feature. It allows us to run experiments. It will hurt compression efficiency, so it shouldn't be used for any production encoding.

Normally, when the encoder performs inter-prediction (also known as motion compensated prediction), it must wait until the reference frames that it wants to use for frame #x are finished encoding before it can start encoding frame #x (or, with Wavefront Parallel Processing, it must wait until the first rows of the reference frames are completed before it can start). This feature tells the encoder to use the original source frames as reference frames, breaking that dependency. This would allow an encoder to run faster, especially for file-based encoding, as it has the dependent data (the source frames), and so it can start encoding each frame right away. But the source frames are not what the decoder will have when it is decoding. The actual decoded reference frames will be different (except for a lossless encode). So the inter-prediction won't be nearly as accurate when you use source frames as reference frames.

[Midzuki]

Originally Posted by Midzuki

So, perhaps XhmikosR will release a new MSYS1 package only when GCC 7 is out...

Not true, fortunately. His MSYS_MinGW-w64_GCC_630_x86-x64_Full.7z went out of the oven yesterday:

http://xhmikosr.1f0.de/tools/msys/

[LigH]

Hooray! Thank you, XhmikosR! I'll start updating.

[Rinzler0x7BB]

Hi,

the last months i made a lot of tests with x265 and now I want to share my experience I made with one issue I had with small moving objects.

From the description of "Jawed" some months ago it seems that he saw a similar issue:

Originally Posted by Jawed

I found that motion in live action tended to become jittery (sort of as though it were half-rate: "anime" in feel).

http://forum.doom9.org/showpost.php?...postcount=4189

I actually found the same source suffered the same fate with x264 at crf 24 (using settings that are almost equivalent to preset very slow in speed).
But in x264 I historically did not use crf as high as 24 - principally because blocking/banding with 8-bit encodes becomes unbearable.

So the same source in both x264 and x265 (both 10-bit) produced the same problem,
which disappears with crf 20. In x264, setting --tune grain also solved the problem (doubled the bitrate for the water test sequence too...).

So when I started my x265 experiments I started to investigate crf, pushing far beyond 21 which was my limit with x264 8-bit. 10-bit, it transpires,
makes x264 blocking/banding a non-issue, which was a good reason to see what I thought of higher crf values. Along the way I stumbled into this problem at crf 24.

(In fact I found the problem back in April and was so dismayed that I just forgot about my x265 experiments and did other things -
not realising at the time that it was b-frames causing the problem.)

On the water sequence I reported 4 b-frames as a solution.
But in other testing I found that rapidly turning faces (small in the frame) in low contrast (think "a steamy room") the problem recurred (horrible jumps, like anime).
So 2 b-frames it is.

I decided not to evaluate CRFs between 20 and 24 to see how the problem arises.
It just seems that at crf 24, b-frames (with x264 or x265 both on very slow preset) are too unreliable.
I hadn't noticed in the past with x264 because I hadn't used such a high value for crf.

My description
This is still visible with the current builds of x265 with lower crf values.
I describe it like a judder in front or the back of the object in the direction of the movement.
At first I thought that it is only visible with crf values lower than 21. But with a closer look it is also visible with crf 20.

How to reproduce
I found a video on youtube with which it was easy to reproduce this behavior.
"Loop 610 & U.S. 290 Interchange - Houston Construction - March 6, 2015 - 4K HD"
https://www.youtube.com/watch?v=Ax90e-F0z_M

This video has a lot of small cars which makes it perfect to see the judder on small cars.
To make it easier to see them i downscaled to 720p.
Enocde the video with --preset medium and --crf 22

My tests
I made a lot of Tests to reduce the judder. At first I started to use higher values which influence the motion estimation like --me star or higher --subme values.
But It helped only very little.

Then I found the setting which helped the most. --rd 5/6 did all the magic.
My problem with --rd 5/6 is the very low speed as I still wanted to have reasonable encoding times.
I also liked the better quality but together with --rdoq-level 2 and higher --psy-rdoq values which we need for high detail encodes it is too slow for me.

My solution
With another bunch of test encodes I found out that --rect helped nearly the same like --rd 5/6.
Then it is not necessary to use --rd 5/6 to have smooth motion on small moving objects.
--rect makes the encode also slower but there is a big difference to --rd 5/6.

My question
Is this a bug?. I did not recognize this behavior with x264.
Maybe there is a way to reduce this judder without the use of --rect or --rd 5 and have a faster encoding speed.

My low quality settings
I ended up in these settings which i use for my low quality encodes:

--profile main10 --output-depth 10 --preset medium --crf 22 --ctu 32 --aq-mode 3 --aq-strength 0.9 --aq-motion  
--rc-lookahead 25 --no-sao --level-idc 4.1 --high-tier --rd 4 --psy-rd 2.1 --psy-rdoq 2.5 --rdoq-level 2 
--bframes 6 --no-strong-intra-smoothing --b-intra --rect --limit-modes

My high quality settings
Finally these are my high quality settings I currently use:

--profile main10 --output-depth 10 --preset medium --crf 20 --ctu 32 --pbratio 1.22 --subme 3 --aq-mode 3 --aq-strength 0.9 
--qcomp 0.64 --rc-lookahead 35 --no-sao --level-idc 4.1 --high-tier --rd 4 --psy-rd 2.5 --psy-rdoq 3.5 --rdoq-level 2 
--bframes 8 --no-strong-intra-smoothing --weightb --b-intra --rect --limit-modes

[Sagittaire]

Originally Posted by Boulder

I was more or less interested in whether the devs had already had some visual comparison done or if the comparisons are purely based on metrics. I'm more than happy to accept the opinion of the majority what comes to visual quality, that's why I use presets But what that option actually does to --tune grain concerning keeping noise/grain is a bit unclear as I'm not that deep into the technical things.

well codec use by definition always metric. Tune grain use "complexity" metric too. all the decision in all codec use always metric. SSIM are by definition an HVS metric.

and you have generaly good correlation with metric and eye in all serious bench.

[aymanalz]

Using V2.3, with 2 pass encoding I am getting significantly higher speed for 2nd pass, than for first pass. Previously, they used to go at the same rate. I am guessing this is due to the Analysis and QP refinement enhancements? I don't use "fast first pass".

[Jamaika]

Originally Posted by Midzuki

Not true, fortunately. His MSYS_MinGW-w64_GCC_630_x86-x64_Full.7z went out of the oven yesterday:

Buuuu, Windows 10 delete files EXE.
Trojan:Win32/Kandelo.B!cl

[LigH]

@ aymanalz:

I believe to remember that 1st pass statistics contain more reusable data than before, so the 2nd pass may be able to spare more calculations?

@ Jamaika:

Which AV possibly reports false alarms for which files? I'm still downloading (crappy rural connection); should be cross-checked with multi-engine AV web services like VirusTotal or malwr.