x265 HEVC Encoder

[Boulder]

Originally Posted by LeXXuz

I have a question regarding ctu sizes in CRF mode.

I did some testing with SD and HD content to compare differences between encodes with --ctu 64 and --ctu 32 setting in crf mode.
I read in the docs and on Wikipedia that larger coding tree units usually increase encoding efficiency, therfore should decrease filesize in crf-mode, right?

But I noticed quite the contrary where ctu=32 results in noticeabley smaller file sizes. See screenshot:

top-left: ctu=64, framethreads=1
top-right: ctu=64, framethreads=2
bottom-left: ctu=32, framethreads=1
bottom-right: ctu=32, framethreads=2
(This is an example with SD video. The behaviour is similar with 1080p content. I also repeated this with different content with less or more complexity to rule out this was just coincidence.)

Okay, as mentioned in the docs, additional frame-threads reduce efficiency and slightly increase filesize. Regarding the noticeable speed increase I think the additional thread is well spend.
And I understand that ctu=32 gives a big speed increase on lower resolutions because there is more parallelism.

But why does the filesize decrease that much which clearly should have an impact on visual quality, right?

The only reason I can think of is that crf values scale differently with different ctu sizes. If so, could I just decrease crf values to get similar filesizes and, more importantly, similar visual results?

Or will ctu=64 still give better visual quality and should always be prefered?

I've noticed this too. I believe there's more to it than just a simple difference in CTU size but that will also affect many other decisions. If you enable the csv logging, it might show some fundamental differences in skips and merges. I think the rskip mode also affects it greatly.

[benwaggoner]

For those comparing --ctu 32 versus 64, have you tried using --ctu 64 with --rdpenalty 1? That raises the cost of a 32x32 TU by 4x, theoretically meaning they'll be selected a lot less often, and only when benefits are unambiguous.

However, it's a really old parameter from x265 circa 2014, and I don't know that anyone has tested with it in ages.

--rdpenalty <0..2>
When set to 1, transform units of size 32x32 are given a 4x bit cost penalty compared to smaller transform units, in intra coded CUs in P or B slices.

When set to 2, transform units of size 32x32 are not even attempted, unless otherwise required by the maximum recursion depth. For this option to be effective with 32x32 intra CUs, --tu-intra-depth must be at least 2. For it to be effective with 64x64 intra CUs, --tu-intra-depth must be at least 3.

Note that in HEVC an intra transform unit (a block of the residual quad-tree) is also a prediction unit, meaning that the intra prediction signal is generated for each TU block, the residual subtracted and then coded. The coding unit simply provides the prediction modes that will be used when predicting all of the transform units within the CU. This means that when you prevent 32x32 intra transform units, you are preventing 32x32 intra predictions.

Default 0, disabled.

Values: 0:disabled 1:4x cost penalty 2:force splits

[LeXXuz]

Originally Posted by benwaggoner

For those comparing --ctu 32 versus 64, have you tried using --ctu 64 with --rdpenalty 1?

Thanks Ben. I never heard or noticed that parameter before. So no, I haven't.
I'll give it a try and see how this may affect speed and file size.

Still, it would be great to find an explanation to those differences in size between 32 and 64. Like Boulder said, there must be more to it.

[vpupkind]

Originally Posted by LeXXuz

Thanks Ben. I never heard or noticed that parameter before. So no, I haven't.
I'll give it a try and see how this may affect speed and file size.

Still, it would be great to find an explanation to those differences in size between 32 and 64. Like Boulder said, there must be more to it.

The lower the resolution the less probability of 64x64 being selected. It's pointless at HD resolutions. Even 32x32 is selected in a tiny % of cases in 1080p and nearly never with lower resolutions.

[LeXXuz]

Originally Posted by vpupkind

The lower the resolution the less probability of 64x64 being selected. It's pointless at HD resolutions. Even 32x32 is selected in a tiny % of cases in 1080p and nearly never with lower resolutions.

