x265 HEVC Encoder

[FranceBB]

The x265 encoder uses no GPU at all.

Exactly. I remember having this conversation before in 2015 when we were talking about x264-like OpenCl encoding acceleration. x265 team said that the encoder was still in the main phase of its development and many things were changing, so they didn't have time implement OpenCl. Now it's 2018, years passed, x265 has become a very good codec, with many enhancement since 2015. Perhaps it's time to implement OpenCl encoding acceleration?

[chen]

Because HEVC max qp is 51, i wonder if there's some special reason that x265 takes 69 as the max qp. Does someone have a clue?

[sneaker_ger]

Probably to control vbv emergency denoising.

[chen]

Probably to control vbv emergency denoising.

Oh, i see. Nice design. Thanks for the hint.

[3ngel]

Hi to all,
i've starting recently experimenting x265 as an alternative to x264
I've done a test to a clip with the same bitrate, and the result is not what i was hoping.

These are the screens

Original
http://thumbs2.imagebam.com/de/6c/8a/f8a907729052473.jpg (http://www.imagebam.com/image/f8a907729052473)

x264
--pass 1 --slow-firstpass --profile high --level 4.1 --preset veryslow --tune grain --bitrate 5414
--pass 2 --slow-firstpass --profile high --level 4.1 --preset veryslow --tune grain --bitrate 5414

http://thumbs2.imagebam.com/78/e3/d4/ea8af4729052553.jpg (http://www.imagebam.com/image/ea8af4729052553)

x265
--pass 1 --slow-firstpass --preset veryslow --tune grain --bitrate 5414
--pass 2 --slow-firstpass --preset veryslow --tune grain --bitrate 5414


