x265 HEVC Encoder

[need4speed]

Originally Posted by 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/ak31a1...b5e22b856f5.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?

Originally Posted by 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?

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]

Originally Posted by x265_Project

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.

Originally Posted by pingfr

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

[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]

Originally Posted by 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?

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

Originally Posted by Stephen R. Savage

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.

Originally Posted by HWK

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 ?

Originally Posted by 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 ?

Uhhh... No.