x265 HEVC Encoder

[mzso]

Here are examples of aliasing I saw with x265 encodes:
https://drive.google.com/open?id=0By...UdidHRRenMyQlE

https://drive.google.com/open?id=0By...k5IakRzZDd0eVk

Does anyone have a clue why it happens?

[littlepox]

It's due to the very distinct pattern on his face after down-scaling.
Technically it is called "Moiré pattern".
It has nothing to do with the encoder unless the encoder performs a blur filter before encoding.

Originally Posted by mzso

Hi!

Is aliasing a significant issue for x265 (our HEVC)? I came across two separate x265 encoded files of the same thing. The higher bitrate one had some pretty bad aliasing where there were fine patterns. The lower bitrate one was even worse with with more stuff aliased an aliasing being more pronounced.

It looks like something went wrong in a processing step prior to encoding... probably in scaling, or chroma subsampling.

[Ma]

There are stability problems with newest Microsoft compilers -- VS 2015 update 3 & VS "15" preview 5. 12-bit x265 compiled with CXXFLAGS=/arch:AVX /GS- /GL hangs at beginning of encoding. (VS 2013 update 5 & VS 2015 update 2 works OK.)

I have a request to a person with AVX2 CPU -- could you test AVX & AVX2 version of 12-bit x265 compiled by VS "15" preview 5 and report back if it works (it hangs at i5 3450S, but it is possible that it works at AVX2 CPU).
VS "15" preview 5 clean builds: http://www.msystem.waw.pl/x265/x265-...393b_vs15p5.7z (it works, no need to test)
AVX-CPU VS "15" preview 5 clean builds: http://www.msystem.waw.pl/x265/x265-..._vs15p5-AVX.7z (x265-12b.exe hangs on AVX CPU)
AVX2-CPU VS "15" preview 5 clean builds: http://www.msystem.waw.pl/x265/x265-...vs15p5-AVX2.7z (not tested -- I don't have AVX2 CPU)

[trip_let]

Originally Posted by Ma

There are stability problems with newest Microsoft compilers -- VS 2015 update 3 & VS "15" preview 5. 12-bit x265 compiled with CXXFLAGS=/arch:AVX /GS- /GL hangs at beginning of encoding. (VS 2013 update 5 & VS 2015 update 2 works OK.)

I have a request to a person with AVX2 CPU -- could you test AVX & AVX2 version of 12-bit x265 compiled by VS "15" preview 5 and report back if it works (it hangs at i5 3450S, but it is possible that it works at AVX2 CPU).
VS "15" preview 5 clean builds: http://www.msystem.waw.pl/x265/x265-...393b_vs15p5.7z (it works, no need to test)
AVX-CPU VS "15" preview 5 clean builds: http://www.msystem.waw.pl/x265/x265-..._vs15p5-AVX.7z (x265-12b.exe hangs on AVX CPU)
AVX2-CPU VS "15" preview 5 clean builds: http://www.msystem.waw.pl/x265/x265-...vs15p5-AVX2.7z (not tested -- I don't have AVX2 CPU)

12-bit AVX build from x265-2.1+20-c64393b_vs15p5-AVX.7z and 12-bit AVX2 build from x265-2.1+20-c64393b_vs15p5-AVX2.7z work fine for me.

I let it go for about 1000 frames before I stopped the process. This on a Core i7-6700K.

[Ma]

Originally Posted by trip_let

12-bit AVX build from x265-2.1+20-c64393b_vs15p5-AVX.7z and 12-bit AVX2 build from x265-2.1+20-c64393b_vs15p5-AVX2.7z work fine for me.

I let it go for about 1000 frames before I stopped the process. This on a Core i7-6700K.

Thanks!

It looks like newest M$ compilers emit AVX2 only instruction with /arch:AVX option. I will try to report this bug.

[Barough]