That makes sense. But why those differences then? Shouldn't those results between --ctu 32 and --ctu 64 setting be much closer if x265 wouldn't use 64x64 at those resolutions anyway? Or does the --ctu 64 setting actually force x265 to use 64x64 where it wouldn't normally do? I thought this is more like a 'maximum allowed size' setting, or am I wrong?

[vpupkind]

Originally Posted by LeXXuz

That makes sense. But why those differences then? Shouldn't those results between --ctu 32 and --ctu 64 setting be much closer if x265 wouldn't use 64x64 at those resolutions anyway? Or does the --ctu 64 setting actually force x265 to use 64x64 where it wouldn't normally do? I thought this is more like a 'maximum allowed size' setting, or am I wrong?

It will always go for CTU 64x64, and then evaluate a 32x32 split.

[Maxiuca]

I compiled the x265 binary yesterday and noticed today that it gave me a strange error ("unknown option -- no-temporal-layers") when I was trying to rerender something, so I had a look at the latest commits and it looks like this option has been retired and the way the temporal layers are configured also changed.

So I just wanted to give everyone a heads-up and hopefully save some time.

Here's the new syntax:

option: --temporal-layers <integer>

Enable specified number of temporal sub layers. For any frame in layer N,
all referenced frames are in the layer N or N-1.A decoder may choose to drop the enhancement layer
and only decode and display the base layer slices.Allowed number of temporal sub-layers
are 2 to 5.(2 and 5 inclusive)

When enabled,temporal layers 3 through 5 configures a fixed miniGOP with the number of bframes as shown below
unless miniGOP size is modified due to lookahead decisions.Temporal layer 2 is a special case that has
all reference frames in base layer and non-reference frames in enhancement layer without any constraint on the
number of bframes.Default disabled.

+----------------+--------+
| temporal layer | bframes|
+================+========+
| 3              | 3      |
+----------------+--------+
| 4              | 7      |
+----------------+--------+
| 5              | 15     |
+----------------+--------+

[ShortKatz]

I've tried the most recent x265 with the new sbrc patch applied. I got

x265 [warning]: Segment based RateControl requires closed gop structure. Enabling closed GOP.
x265 [warning]: Segment based RateControl requires fixed gop length. Force set min-keyint equal to keyint.

I was wondering what the reason for the closed GOP and min-keyint = keyint might be? The old patch did not set this.

For my test it did set it to

x265 [info]: Keyframe min / max / scenecut / bias : 240 / 240 / 40 / 5.00

[Boulder]

Originally Posted by ShortKatz

I was wondering what the reason for the closed GOP and min-keyint = keyint might be? The old patch did not set this.

To me it looks like they are looking at it in a very different way this time. The functionality name itself was a bit strange considering that it was actually an auto AQ function. Now it really looks like what it says -- and I don't think it's a good idea to make things fixed like this. It would be much better to allow the old functionality as well and set those fixed values only in case of VBV being enabled.

[benwaggoner]

Originally Posted by Boulder

To me it looks like they are looking at it in a very different way this time. The functionality name itself was a bit strange considering that it was actually an auto AQ function. Now it really looks like what it says -- and I don't think it's a good idea to make things fixed like this. It would be much better to allow the old functionality as well and set those fixed values only in case of VBV being enabled.

This SBRC implementation may be for use cases where per fragment max size is the fundamental limitation, not VBV. I've seen that for low latency live solutions, where VBV isn't a great tool for controlling worst-case latency. It would also open up GOP level parallelism since the prior GOP's VBV state isn't relevant.

That's certainly the behavior I'd imagine for a "Segment Based Rate Control" - it's based on each segment/fragment, not on VBV.

[vpupkind]

Originally Posted by benwaggoner

This SBRC implementation may be for use cases where per fragment max size is the fundamental limitation, not VBV. I've seen that for low latency live solutions, where VBV isn't a great tool for controlling worst-case latency. It would also open up GOP level parallelism since the prior GOP's VBV state isn't relevant.

