x265 HEVC Encoder

[need4speed]

Hi all, great improvements lately with newer versions, so thanks for starters.
Have a question; tried different settings and tweaks but still having issues with crf. Basically I am encoding avc TV series, 1080p mkv, so to save disk space. I know it's not a good practice but, still...
Ok so I am dealing mainly with 5000 to 13000 kbs mkv video rate, trying to save say 40% in terms of final video size.
First tried 2pass Abr, 4000kbs,tune grain and aq motion. Other settings are mainly default, except for nosao, no strong intrasmoothing, no Deb lock and me star.
Results are pretty good for my needs. A bit too slow so I tried to move on to crf.
I often get too low final bitrate, results nice but not satisfactory.
So question is: there is any way to set minimum bitrate in crf mode? Can't really find it. Ideally would like to set a proper range, say 3000 min 4500 max and distribute bitrate in a smart way, so to speak.
Many thanks for any idea or suggestions!

Inviato dal mio GT-N7100 utilizzando Tapatalk

[LigH]

CRF means: The encoder will try to guarantee that the quality loss will stay below a certain level. But it will only take as much bitrate as it really needs to preserve enough quality. Requesting more bitrate would only waste space without additional value. Clinging to a bitrate range is usually not optimal; it does not reflect the diversity of video material (e.g. talk shows or landscape stills with little motion need a lot less bitrate to preserve the same quality, compared to action movies).

So the other direction may be suitable: Decrease your preferred CRF value a bit to preserve better quality, but limit the maximum bitrate. This is usually achieved best by specifying VBV limits.

[Romario]

CRF means: The encoder will try to guarantee that the quality loss will stay below a certain level. But it will only take as much bitrate as it really needs to preserve enough quality. Requesting more bitrate would only waste space without additional value. Clinging to a bitrate range is usually not optimal; it does not reflect the diversity of video material (e.g. talk shows or landscape stills with little motion need a lot less bitrate to preserve the same quality, compared to action movies).

So the other direction may be suitable: Decrease your preferred CRF value a bit to preserve better quality, but limit the maximum bitrate. This is usually achieved best by specifying VBV limits.
Can you tell me one example, so that I see how that work? Thanks in advance.

Other thing now.

Can I use denoise filter, make that any sense? To have better quality encodes, of course.

And which denoise filter is best?

Gesendet von meinem GT-I9295 mit Tapatalk

[aymanalz]

Can you tell me one example, so that I see how that work? Thanks in advance.

Other thing now.

Can I use denoise filter, make that any sense? To have better quality encodes, of course.

And which denoise filter is best?

Gesendet von meinem GT-I9295 mit Tapatalk

x265 has an internal denoiser that you can apply, and it works very fast. But if you want high quality denoising, you should apply avisynth scripts like nlmeans or knlmeans.

For the x265 noise reduction, use command line --nr-inter <integer> and --nr-intra <integer>.

[WhatZit]

So question is: there is any way to set minimum bitrate in crf mode? Can't really find it. Ideally would like to set a proper range, say 3000 min 4500 max and distribute bitrate in a smart way, so to speak.