x265 v2.1+20-c64393b415ad (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[LigH]

x265 2.1+20-c64393b415ad (GCC 5.3.0)
x265 2.1+20-c64393b415ad (GCC 6.2.0)

CLI changes since v2.1+2:

+   --limit-tu <integer>          Enable early exit from TU recursion for inter coded blocks. Default 0

-   --discard-sei                 Discard SEI packets in bitstream. Default disabled
-   --discard-vui                 Discard optional VUI information from the bistream. Default disabled
+   --[no]-vui-timing-info        Discard optional VUI timing information from the bistream. Default enabled
+   --[no]-vui-hrd-info           Discard optional HRD timing information from the bistream. Default enabled

^ The small syntax typo will surely be corrected soon... ([no-]... instead of [no]-...).

The new option --limit-tu sounds interesting to me; I wonder how much speed gain will be possible without a noticable additional loss of quality.
__

P.S.: Don't try --limit-tu >2.

Invalid limit-tu option, limit-TU must be 0, 1 or 2

In a very brief test with a small video, the results were bit-identical, and no certain speed increase. So I guess an advantage requires specific situations.

[fauxreaper]

Originally Posted by LigH

In a very brief test with a small video, the results were bit-identical, and no certain speed increase. So I guess an advantage requires specific situations.

limit-tu only works with tu-inter-depth>1.

[benwaggoner]

Originally Posted by LigH

x265 2.1+20-c64393b415ad (GCC 5.3.0)
x265 2.1+20-c64393b415ad (GCC 6.2.0)
The new option --limit-tu sounds interesting to me; I wonder how much speed gain will be possible without a noticable additional loss of quality.
__

In a very brief test with a small video, the results were bit-identical, and no certain speed increase. So I guess an advantage requires specific situations.

I have a few more --limit-tu questions as well.

1. What does the default of 0 do? Is it the same as --no-limit-tu?
2. Is the expectation that 2 is faster and potentially lower quality than 1?

[brumsky]

@x265_project

Thank you guys so much! I've been wishing for a option like this for some time.

A few quick tests show a performance drop of ~.5% with a file size ~2% smaller. This is comparing inter 1 vs inter 4 + limit tu 1. Without limit tu, inter 4 is ~ 20% slower.

So far I see no visible quality difference.

Great job!!!

Could you explain the differences between limit tu 1 + 2 a bit more in depth, please?

[easyfab]

Originally Posted by LigH

I wonder how much speed gain will be possible without a noticable additional loss of quality.
.

according to this https://mailman.videolan.org/piperma...er/010702.html

it seems there is no significant loss of quality for a good gain of speed with slower presets

[LigH]

Originally Posted by fauxreaper

limit-tu only works with tu-inter-depth>1.

This leads to the follow-up question: When does that happen? — For preset defaults slower than "slow".

slower = 2
veryslow = 3
placebo = 4

They are all no choice for a CPU without AVX support, I fear...

[stevendj]

Hi all,

I noticed a speed decrease between today's x265 and an earlier version of it.
Using builds from builds.x265.eu I narrowed the change I'm talking about down to be between the following versions:
1.9+217-626fcbac7ffb
1.9+223-17c0c875f27d

Encoding the same input video with the same settings takes 5%-30% longer in +223 compared to +217.
File size and visual quality of the output are virtually the SAME.

These commits can currently be found at the fourth page of the commits list on Bitbucket.
I also attached a screenshot of the 6 commits that could have caused this slowdown.

The new recursion skip a.k.a. --rskip seems like something big that could have caused the different encoding time, so I tried --no-rskip, but that (logically) only further increased the encoding time.

Could some other people perhaps test if they see a significant slow down between these versions too?

Thanks in advance

[Ma]

Originally Posted by stevendj

Encoding the same input video with the same settings takes 5%-30% longer in +223 compared to +217.
File size and visual quality of the output are virtually the SAME.

Could you specify your encoding settings?

[Motenai Yoda]

Originally Posted by LigH

This leads to the follow-up question: When does that happen? — For preset defaults slower than "slow".

slower = 2
veryslow = 3
placebo = 4

They are all no choice for a CPU without AVX support, I fear...

virtually they can change preset defaults to use tu-inter 2/3 on faster presets with limit-tu 2/1 w/o sensible speed impact

also as the doc says

--limit-tu <0|1|2>
Enables early exit from TU depth recursion, for inter coded blocks.
Level 1 - decides to recurse to next higher depth based on cost comparison of full size TU and split TU.
Level 2 - based on first split subTU's depth, limits recursion of other split subTUs.
Default: 0

so testing anything over 2 has no sense

[brumsky]

Originally Posted by stevendj

Hi all,

I noticed a speed decrease between today's x265 and an earlier version of it.

This will explain the performance difference you are seeing.

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

At least it should.

[stevendj]

Originally Posted by Ma

Could you specify your encoding settings?

I can reproduce the difference with just preset slower & crf 23.
I also tried preset medium, but the issue seems non-existent there.

It seems especially reproducible when encoding animated content, less so with 'real-life footage'.
Now that I've done some more testing, I do see a quality increase in the 'real-life footage' encodes (so good job x265 team!),
but when encoding animated content -in my opinion so far- the quality doesn't visibly change while the extra encoding time is noticable..

[benwaggoner]

Originally Posted by stevendj

but when encoding animated content -in my opinion so far- the quality doesn't visibly change while the extra encoding time is noticable..

Animation is pretty easy to encode. If it's already looking pretty much dialed in, than encoder improvements aren't going to do visually. Try raising your CRF by 3 and redoing the comparison.

[stevendj]

Originally Posted by benwaggoner

Animation is pretty easy to encode. If it's already looking pretty much dialed in, than encoder improvements aren't going to do visually. Try raising your CRF by 3 and redoing the comparison.

Tried it, and even tried raising it by 6:
There is a small quality increase, but a ~30% slower encode by my testing. (I only ran 1 test with this higher crf, on animation)

Dear x265 Team, if in the future you would want to optimise x265 for animated content, I guess you should also look into how --rskip behaves on animation.

Edit: all you hard & good work is much appreciated, though!