That's certainly the behavior I'd imagine for a "Segment Based Rate Control" - it's based on each segment/fragment, not on VBV.

The idea is that HLS and DASH measure bitrate in units of segments, rather than sliding window. You have to obey the VBV in any case, but can redistribute bits more freely this way.

[vpupkind]

Originally Posted by Boulder

To me it looks like they are looking at it in a very different way this time. The functionality name itself was a bit strange considering that it was actually an auto AQ function. Now it really looks like what it says -- and I don't think it's a good idea to make things fixed like this. It would be much better to allow the old functionality as well and set those fixed values only in case of VBV being enabled.

It is not an auto AQ function. They submitted a wrong parch initially.

[Boulder]

Originally Posted by vpupkind

It is not an auto AQ function. They submitted a wrong parch initially.

So is the very old auto AQ patch, which has been submitted but never pushed to the master, the one to use for that purpose? I've not seen anything strange in my tests with the incorrect patch.
(https://mailman.videolan.org/piperma...ry/012882.html)

[Boulder]

Originally Posted by benwaggoner

This SBRC implementation may be for use cases where per fragment max size is the fundamental limitation, not VBV. I've seen that for low latency live solutions, where VBV isn't a great tool for controlling worst-case latency. It would also open up GOP level parallelism since the prior GOP's VBV state isn't relevant.

That's certainly the behavior I'd imagine for a "Segment Based Rate Control" - it's based on each segment/fragment, not on VBV.

I based my understanding on this comment in the patch which is not yet in master: 3. Reset RateControl (CRF/ABR) at the segment beginning

[benwaggoner]

Originally Posted by Boulder

I based my understanding on this comment in the patch which is not yet in master: 3. Reset RateControl (CRF/ABR) at the segment beginning

Yep, that nails it.

VBV-based encoding makes sense for Video on Demand, as bits saved in one fragment mean the next fragment can be downloaded sooner to increase client-side fragment buffer duration.

But with adaptive streaming where encoder latency~segment duration, there's not any way to "save" bits for the encoder to use on a fragment that hasn't happened yet. Rebuffer chance is proportional to the maximum fragment size of the lowest bitrate rendition. That's hard and limiting to control through VBV itself, and SBC does a better job of maximizing quality for a given max fragment size.

[ShortKatz]

Originally Posted by vpupkind

It is not an auto AQ function. They submitted a wrong parch initially.

Thats a pity, because HandBrake 1.6.0 does now contain the wrong sbrc patch. If someone now makes a preset with the sbrc option, than this patch will give different results if HandBrake 1.7.0 will be released some day, because the new patch reuses the same option name than the old patch.

Originally Posted by Boulder

So is the very old auto AQ patch, which has been submitted but never pushed to the master, the one to use for that purpose? I've not seen anything strange in my tests with the incorrect patch.
(https://mailman.videolan.org/piperma...ry/012882.html)

Yes, I very much like this auto-aq feature. Was wondering why this patch never made it into master. I still use it with my own builds.

[Boulder]

Looks like the final version was now pushed to master.

Here's hoping that jpsdr can include the old auto-aq feature (+ the hysteresis part) in his mod since SBRC is now something very different from what it was..

[Barough]

x265 v3.5+85
Built on January 12, 2023, GCC 12.2.0

https://bitbucket.org/multicoreware/.../branch/master

DL :
https://www.mediafire.com/file/9qs4smpj0m6tjzy/

[benwaggoner]

Originally Posted by Boulder

Looks like the final version was now pushed to master.

Here's hoping that jpsdr can include the old auto-aq feature (+ the hysteresis part) in his mod since SBRC is now something very different from what it was..

I propose --aq-auto or --aq-mode auto.

Yeah, Auto AQ and SBRC are orthogonal and additive features.

[jpsdr]

I'll try to put it back and replace the name of all the commands :
--srbc => --aq-auto
--srbc-hyst => --aq-auto-hyst
--srbc-aq5 => --aq-auto-aq5
--srbc-hdr => --aq-auto-hdr