avs [info]: AviSynth+ 0.1 (r1576, x64)
avs [info]: Video colorspace: YV12
avs [info]: Video resolution: 1920x816
avs [info]: Video framerate: 24000/1001
avs [info]: Video framecount: 205
avs4x26x [info]: "x265.exe" - --pass 1 --slow-firstpass --preset veryslow --tune
grain --bitrate 5414 -o 1pass.hevc --frames 205 --fps 24000/1001 --input-res 1
920x816 --input-csp i420
yuv [info]: 1920x816 fps 24000/1001 i420p8 unknown frame count
raw [info]: output file: 1pass.hevc
x265 [info]: HEVC encoder version 2.6+31-3712d13c09bf
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 B
MI2 AVX2
x265 [warning]: Rc Grain removes qp fluctuations caused by aq/cutree, Disabling
aq,cu-tree
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(13 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / off / on
x265 [info]: Rate Control / qCompress : ABR-5414 kbps / 0.60
x265 [info]: tools: rect amp limit-modes rd=6 psy-rd=4.00 rdoq=2 psy-rdoq=10.00
x265 [info]: tools: limit-tu=4 signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock stats-write

x265 [info]: frame I: 3, Avg QP:27.67 kb/s: 8761.29
x265 [info]: frame P: 30, Avg QP:27.57 kb/s: 5084.63
x265 [info]: frame B: 172, Avg QP:27.61 kb/s: 4393.54
x265 [info]: Weighted P-Frames: Y:3.3% UV:0.0%
x265 [info]: Weighted B-Frames: Y:5.8% UV:1.7%
x265 [info]: consecutive B-frames: 12.1% 0.0% 0.0% 9.1% 9.1% 21.2% 9.1% 18.2% 21
.2%

encoded 205 frames in 155.38s (1.32 fps), 4558.59 kb/s, Avg QP:27.60

-----
avs [info]: AviSynth+ 0.1 (r1576, x64)
avs [info]: Video colorspace: YV12
avs [info]: Video resolution: 1920x816
avs [info]: Video framerate: 24000/1001
avs [info]: Video framecount: 205
avs4x26x [info]: "x265.exe" - --pass 2 --slow-firstpass --preset veryslow --tune
grain --bitrate 5414 -o 2pass.hevc --frames 205 --fps 24000/1001 --input-res 1
920x816 --input-csp i420
yuv [info]: 1920x816 fps 24000/1001 i420p8 unknown frame count
raw [info]: output file: 2pass.hevc
x265 [info]: HEVC encoder version 2.6+31-3712d13c09bf
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 B
MI2 AVX2
x265 [warning]: Rc Grain removes qp fluctuations caused by aq/cutree, Disabling
aq,cu-tree
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(13 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / off / on
x265 [info]: Rate Control / qCompress : ABR-5414 kbps / 0.60
x265 [info]: tools: rect amp limit-modes rd=6 psy-rd=4.00 rdoq=2 psy-rdoq=10.00
x265 [info]: tools: limit-tu=4 signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock stats-read

x265 [info]: frame I: 3, Avg QP:25.33 kb/s: 13683.28
x265 [info]: frame P: 30, Avg QP:26.53 kb/s: 5932.95
x265 [info]: frame B: 172, Avg QP:26.47 kb/s: 5163.89
x265 [info]: Weighted P-Frames: Y:3.3% UV:0.0%
x265 [info]: Weighted B-Frames: Y:5.8% UV:1.7%
x265 [info]: consecutive B-frames: 12.1% 0.0% 0.0% 9.1% 9.1% 21.2% 9.1% 18.2% 21
.2%

encoded 205 frames in 160.23s (1.28 fps), 5401.11 kb/s, Avg QP:26.46

http://thumbs2.imagebam.com/46/8a/c0/e19d15729052633.jpg (http://www.imagebam.com/image/e19d15729052633)

As you can see, x264 does overally a better job than x265.
In particular you can see banding and more "encoding artifact".
Is this the expected behaviour at this stage of x265 development or I'm missing parameters?

Thank you very much for your work

[benwaggoner]

Hi to all,
i've starting recently experimenting x265 as an alternative to x264
I've done a test to a clip with the same bitrate, and the result is not what i was hoping.

These are the screens

Original
http://thumbs2.imagebam.com/de/6c/8a/f8a907729052473.jpg (http://www.imagebam.com/image/f8a907729052473)

x264
--pass 1 --slow-firstpass --profile high --level 4.1 --preset veryslow --tune grain --bitrate 5414
--pass 2 --slow-firstpass --profile high --level 4.1 --preset veryslow --tune grain --bitrate 5414

http://thumbs2.imagebam.com/78/e3/d4/ea8af4729052553.jpg (http://www.imagebam.com/image/ea8af4729052553)

x265
--pass 1 --slow-firstpass --preset veryslow --tune grain --bitrate 5414
--pass 2 --slow-firstpass --preset veryslow --tune grain --bitrate 5414


http://thumbs2.imagebam.com/46/8a/c0/e19d15729052633.jpg (http://www.imagebam.com/image/e19d15729052633)

As you can see, x264 does overally a better job than x265.
In particular you can see banding and more "encoding artifact".
Is this the expected behaviour at this stage of x265 development or I'm missing parameters?

Thank you very much for your work
--tune grain are designed pretty differently for x264 and x265 IIRC. I wouldn't expect identical results even at the same net psychovisual preference. And from the still it isn't obvious to me that --tune grain is appropriate for this source. I would probably have tried --tune film in x264 (which doesn't have a x265 preset implementation).

These are relatively subtle differences; can you see the difference when playing at full speed?

Also, these are pretty high bitrates for VBR in either case. The point of x265 is for bitrates where x264 isn't good enough. Maybe try 2000 to see some bigger differences.

[3ngel]

@benwaggoner

Thanks for the reply, i'll try --tune film out of my curiosity.

Concerning subtle differences, my concept was to use x265 for "archival purposes", but i realize reading more and more around that x265 currently (or by design?) isn't aimed toward "archival" (high bitrates) but for "streaming" (low bitrates) and you confirm this too

The point of x265 is for bitrates where x264 isn't good enough.

So i can conclude i have to remain on x264 for archival for now.

Thanks

[pradeeprama]

Is there a recommendation on using RADL? Is it something that can be safely used in all fixed-GOP encodes to potentially increase quality?

From the description, it sounds like the fundamental technology could also be used in variable duration Closed GOP as well.

We have some broadcast partners using 3-4 frames of RADL pictures reporting that it helps improve efficiency for them in closed GOP scenarios, and to switch between streams easily. I don't see any downside in using it for fixed-GOP encodes as long as the decoder on the downstream can support it.

[pradeeprama]

My raw picture size varies from time to time. For instance, I get 250 frames in 1080p for the first 10 secs, and then another 250 frames in 720p in the second 10 secs, and so on. And i need to encode all these frames into a same HEVC bit stream. I found no appropriate command line option, and thus looked into the apis. The x265_encoder_reconfig() seems to be a possible solution, but I am not sure. Can someone share some ideas or experiences?

x265 does not support changing resolution of the encode on the fly for a single instance of x265. Although this should be possible by just changing the resolution with a new SPS/PPS, from my experience, decoders don't always support this flawlessly in a single stream without a new VPS.

[mini-moose]

Hi

I'm trying x265 for the first time now.

Is pausing encode by clicking on the console window safe and won't cause any corruptions?

i.e touch to pause and then space bar to resume.

I've been told to use avs2pipemod64 to pipe x265 through. Don't know if that could have any effect on pausing.

thanks in advance.

[FranceBB]

@mini-moose... I did it accidentally more than once and it didn't corrupt my encode; everything resumed fine and the final output wasn't affected. I think x265 *just* waits for frames from the pipe to encode them. Clicking on the console prevents the pipe from processing frames, therefore x265 waits.

[Selur]

From my experience only thing that might be 'off' are encoding speed/time indications/estimations when pausing an encoding,...

[birdie]

@mini-moose

100% safe unless you press Ctrl + C which will simply terminate your encoding.

[mini-moose]

thanks for all the answers!

[dcxero]

Does anyone have any CLI tricks for cutting down on the grid of "squares" that pop up during encoding? I'm still trying out various options, trying to keep most options near placebo level, but this seems to be a common occurrence, am I misusing a switch?

Example, Source:
http://thumbs2.imagebam.com/e8/89/19/976108731537323.jpg (http://www.imagebam.com/image/976108731537323)

Encode
http://thumbs2.imagebam.com/1a/8f/55/eda72c731537283.jpg (http://www.imagebam.com/image/eda72c731537283)

--ctu 64 --bframes 8 --b-adapt 2 --rc-lookahead 60 --lookahead-slices 1 --ref 6 --limit-refs 0 --me 3 --merange 92 --subme 5 --rect --amp --limit-modes --max-merge 5 --no-rskip --no-fast-intra --b-intra --limit-sao --weightb --rd 6 --rdoq-level 2 --tu-intra-depth 4 --tu-inter-depth 4 --cbqpoffs -3 --crqpoffs -3 --deblock -3:-3 --no-strong-intra-smoothing --psy-rd 2.10 --psy-rdoq 4 --qcomp .75 --input-res 3840x2160 --fps 24000/1001 --aq-strength 1.00 --ipratio 1.3 --pbratio 1.2 --crf 16.5 --vbv-bufsize 160000 --vbv-maxrate 160000

[Taurus]

Sorry, my english is maybe bad.
But I cant see grid of "squares" in your pictures.
Just the normal encoding artefacts.
Your --input-res 3840x2160 and your posted images are 1280x720.
Even bumping up the monitor brightness and magnifying the png
shows no squares on my side.
Or maybe my eyesight is vanishing.
Just an old horse with dull eyes :D!

[Asmodian]

Does anyone have any CLI tricks for cutting down on the grid of "squares" that pop up during encoding?

-3 is probably too weak deblocking for x265, try -1 or -2 at most.

[microchip8]

-3 is probably too weak deblocking for x265, try -1 or -2 at most.

I doubt it, I use -3 for all my encodes and don't experience any blocking here

[dcxero]

-3 is probably too weak deblocking for x265, try -1 or -2 at most.

Cheers, that seemed to be it. I guess I assumed the deblocking was more like x264, but I ran the same CLI a dozen more times, only changing deblock between -3,-3 -2,-2... all the way back to +3,+3 and then disabled. +2,+2 had the least offensive blocking (practically none) while remaining closer to the source (+3,+3 started to alter it)

[microchip8]

Cheers, that seemed to be it. I guess I assumed the deblocking was more like x264, but I ran the same CLI a dozen more times, only changing deblock between -3,-3 -2,-2... all the way back to +3,+3 and then disabled. +2,+2 had the least offensive blocking (practically none) while remaining closer to the source (+3,+3 started to alter it)

I can't see any blocking in your image you posted. Maybe my display isn't good enough?

[jlpsvk]

any cons to using --no-deblock in CLI? i I want to preserve as much sharpness as ist gets? my CLI:

--crf 18 --profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --amp --vbv-bufsize 160000 --vbv-maxrate 160000
--me star --max-merge 5 --rc-lookahead 40 --lookahead-slices 4 --ref 5 --min-keyint 24 --keyint 240 --colorprim bt709
--colormatrix bt709 --transfer bt709 --no-info --no-deblock --no-sao --no-strong-intra-smoothing --high-tier

[dcxero]

I can't see any blocking in your image you posted. Maybe my display isn't good enough?

Maybe? I'm using a BenQ 2160p/10-bit (8-bit+RFC) display. I find it more prominent in grainy sources, here's a quick/better example which you might be able to see

Source:
http://thumbs2.imagebam.com/fb/5a/7c/b6a9ca732092083.jpg (http://www.imagebam.com/image/b6a9ca732092083)

-3,-3 deblock:
http://thumbs2.imagebam.com/11/33/39/0ffa8c732092103.jpg (http://www.imagebam.com/image/0ffa8c732092103)

+2,+2 deblock:
http://thumbs2.imagebam.com/5e/67/39/ab7854732092133.jpg (http://www.imagebam.com/image/ab7854732092133)

[microchip8]

Maybe? I'm using a BenQ 2160p/10-bit (8-bit+RFC) display. I find it more prominent in grainy sources, here's a quick/better example which you might be able to see

Source:
http://thumbs2.imagebam.com/fb/5a/7c/b6a9ca732092083.jpg (http://www.imagebam.com/image/b6a9ca732092083)

-3,-3 deblock:
http://thumbs2.imagebam.com/11/33/39/0ffa8c732092103.jpg (http://www.imagebam.com/image/0ffa8c732092103)

+2,+2 deblock:
http://thumbs2.imagebam.com/5e/67/39/ab7854732092133.jpg (http://www.imagebam.com/image/ab7854732092133)

Still can't see it. All I can see is that the +2 one looks smoother than the -3 one. Can't see blocking, though. But indeed, the +2 one is closer to the source

Anyways, if you're happy with +2, use it :p

[dcxero]

Still can't see it.

You definitely need a new monitor then! :D

I suppose it's harder to see if you look at it unless zooming, or blown up on a TV/projector. Try flipping back and forth between the source image zoomed in, there's a faint grid of squares about 16x16 pixels wide across the whole image

It seems to be something inherent to HEVC (or just more noticeable), because I've seen it in some retail UHD discs as well (unless they're just using x264 too! :cool:)

[microchip8]

You definitely need a new monitor then! :D

I suppose it's harder to see if you look at it unless zooming, or blown up on a TV/projector. Try flipping back and forth between the source image zoomed in, there's a faint grid of squares about 16x16 pixels wide across the whole image

It seems to be something inherent to HEVC (or just more noticeable), because I've seen it in some retail UHD discs as well (unless they're just using x264 too! :cool:)

Perhaps. My monitor is a plain 6 bit+FRC from AOC (LG Display panel). My TV has a PVA panel (Samsung) at true 8 bits

I don't have any 4K displays here, all are FHD and on FHD I can't see it on any of my displays

[burfadel]

It doesn't look like a true transfer from the film original. Is it The Fifth Element? It's a movie I thought they would have done a proper 4k transfer for. The grain doesn't help much either, as the grain acts as detail that needs to be encoded. If it changes each frame it is probably using most of the bandwidth and bit allocation for the grain and not the actual picture. I think you'll find using a denoiser first could greatly improve the success of your output. Maybe give my mClean (v2.1) a go? https://forum.doom9.org/showthread.php?t=174804

I'm not specifically spruiking my script! This situation is just one of many that it is designed to help with. You will need to use the latest Avisynth+, updated RGTools, MVTools, Masktools, Modplus, f3kdb, as the script utilises new functions that weren't available in older versions of these. It's designed in such a way that the base settings should be adequate and retain some grain in a way that it will be more encoder bit friendly.

[Sp00kyFox]

hi there. I was wondering what are the thoughts about the aq-motion option regarding cartoon or anime content. In my experience it's beneficial to use with real world content where the higher quantization of moving parts is masked by the motion blur they introduce. but with drawn content moving parts are usually as sharp as still areas. I made a little encoding test to see the effect on bitrate and with drawn content it doesn't seem to do much anyways. any experiences with this option here?

[divxmaster]

@burfadel, thats interesting, I will have to check your filter out! I am currently getting very good results with smdegrain:

vid = haf.SMDegrain(vid, tr=3,thSAD=150,RefineMotion=True,contrasharp=True,pel=2)

varying thSAD from 100-400 depending on grain, or smdegrain off if no grain (ironman3, Star Trek Beyond).

Cheers,
Divxmaster

[WhatZit]

any cons to using --no-deblock in CLI? i I want to preserve as much sharpness as it gets?

http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6324414

The --deblock loop filter uses a PAIR of values that correspond to STRENGTH,DECISION.

STRENGTH needs no explanation, but DECISION (literally) decides how often to employ the filter on coding units.

The default value of 0 activates on relatively balanced values between the block boundaries.

The maximum value of 6 activates on ALL block boundaries regardless of disparity, producing whole-scene smoothing.

The minimum value of -6 activates only on those block boundaries which have significant threshold disparity, producing virtually no deblocking on anything other than already unwatchable artifacts.

To answer your question, unless you are using a high enough bitrate to never create blocking artifacts in the first place, you should always have some level of deblocking active (even -6,-6), because blocking is something that the eye just spots immediately.

To figure out what values the filter should be set to FOR YOU and your bitrates, get yourself a high-detail sample with stationary foreground elements & rapidly moving background elements. A sunny panning shot of people running in front of plants or other complex backgrounds is perfect.

Adjust DECISION until the background blocking stops (or is acceptable) whilst the foreground remains untouched. Then adjust STRENGTH to suit.

I personally use -2,-3.

[LigH]

A sunny panning shot of people running in front of plants or other complex backgrounds is perfect.

For short lossless clips, check derf's collection at xiph.org (https://media.xiph.org/video/derf/), in sections "HD Content and Above" and below, e.g. "crowd_run", "rush_field_cuts", or something with a water surface.
__

The "founder and chairman of MPEG", Leonardo Chiariglione, discovered that the patent licensing model gets obsolete (http://blog.chiariglione.org/2018/01/28/) with the success of OpenSource media formats like Opus audio and soon AOMedia AV1 video ... all the investments for an uncertain future of MPEG technologies. Including HEVC.

No immediate reason for Multicoreware to panic, I believe. Established uses of MPEG technologies won't disappear quickly. And when their substitution with more advanced and free OpenSoure formats comes closer, it's not improbable that their development gets paid for as well.
__

P.S.: Holding back new builds until [PATCH] CMake: blacklist mingw implicit link libraries gets committed. If I understand its intention correctly, this should slim down the binary base a little by avoiding superfluous linked libraries?

[jlpsvk]

http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6324414

The --deblock loop filter uses a PAIR of values that correspond to STRENGTH,DECISION.

STRENGTH needs no explanation, but DECISION (literally) decides how often to employ the filter on coding units.

The default value of 0 activates on relatively balanced values between the block boundaries.

The maximum value of 6 activates on ALL block boundaries regardless of disparity, producing whole-scene smoothing.

The minimum value of -6 activates only on those block boundaries which have significant threshold disparity, producing virtually no deblocking on anything other than already unwatchable artifacts.

To answer your question, unless you are using a high enough bitrate to never create blocking artifacts in the first place, you should always have some level of deblocking active (even -6,-6), because blocking is something that the eye just spots immediately.

To figure out what values the filter should be set to FOR YOU and your bitrates, get yourself a high-detail sample with stationary foreground elements & rapidly moving background elements. A sunny panning shot of people running in front of plants or other complex backgrounds is perfect.

Adjust DECISION until the background blocking stops (or is acceptable) whilst the foreground remains untouched. Then adjust STRENGTH to suit.

I personally use -2,-3.

I am using CRF16 with x265 4K HDR encodes. So the bitrate is not limiting, i think. :)

[Midzuki]

x265.exe 2.6+37-1949157705ce

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2510642#post2510642

[Barough]

x265 v2.6+37-1949157705ce (http://www.mediafire.com/file/kzkmtkg0wa8nou6/) (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

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

[LigH]

@Barough - interesting, your version info strings still work:

x265 [info]: HEVC encoder version 2.6+37-1949157705ce
x265 [info]: build info [Windows][GCC 7.3.0][64 bit] 8bit+10bit+12bit

Mine only display "(null)". Possibly because my MSYS2 environment updated to a buggy binutils version or similar... I hope the MABS developers will find a workaround until the package providers offer updates.

[Barough]

@LigH - I ran the update on MABS today and it updated just fine. Have done 2 test encodes with the new x265 through MeGUI and it worked perfect

[Ma]

@LigH - the bug in binutils 2.30 for mingw target is huge, the compiler cannot create executables. If you build the x265.exe encoder it means you probably use binutils 2.29.1.

Mercurial was moved from mercurial.selenic.com to mercurial-scm.org and this is prime suspect for the problem. You can try to execute hg clone https://bitbucket.org/multicoreware/x265 from msys2 shell to some new location and use new x265 folder only with new version of HG (from msys2).

[LigH]

I can build it ... despite:
[2018-01-29 21:24] [ALPM] upgraded mingw-w64-x86_64-binutils (2.29.1-1 -> 2.30-1)
If I knew how to tell the MSYS2 environment of MABS to downgrade, I could do that. And I am pretty sure that wiiaboo knows about this issue.

And because updating x265 failed with an "unresolved merge", I recently let the whole x265 source get cloned anew, by deleting the whole build/x265-hg directory.

There is a new proposed patch to generate the hg version information in a different way, this is not yet committed.

It's so confusing ... so many reasons why the base system of two users can be different enough that doing the same which is supposed to bring both systems to the same state still produces different results.

[LigH]

After re-installing MABS completely, which updated only to binutils-2.29, version strings are back. Other important changes:

32-bit builds made with GCC can open large files too; MinGW compiles exclude some superfluous libraries; fixes in special conditions with BREF frames, rate control with both weightp and cutree, and unnecessary luma calculations in CSV output

x265 2.6+37-1949157705ce (https://www.mediafire.com/file/ix8c963vei5mk65/x265_2.6%2B37-1949157705ce.7z) (MSYS2/MinGW, GCC 7.3.0)

[Motenai Yoda]

I would suggest a possible tune animation:
aq-mode 3 aq-strength 0.6 aq-motion qg-size 16 rc-lookahead +20 psy-rd 1.2 rdoq-level 2 psy-rdoq 0.3 deblock 1:-1 cbqpoffs -1 crqpoffs -1
under evalutation (some unclear detail loss)
ref +1 bframes +2

[Ma]

I would suggest a possible tune animation:

I've prepared first version of anime patch with main part:
+ else if (!strcmp(tune, "anime"))
+ {
+ param->rc.aqMode = 3;
+ param->rc.aqStrength = 0.6;
+ param->bAQMotion = 1;
+ param->rc.qgSize = 16;
+ param->lookaheadDepth += 20;
+ param->psyRd = 1.2;
+ param->rdoqLevel = 2;
+ param->psyRdoq = 0.3;
+ param->bEnableLoopFilter = 1;
+ param->deblockingFilterTCOffset = 1;
+ param->deblockingFilterBetaOffset = -1;
+ param->cbQpOffset = -1;
+ param->crQpOffset = -1;
+ }
Windows binaries for testing + patch file anime.7z (http://msystem.waw.pl/x265/anime.7z)

[Motenai Yoda]

I'd rather be glad to take into account somebody else's opinion about it too

[LigH]

With a readily provided test encoder, that's easier than in theory. :) Or with lengthy CLI param lists.

[Ma]

From my tests the option '--qg-size 16' is broken -- in all bitrates decrease quality.
I don't like '--aq-motion', so my 'anime' proposition is:
--rc-lookahead *= 2;
--psy-rd /= 2;
--keyint *= 2;
if (rdoq-level > 0)
{
--cbqpoffs -1; --crqpoffs -1;
}
if (preset >= 7) // slower, veryslow & placebo
{
--frame-threads 1;
}

[Arhu]

I always use aq-mode 3 (10 bit) but regularly had banding issues with aq-strength < 1. Could anyone else observe this?

[LigH]

MSYS2 released binutils-2.30-2; static binaries should work again.

[Ma]

I've made some tests about '--qg-size'. For my eyes '--qg-size 32' is better than '--qg-size 16'. After checking all possible values (8, 16, 32 and 64) the best is 64 (PSNR/SSIM and for my eyes). It is a bit strange, the default value in x265 is 32.

My test was encoding first 2222 frames of big_buck_bunny_1080p24.y4m with preset slower, tune anime (which I renamed to cartoon), 10-bit output, ABR mode with bitrates: 300, 450, 750, 1200 and 1950, qg-size from 8 to 64.
Command line:
for %b in (300 450 750 1200 1950) do (for %q in (8 16 32 64) do
(x265 -D10 --psnr --ssim -p7 -f2222 --tune cartoon --bitrate %b --qg-size %q ../big_buck_bunny_1080p24.y4m m%b-%q.hevc))

The result Global PSNR/SSIM Mean Y dB is (bitrate\qg-size):

8 16 32 64
300 37.554/11.452 37.538/11.520 37.643/11.568 37.781/11.638
450 39.056/12.742 39.026/12.781 39.143/12.843 39.281/12.907
750 40.993/14.407 40.962/14.445 41.099/14.522 41.225/14.559
1200 42.835/16.004 42.802/16.032 42.958/16.117 43.065/16.136
1950 44.746/17.661 44.713/17.692 44.866/17.774 44.950/17.781


Samples to watch:
bitrate 300: qg-size 16 (http://msystem.waw.pl/x265/m300-16.mkv), qg-size 64 (http://msystem.waw.pl/x265/m300-64.mkv)
bitrate 450: qg-size 16 (http://msystem.waw.pl/x265/m450-16.mkv), qg-size 64 (http://msystem.waw.pl/x265/m450-64.mkv)

So my question is: what should I look at to see the advantages of qg-size 16?

[Selur]

It is a bit strange, the default value in x265 is 32.
Hmm,....
--qg-size <64|32|16|8>

Enable adaptive quantization for sub-CTUs. This parameter specifies the minimum CU size at which QP can be adjusted, ie. Quantization Group size. Allowed range of values are 64, 32, 16, 8 provided this falls within the inclusive range [maxCUSize, minCUSize]. Default: same as maxCUSize
source: http://x265.readthedocs.io/en/latest/cli.html?highlight=qg-size#cmdoption-ctu
--ctu, -s <64|32|16>

Maximum CU size (width and height). The larger the maximum CU size, the more efficiently x265 can encode flat areas of the picture, giving large reductions in bitrate. However this comes at a loss of parallelism with fewer rows of CUs that can be encoded in parallel, and less frame parallelism as well. Because of this the faster presets use a CU size of 32. Default: 64
source: http://x265.readthedocs.io/en/latest/cli.html?highlight=qg-size#cmdoption-ctu

-> Shouldn't the default be 64 and not 32?

[LigH]

I remember that there was an issue with 64 (loss of details, or improper segmentation?)... but I do not remember if it was fixed yet.

[Ma]

In documentation the default value of qg-size is 64, in real code it is 32. 'x265 --help' prints options and default values, if you encode there is line
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
It was probably changed from 64 to 32 and the documentation is not updated.
Anyway, the 32 value is a bit strange for me.
-----------
It was changed in 2015-08-03 by https://bitbucket.org/multicoreware/x265/commits/dc5d58411210549d288b991ccfc4da4450e9f84e

[Selur]

@Ma: thanks for the insight

Cu Selur