Have a read through this: x265 Quality, Rate Control & Rate Distortion Options (http://x265.readthedocs.io/en/default/cli.html#quality-rate-control-and-rate-distortion-options)

You might like to experiment with the --crf-max option. EDIT: Doesn't work in CRF mode unless you enable VBV, apparently! (https://bitbucket.org/multicoreware/x265/issues/61/vbv-crf-min-max-level-profile-tier) Ditto for below.

Can you tell me one example, so that I see how that work? Thanks in advance.

Make sure you understand the consequences described in that manual section when combining video buffer verification with constant rate factors.

Without using VBV, LigH's CRF suggestion above would be something like --crf 19 --crf-min 17

[need4speed]

Have a read through this: x265 Quality, Rate Control & Rate Distortion Options (http://x265.readthedocs.io/en/default/cli.html#quality-rate-control-and-rate-distortion-options)

You might like to experiment with the --crf-min option.



Make sure you understand the consequences described in that manual section when combining video buffer verification with constant rate factors.

Without using VBV, LigH's CRF suggestion above would be something like --crf 19 --crf-max 17
Many thanks to you and light, have gone through the whole white papers reading and was/am still somehow confused about all parameters and, above all, dependencies.
Still, have tried in the meantime some other tweaks with crf and, to recap:
Two pass Abr works better than crf.
I know this is all personal perception and its OK. BUT two pass is really too slow,guess I'll have to cope with that.
Will try crf min.
Thanks again!
BTW, have tried crf 19, aqmotion and rskip,me star. What is weird is that out of two tests the final result is totally spoiled. 1,6 gigs turned into 125 megs. Totally wrong! Just for the record really but wondering if I did anything wrong since rskip gave me a totally acceptable fps conversion speed.

Inviato dal mio GT-N7100 utilizzando Tapatalk

[WhatZit]

BUT two pass is really too slow,guess I'll have to cope with that.

That's the main reason why I stopped using it. In fact, my original .bat used 3-pass, with little improvement for the extra time spent.

Still, the new processors on the market may change the ABR situation for the better...

Will try crf min

I don't use those CRF min/max options, but I do remember experimenting with them once and noticed no difference. Hope you have better luck.

EDIT: Found something interesting about the seemingly non-functional crf min/max: https://bitbucket.org/multicoreware/x265/issues/61/vbv-crf-min-max-level-profile-tier

Used only for ABR/VBV? The Feb 17, 2017 manual still hasn't clarified this.

[x265_Project]

We've been experimenting with new lambda tables, which are the set of constants that are used to determine the relative importance given to bit rate vs. distortion, as candidate modes and motion vectors are evaluated for each block of video. We think there is an opportunity for improvement, but as with everything we do, we care only about subjective visual quality and not objective measures of quality (PSNR, SSIM, etc.). So, this means we have a lot of testing to do, with a wide variety of video test content, at a wide range of quality levels. Since x265 is open source, we can crowd-source some of the testing and feedback.

If you're interested, we would welcome your feedback with one of our candidate lambda tables.

Use the attached file, removing the .txt from the file name to save as a Comma Separated Value (.csv) file.

Then, run an 8 bit encode using the default x265, and run a 2nd encode using --lambda-file x265-NewLambdaTable.csv (pointing to this new csv file). Note that a constant QP or CRF encode will probably be larger than your default encode, so to fairly evaluate the new lambda table you need to do 2 pass encodes in both cases (you can use --no-slow-firstpass in --pass 1, to speed things up). If you're used to heavily modifying your command line, we would suggest that you don't for these tests (stick with a --preset).

Compare the visual quality of x265 today with x265 with the new lambda table, and let us know which one you prefer.

Again... this is for 8 bit encodes only. Bit rates of --qp or --crf encodes will be affected, so use 2 pass encodes to produce A/B test encodes of equal file size that you can compare.

Thanks.

[need4speed]

If you're interested, we would welcome your feedback with one of our candidate lambda tables.

Simply copy and paste the values below into a spreadsheet application, then save as a Comma Separated Value (.csv) file. Or you can use a text editor, putting a comma between each value.



Again... this is for 8 bit encodes only. Bit rates of --qp or --crf encodes will be affected, so use 2 pass encodes to produce A/B test encodes of equal file size that you can compare.

Thanks.

[/CODE]

Hi, will try in few minutes when I get some confirmations:
This is my line in Staxrip, can you please check if anything wrong?

--pass 1 --bitrate 4000 --preset fast --qcomp 0.7 --crf-min 18 --crf-max 21 --me star --no-strong-intra-smoothing --range limited --no-deblock --lambda-file "C:\Users\zione\Desktop\lamba.csv" --no-sao --no-slow-firstpass --aq-motion

[x265_Project]

Hi, will try in few minutes when I get some confirmations:
This is my line in Staxrip, can you please check if anything wrong?

--pass 1 --bitrate 4000 --preset fast --qcomp 0.7 --crf-min 18 --crf-max 21 --me star --no-strong-intra-smoothing --range limited --no-deblock --lambda-file "C:\Users\zione\Desktop\lamba.csv" --no-sao --no-slow-firstpass --aq-motion

Stick with --preset fast, and drop the --qcomp 0.7 --crf-min 18 --crf-max 21 --me star --no-strong-intra-smoothing --range limited --no-deblock --no-sao --aq-motion

To do 2 pass encodes, you need to run 2 separate encoding passes.

1st pass: x265 [input options, bitrate, preset] --pass 1 --no-slow-firstpass
2nd pass: x265 [input options, bitrate, preset] --pass 2

I haven't used Staxrip, so I may not be the best advisor here.

[need4speed]

Stick with --preset fast, and drop the --qcomp 0.7 --crf-min 18 --crf-max 21 --me star --no-strong-intra-smoothing --range limited --no-deblock --no-sao --aq-motion

To do 2 pass encodes, you need to run 2 separate encoding passes.

1st pass: x265 [input options, bitrate, preset] --pass 1 --no-slow-firstpass
2nd pass: x265 [input options, bitrate, preset] --pass 2

I haven't used Staxrip, so I may not be the best advisor here.

Thanks, to be honest have tried with my seetings and 2pass, new file as suggested. There is quite a difference and it is not remarkable but quite indicative, both in terms of encoding speed (dont know if this is supposed to happen, about 12-15%) and final perceived quality. I am not a pixel peeper but checking some screenshots I see a difference, not really big but noticeable.

Will try to stick to presets as suggested but need some help on how to set up staxrip as requested, especially setting pass1 and pass2 differently.
Thanks again

[x265_Project]

Updated the lambda table above... please give this a try.

[need4speed]

Updated the lambda table above... please give this a try.
Will in a couple of hours, would it be possible to have the command line to input for fast and bitrate 4000?
TIA

Inviato dal mio GT-N7100 utilizzando Tapatalk

[need4speed]

Updated the lambda table above... please give this a try.

hmm..something wrong here.
Same everything, was workins ok with old values, here's what I get when updated csv file:

***************************************

Error Encoding video using x265 2.3+8 x64 multi lib 8/10/12 bit

Encoding video using x265 2.3+8 x64 multi lib 8/10/12 bit failed with exit code: 2 (0x2)

The exit code might be a system error code: STATUS_WAIT_2

The exit code might be a system error code: Impossibile trovare il file specificato.

y4m [info]: 1912x1072 fps 24000/1001 i420p8 unknown frame count
raw [info]: output file: NUL
x265 [info]: HEVC encoder version 2.3+8-cfaff341e350
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-4 (High tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(17 rows)
x265 [error]: lambda file contains too many values
x265 [error]: failed to open encoder
avs2pipemod[info]: writing 27960 frames of 24000/1001 fps, 1912x1072,
sar 0:0, YUV-420-planar-8bit progressive video.
avs2pipemod[info]: finished, wrote 1 frames [0%].
avs2pipemod[info]: total elapsed time is 0.016 sec.
avs2pipemod[error]: only wrote 1 of 27960 frames.



StaxRip.ErrorAbortException: Encoding video using x265 2.3+8 x64 multi lib 8/10/12 bit failed with exit code: 2 (0x2)

The exit code might be a system error code: STATUS_WAIT_2

The exit code might be a system error code: Impossibile trovare il file specificato.

y4m [info]: 1912x1072 fps 24000/1001 i420p8 unknown frame count
raw [info]: output file: NUL
x265 [info]: HEVC encoder version 2.3+8-cfaff341e350
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-4 (High tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(17 rows)
x265 [error]: lambda file contains too many values
x265 [error]: failed to open encoder
avs2pipemod[info]: writing 27960 frames of 24000/1001 fps, 1912x1072,
sar 0:0, YUV-420-planar-8bit progressive video.
avs2pipemod[info]: finished, wrote 1 frames [0%].
avs2pipemod[info]: total elapsed time is 0.016 sec.
avs2pipemod[error]: only wrote 1 of 27960 frames.


in StaxRip.Proc.Start() in D:\Projekte\VS\VB\StaxRip\General\Proc.vb:riga 240
in StaxRip.x265Encoder.Encode(String passName, String batchCode, ProcessPriorityClass priority) in D:\Projekte\VS\VB\StaxRip\Encoding\x265.vb:riga 74
in StaxRip.x265Encoder.Encode() in D:\Projekte\VS\VB\StaxRip\Encoding\x265.vb:riga 43
in StaxRip.MainForm.Encode() in D:\Projekte\VS\VB\StaxRip\Forms\MainForm.vb:riga 2245
in StaxRip.MainForm.RunJobRecursive() in D:\Projekte\VS\VB\StaxRip\Forms\MainForm.vb:riga 3506

[x265_Project]

hmm..something wrong here.
Same everything, was workins ok with old values, here's what I get when updated csv file:

I've revised my post, attaching a txt file that you can use. Just remove the .txt file extension to convert this to a .csv file.

[need4speed]

I've revised my post, attaching a txt file that you can use. Just remove the .txt file extension to convert this to a .csv file.

Thanks, was revising the two original files and in the second one there was an additional line.
Will try newer file in a sec.
UPDATE: file is working ok now, encoding.
Btw, could I add nosao nodebloock nostrongintrasmoothing to the preset fast at present time? The file encoded with original table was somehow more defined and blurred at the same time..cant really explain without adding screenshots (maybe later) but the signs and writings etc were more defined and clearer, somehow faces were more blurred than usual. Hard to explain but this was something I have noticed immediately. MY PERSONAL OPINION of course!

[sneaker_ger]

Then, run an 8 bit encode using the default x265, and run a 2nd encode using --lambda-table x265-NewLambdaTable.csv (pointing to this new csv file).
It's --lambda-file, not --lambda-table.

[need4speed]

I've revised my post, attaching a txt file that you can use. Just remove the .txt file extension to convert this to a .csv file.
Ok,
I have run some tests with a 20mins tv episode mkv, just to check main differences as for the encoding sessions I usually run.
The attached file is producing better results than the former one, fast profile as is and adding only no slow firstpass.
Anywyas the best outcome is adding some additional tweaks as for one of my previous messages, specifically:
--pass 1 --bitrate 4000 --preset fast --qcomp 0.7 --aq-motion --no-strong-intra-smoothing --no-deblock --lambda-file "C:\Users\zione\Desktop\x265-NewLambdaTable.csv" --no-sao --no-slow-firstpass
This is really making a difference, not huge but it works great for my needs.
Usually I encode in 10bits, is or will this be possible?
So far thanks for your tweaks, in case I can upload samples with different settings if needed.
For the record I7 3700 is now about 15 fps, definitely good.
Again, I am not a pixel peeper and am not interested in a "perfect" result but these settings and your file is giving out really nice files.
Will try again with some files encoded originally 13/15 mbs avc.
I am still using staxrip 1407 and no issues so far,together with HEVC encoder version 2.3+8-cfaff341e350

[x265_Project]

It's --lambda-file, not --lambda-table.
Good catch. Fixed. Thanks.

[x265_Project]

The new lambda table posted here should improve the level of detail in any encode at any bit rate. Keep in mind that the "level of detail" you see in an H.264 encode may include energy that looks like actual detail, but is actually noise (fine-grained macroblocking artifacts). So H.265 encodes generally tend to look like they have less detail, because they have less high frequency energy in the decoded signal. We don't try to produce the maximum level of high frequency energy, we try to produce the most accurate representation possible, including both spatial detail and motion (temporal) accuracy.

We're going to update x265 (development branch) to include this new lambda table, starting with 8 bit builds. Similarly, we'll optimize and update the 10 and 12 bit lambda tables, as soon as possible. There are a number of adjustments we have to make to x265 when we change the lambda table, so this takes a bit of time to do all of the necessary testing and tuning.

[need4speed]

We're going to update x265 (development branch) to include this new lambda table, starting with 8 bit builds. Similarly, we'll optimize and update the 10 and 12 bit lambda tables, as soon as possible. There are a number of adjustments we have to make to x265 when we change the lambda table, so this takes a bit of time to do all of the necessary testing and tuning.

As for detail retention and AVC files I have no complains, meaning that my only goal is keeping as much quality as possible and decrease file size, so I fully understand limitations.
Still, the perceived quality with new table is higher than the old values, hence this is something that definitely helps x265 improvement. I assume the benefits will be similar for better material as well.
Will be waiting for the 10bits tables, but for the time being keep up with the good job 'cause we definitely have something here!
Thanks again!

[sneaker_ger]

I did a short lambda test. Had to search a bit for frames with some pronounced differences. New lambda was a bit better.

https://abload.de/img/source_yvu0k.png
https://abload.de/img/default_69ul1.png
https://abload.de/img/newtable_jiu1w.png

[brumsky]

The new lambda table posted here should improve the level of detail in any encode at any bit rate. Keep in mind that the "level of detail" you see in an H.264 encode may include energy that looks like actual detail, but is actually noise (fine-grained macroblocking artifacts). So H.265 encodes generally tend to look like they have less detail, because they have less high frequency energy in the decoded signal. We don't try to produce the maximum level of high frequency energy, we try to produce the most accurate representation possible, including both spatial detail and motion (temporal) accuracy.

We're going to update x265 (development branch) to include this new lambda table, starting with 8 bit builds. Similarly, we'll optimize and update the 10 and 12 bit lambda tables, as soon as possible. There are a number of adjustments we have to make to x265 when we change the lambda table, so this takes a bit of time to do all of the necessary testing and tuning.

I can't wait for the 10 it tables!! Thanks and great job as always!

[x265_Project]

If you have heavily customized your x265 encoding parameters in order to improve the level of detail, I would suggest trying a 2 pass encode with the new lambda table with your favorite --preset, comparing it to a 2 pass encode without the new lambda table. Some of the tendencies of x265 that you may have been trying to correct for may be addressed by this new lambda table. We look forward to your feedback.

[x265_Project]

I did a short lambda test. Had to search a bit for frames with some pronounced differences. New lambda was a bit better.

https://abload.de/img/source_yvu0k.png
https://abload.de/img/default_69ul1.png
https://abload.de/img/newtable_jiu1w.png
Thanks for your feedback. The differences are pretty subtle, since you're obviously using a decent bit rate. The difference between the old lambda table and the new one are easier to see at lower bit rates.

[Magik Mark]

I'm sorry what is the syntax for lamda? Any parameters?


Sent from my iPhone using Tapatalk

[LigH]

@ Magic Mark:

Mixing replies from x265_Project (https://forum.doom9.org/showthread.php?p=1800669#post1800669) and need4speed (https://forum.doom9.org/showthread.php?p=1800796#post1800796):

1st pass: x265 [input options, bitrate, preset] --pass 1 --lambda-file x265-NewLambdaTable.csv --no-slow-firstpass
2nd pass: x265 [input options, bitrate, preset] --pass 2 --lambda-file x265-NewLambdaTable.csv

[Magik Mark]

Thanks. How do I do this in staxrip? Where can I get the lamda file? Which version of x265 is supported?


Sent from my iPhone using Tapatalk

[need4speed]

@ Magic Mark:

Mixing replies from x265_Project (https://forum.doom9.org/showthread.php?p=1800669#post1800669) and need4speed (https://forum.doom9.org/showthread.php?p=1800796#post1800796):

1st pass: x265 [input options, bitrate, preset] --pass 1 --lambda-file x265-NewLambdaTable.csv --no-slow-firstpass
2nd pass: x265 [input options, bitrate, preset] --pass 2 --lambda-file x265-NewLambdaTable.csv
Thanks Ligh, I stick to Staxrip and first pass is OK, checking logs second pass is not picking up the specified settings, can you point me to the rifmght direction please?
I have no problem switching to cli a nd, guess ffmpeg but need some directions here as well.
Have read some white papers but can't figure it out

Inviato dal mio GT-N7100 utilizzando Tapatalk

[sneaker_ger]

You should be able to use --no-slow-firstpass on all passes if your GUI does not support different options for different passes. If should just be ignored in the 2nd pass, then.

Thanks. How do I do this in staxrip? Where can I get the lamda file?
https://forum.doom9.org/showpost.php?p=1800604&postcount=4957
In StaxRip's "Other 2" x265 option you can choose the lambda file.

[need4speed]

Thanks Ligh, I stick to Staxrip and first pass is OK, checking logs second pass is not picking up the specified settings, can you point me to the rifmght direction please?
I have no problem switching to cli a nd, guess ffmpeg but need some directions here as well.
Have read some white papers but can't figure it out

Inviato dal mio GT-N7100 utilizzando Tapatalk
Basically in Staxrip where can I specify settings for second pass?

Inviato dal mio GT-N7100 utilizzando Tapatalk

[pradeeprama]

The updated lambda2 table for 8-bit are pushed in now into the default branch. You can build at changeset db5e22b856f5 to get the updated encoder.

Feedback from more testing is welcome!

[stax76]

Thanks. How do I do this in staxrip? Where can I get the lamda file?

All codec dialogs have a search input box at the bottom of the dialog.

The Search input field can be used to search for options, it searches in the switch, the label and the help. Multiple matches can be cycled by pressing enter.

[Midzuki]

x265.exe 2.3+22-db5e22b856f5

http://www.mediafire.com/file/ak31a1i5oj2o9rj/x265_2.3+22-db5e22b856f5.7z

[pingfr]

@Midzuki: Thanks for the precompiled binary!

@x265_Project & @LigH: Any newer parameters we should pass to the 2.3+22 build in order to benefit on the new improved subjective visual quality algorithm?

[x265_Project]

@Midzuki: Thanks for the precompiled binary!

@x265_Project & @LigH: Any newer parameters we should pass to the 2.3+22 build in order to benefit on the new improved subjective visual quality algorithm?

Just try it with your favorite default preset first. Do a 2 pass encode, to match the bit rate to one of your earlier encodes, and then compare the quality.

[pingfr]

Just try it with your favorite default preset first. Do a 2 pass encode, to match the bit rate to one of your earlier encodes, and then compare the quality.

So no point running any tests when using CRF?

Thanks for your replies.

[x265_Project]

So no point running any tests when using CRF?

Thanks for your replies.
If you run CRF, the new build will generate larger files. There's no point in trying to compare the visual quality of 2 encodes that have different bit rates. So, you would have to experiment to figure out a higher CRF value that produces the same file size as before. If you went through that trouble, you could then make a valid comparison.

[ndkamal]

Originally Posted by x265_Project View Post
The new lambda table posted here should improve the level of detail in any encode at any bit rate. Keep in mind that the "level of detail" you see in an H.264 encode may include energy that looks like actual detail, but is actually noise (fine-grained macroblocking artifacts). So H.265 encodes generally tend to look like they have less detail, because they have less high frequency energy in the decoded signal. We don't try to produce the maximum level of high frequency energy, we try to produce the most accurate representation possible, including both spatial detail and motion (temporal) accuracy.

We're going to update x265 (development branch) to include this new lambda table, starting with 8 bit builds. Similarly, we'll optimize and update the 10 and 12 bit lambda tables, as soon as possible. There are a number of adjustments we have to make to x265 when we change the lambda table, so this takes a bit of time to do all of the necessary testing and tuning.



I've made some tests with the new lambda table, and the results are great, there are more details with the the last build.

Greats works !!!!

[Magik Mark]

Guys

Pls advise us if lamda file or 10bit is available

[LigH]

As you can read, this lambda2 file is for 8-bit encoding only. I believe it is now already default in a current build (v2.3+22)? commit db5e22b (https://bitbucket.org/multicoreware/x265/commits/db5e22b856f53b4024a5933a1ca4f1f977a016ba)

[shinchiro]

I tried testing on anime material. While the new lambda generally better in all cases, in lots of motion scene(bframes?) noises is more noticeable in new build. I guess this is normal?

[Stephen R. Savage]

How was the new coefficient table calculated?

[need4speed]

I tried testing on anime material. While the new lambda generally better in all cases, in lots of motion scene(bframes?) noises is more noticeable in new build. I guess this is normal?
Same feeling. TV series, dark scenes and fast motion.
Noticeable improvements generally speaking but there seems to be more noise, especially in dark scenes.
Will check and compare screenshots later.
X265 last posted version, Staxrip, preset fast, two pass, Abr 4000, no Sao no deblock, no strong is, aq motion, no slow first pass.
I assume new lambda table is default?

Inviato dal mio GT-N7100 utilizzando Tapatalk

[x265_Project]

How was the new coefficient table calculated?
Trade secret.

No, seriously... part theoretical, part experimental. We calculated a better theoretical curve, and then we experimented with variations on this curve until we were satisfied that we found the optimal curve. [The values in the lambda table are an exponential function... forming a straight line if you plot them exponentially]. This is not the optimal curve with respect to objective quality metrics like SSIM and PSNR... it's the optimal curve with respect to subjective visual quality.

Psy-rd, psy-rdoq, AQ and cu-tree may all need to be slightly tuned now, and we're looking at this. The starting few seconds of ABR rate control (--bitrate) will also need to be recalibrated.

[HWK]

Just to confirm if you have multi build, lambda 2 table is used if input and output depth both are at 8 bit.

[brumsky]

So what's the story with rdoq-level 1 vs 2? I've been toying around with it and it seems that 1 is "sharper" but it might not be as true to the source compared with 2.

I also noticed rdoq-level 2 is used in the higher presets.

[x265_Project]

Just to confirm if you have multi build, lambda 2 table is used if input and output depth both are at 8 bit.
It only depends on output depth. If input depth is greater than output depth, x265 truncates the samples to the internal depth (the output depth). It will dither the last bit if you add --dither. So if you have 10 bit content but you want an 8 bit encode, x265 will use 8 bits for all calculations, and it will use the 8 bit lambda table.

[CruNcher]

x265_Project

did you ever made tests how high the 10->8bit conversion overhead is for an almost perceptual banding free result, especially on high f-stop captured skyboxes internally and where the point of f-stop slope is it makes virtually no difference anymore in overall perception ?

and at which QP this merges currently depending on the overall Preset Setup in x265 or does it explicitly need AQ enabled, and how this shifts between Generations ?

Or do you know some papers this was discussed about in General @ HEVC at conferences primarily maybe by Ateme, Dolby, Technicolor, Sony, Samsung ?

[x265_Project]

x265_Project

did you ever made tests how high the 10->8bit conversion overhead is for an almost perceptual banding free result, especially on high f-stop captured skyboxes internally and where the point of f-stop slope is it makes virtually no difference anymore in overall perception ?

and at which QP this merges currently depending on the overall Preset Setup in x265 or does it explicitly need AQ enabled, and how this shifts between Generations ?

Or do you know some papers this was discussed about in General @ HEVC at conferences primarily maybe by Ateme, Dolby, Technicolor, Sony, Samsung ? Uhhh... No.