x265 HEVC Encoder

[LeXXuz]

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]

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]

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]

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]

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]

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]

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/pipermail/x265-devel/2020-February/012882.html)

[Boulder]

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]

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]

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.



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/pipermail/x265-devel/2020-February/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/x265_git/commits/branch/master

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

[benwaggoner]

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

[benwaggoner]

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
So, --aq-auto itself would be Rec. 709 tuned?

Is there not a way to have hdr + hyst?

[ShortKatz]

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/pipermail/x265-devel/2020-February/012882.html)

I have updated the original autoAQ patch to the current x265 master. I also included the memory leak fix from the first sbrc approach, AQ mode 5 and the --aq-bias-strength option from a GitHub patch from noizuy.
Everyone feel free to give it a try: https://gist.github.com/Nomis101/9953a2feb69e9f4b96a73fabca2d5ff8

[jpsdr]

So, --aq-auto itself would be Rec. 709 tuned?
I don't know, i just put back as it was in the first place.


Is there not a way to have hdr + hyst?
Yes, put the 2 commands options.

Should explain more.
First, you have to enable it with --aq-auto, and then, you tune with --aq-auto-xxx. Using for example --aq-auto-hdr without --aq-auto has no effect, as the feature is just not enabled.

I have pushed things on my github, didn't have time yet to build and test.

[Boulder]

I have updated the original autoAQ patch to the current x265 master. I also included the memory leak fix from the first sbrc approach, AQ mode 5 and the --aq-bias-strength option from a GitHub patch from noizuy.
Everyone feel free to give it a try: https://gist.github.com/Nomis101/995...a73fabca2d5ff8

I don't know, i just put back as it was in the first place.


Yes, put the 2 commands options.

Should explain more.
First, you have to enable it with --aq-auto, and then, you tune with --aq-auto-xxx. Using for example --aq-auto-hdr without --aq-auto has no effect, as the feature is just not enabled.

I have pushed things on my github, didn't have time yet to build and test.

Thank you to both :)

Are the "false SBRC patch" and "old auto-aq" the same or are there some fundamental differences there?

[jpsdr]

From what i've seen (quickly), my custom release includes all the patchs of ShortKatz. I don't know what was the "old auto-aq".

[Boulder]

From what i've seen (quickly), my custom release includes all the patchs of ShortKatz. I don't know what was the "old auto-aq".

It was this one: https://mailman.videolan.org/pipermail/x265-devel/2020-February/012882.html

[jpsdr]

@Boulder
At very quick first glance, it seems similar, so there is a good chance it was the same.

QUESTION
With the new SBRC there is :
x265 [warning]: Segment based RateControl requires fixed gop length. Force set min-keyint equal to keyint.
Does it mean that there is not anymore I-Frames inserted on scene change detection and so GOP have always the same length ?
In that case, is it realy an interesting thing ?

[ShortKatz]

Is it possible to include support for DOVI profile 7 support to x265? I think I've seen a patch for this somewhere, but I cannot find it, so I may be wrong.




I have pushed things on my github, didn't have time yet to build and test.

Thanks for your effort. I think it is quite a pity that we need to make mod versions to bring x265 to the feature level it actually should be.

[vpupkind]

@Boulder
At very quick first glance, it seems similar, so there is a good chance it was the same.

QUESTION
With the new SBRC there is :
x265 [warning]: Segment based RateControl requires fixed gop length. Force set min-keyint equal to keyint.
Does it mean that there is not anymore I-Frames inserted on scene change detection and so GOP have always the same length ?
In that case, is it realy an interesting thing ?

It is still interesting for live, as in streaming production you typically have fixed segment duration. I bet this can be extended to variable length segments, especially for 2-pass encoding.

[excellentswordfight]

@Boulder
Does it mean that there is not anymore I-Frames inserted on scene change detection and so GOP have always the same length ?
In that case, is it realy an interesting thing ?
You can still have i-frames inserted on scene change with fixed GOP size, as you can have non-IDR I-frames.

Fixed GOP sizes are still very relevant for broadcast/streaming/VOD.

[FranceBB]

I think it is quite a pity that we need to make mod versions to bring x265 to the feature level it actually should be.

You don't, please commit back and the Multicoreware guys will look at everything.
If no one opens pull requests, then the changes will never be merged...

[Ritsuka]

I guess all the the unapplied patches on the mailing-list and on bitbucket are just in my mind ;P

[jpsdr]

I've made a new build of my mod version (check my github). Quick test seems fine.

[ShortKatz]

You don't, please commit back and the Multicoreware guys will look at everything.
If no one opens pull requests, then the changes will never be merged...

I've opened several pull requests on this mailing list. Just one got applied, half a year later. And there are so many more patches on this list that got never merged, not even reviewd.
Here are 3 examples of interesting patches that never got applied:
https://mailman.videolan.org/pipermail/x265-devel/2020-February/012907.html
https://mailman.videolan.org/pipermail/x265-devel/2020-February/012908.html
https://mailman.videolan.org/pipermail/x265-devel/2020-October/013158.html

And then there are sadly some bug fixes that were opened at the wrong place:
https://github.com/videolan/x265/pulls

(And I don't even talk about all those open bugs in the bug tracker that never got fixed)

[vpupkind]

I've opened several pull requests on this mailing list. Just one got applied, half a year later. And there are so many more patches on this list that got never merged, not even reviewd.
Here are 3 examples of interesting patches that never got applied:
https://mailman.videolan.org/pipermail/x265-devel/2020-February/012907.html
https://mailman.videolan.org/pipermail/x265-devel/2020-February/012908.html
https://mailman.videolan.org/pipermail/x265-devel/2020-October/013158.html

And then there are sadly some bug fixes that were opened at the wrong place:
https://github.com/videolan/x265/pulls

(And I don't even talk about all those open bugs in the bug tracker that never got fixed)

Two of them seem to be of limited non-academic use.

[Yomiko]

What are the params that are allowed to change for encoding two slices of video and later losslessly concatenating them? Are they merely the ones specified in --zones?

[benwaggoner]

Should explain more.
First, you have to enable it with --aq-auto, and then, you tune with --aq-auto-xxx. Using for example --aq-auto-hdr without --aq-auto has no effect, as the feature is just not enabled.
Did you consider having the different modes as parameters to --aq-auto? Ala:

--aq-auto none (aka --no-auto-aq)
--aq-auto hyst
--aq-auto "hdr,hyst"

Or

--auto-aq-mode for the parameters?

Those would seem to match x265 style a little better. I'm not sure what the limitations are in command line structure.

[jpsdr]

Not realy, i made it "quick"... Don't realy interested in spending time to figure out how to analyse command line with several parameters. Could see others command line to figure out how it's done.
This configuration is working and is fine for me. Yes, it could be better and more x265 friendly, but not in the mood...
It's in the first place an own custom build, and i share it in case people could be interested with.
After, if someone is motivated enough to make a pull request, no problemo... ^_^

[jpsdr]

Are these patches interesting (and correct, not adding issues) to commit in my custombuild ?
I checked my code, they are not implemented, so the bugs (if realy) are still here. As i'm using tskip, if the 1rst is to be commited, i'm very interested by a validation.

https://github.com/videolan/x265/pull/6/commits/51da5f6781e052521cf42ab14bdbc25d50cec5d8 (very interested if this one is to be applyed)
https://github.com/videolan/x265/pull/5/commits/cf043d2a47ac9a2cfa29f518550c8ffe57bc08b6
https://github.com/videolan/x265/pull/4/commits/3b99bbe6306eb3dd3eed677a840cc988a0928a11 (this one is big... Maybe not so easy to check the effects ?)
https://github.com/videolan/x265/pull/4/commits/3d29c2497b3763c797cd97ba4d953a189859ff8b

[vpupkind]

Did you consider having the different modes as parameters to --aq-auto? Ala:

--aq-auto none (aka --no-auto-aq)
--aq-auto hyst
--aq-auto "hdr,hyst"

Or

--auto-aq-mode for the parameters?

Those would seem to match x265 style a little better. I'm not sure what the limitations are in command line structure.

Talk to MulticoreWare? I would expect them to post it again, with a different parameter name.

[Boulder]

Are these patches interesting (and correct, not adding issues) to commit in my custombuild ?
I checked my code, they are not implemented, so the bugs (if realy) are still here. As i'm using tskip, if the 1rst is to be commited, i'm very interested by a validation.

https://github.com/videolan/x265/pull/6/commits/51da5f6781e052521cf42ab14bdbc25d50cec5d8 (very interested if this one is to be applyed)
https://github.com/videolan/x265/pull/5/commits/cf043d2a47ac9a2cfa29f518550c8ffe57bc08b6
https://github.com/videolan/x265/pull/4/commits/3b99bbe6306eb3dd3eed677a840cc988a0928a11 (this one is big... Maybe not so easy to check the effects ?)
https://github.com/videolan/x265/pull/4/commits/3d29c2497b3763c797cd97ba4d953a189859ff8b
The third one could well be interesting to many. If you could do the first pass in like half the resolution of the actual encode in the second pass, it might speed things up considerably. Especially with 4K sources, that is.

[vpupkind]

The third one could well be interesting to many. If you could do the first pass in like half the resolution of the actual encode in the second pass, it might speed things up considerably. Especially with 4K sources, that is.

I think (looking at GitHub) that the reason for non-inclusion is CLA (derived from the x265 CLA)

[jpsdr]

I think for now i'll not try to include the big one, but i need to be sure that the 3 others are validated to be bug fixes.

For aq-auto, what i'll see if easy to do is the following :
--aq-auto <integer>
0 : Default, disable. <>0 enabled.
Bit 1 : If set to 1 enable hysteresis.
Bit 2 : If set to 1 enable HDR mode.
Bit 3 : If set to 1 enable AQ5.
The others bits (0, 4 to 7) if set to 1 will just enable the aq-auto mode.
=>
--aq-auto 1 : Just enable the aq-auto mode.
--aq-auto 2 is exactly the same than --aq-auto 3.

[LeXXuz]

Anyone else having issues with x265 halting about 4 seconds before the actual source file ends? It doesn't happen every time but quite a few times now on different systems.
Currently using jp's version: 3.5+75+0-f3c013983 [Mod by Patman]

[benwaggoner]

Are these patches interesting (and correct, not adding issues) to commit in my custombuild ?
I checked my code, they are not implemented, so the bugs (if realy) are still here. As i'm using tskip, if the 1rst is to be commited, i'm very interested by a validation.

https://github.com/videolan/x265/pull/6/commits/51da5f6781e052521cf42ab14bdbc25d50cec5d8 (very interested if this one is to be applyed)
https://github.com/videolan/x265/pull/5/commits/cf043d2a47ac9a2cfa29f518550c8ffe57bc08b6
https://github.com/videolan/x265/pull/4/commits/3b99bbe6306eb3dd3eed677a840cc988a0928a11 (this one is big... Maybe not so easy to check the effects ?)
https://github.com/videolan/x265/pull/4/commits/3d29c2497b3763c797cd97ba4d953a189859ff8b
#1 is certainly interesting to me. --tskip is a very valuable feature with a certain subset of content, like text and computer graphics. Using the wrong reconstruction sounds like a pretty big bug.

That said, it's from 2018. I wouldn't be surprised if it had already been fixed.

[jpsdr]

I've put the 2 first patches. And no, they were not fixed.
Also put the change on --aq-auto command. Now, i have to build and make my usual small quick encode test.

[madey83]

I've put the 2 first patches. And no, they were not fixed.
Also put the change on --aq-auto command. Now, i have to build and make my usual small quick encode test.

Hi,

is this "--aq-auto-hdr" can be used for dolby vision encode use case?

[jpsdr]

@madey83
Yes.

New build with the modified --aq-auto command described in post #8949, and also include the two old bug fix patches. Check my Github.
Quick small encode test, seems fine.

[Boulder]

It's a bit confusing :D Are we talking about an 8-bit integer here? I was just quickly testing it, and expected --aq-auto 3 to enable hysteresis and HDR mode (calculated 1+2) but it only enabled hysteresis. --aq-auto 6 brought up the desired combination while I assumed it would enable all of the three.

[jpsdr]

With 3, you set Bits 0 & 1 at 1.
With 6, you set Bits 1 & 2 at 1.

[Zebulon84]

obsolete

[jpsdr]

What is obsolete ???

[Boulder]

With 3, you set Bits 0 & 1 at 1.
With 6, you set Bits 1 & 2 at 1.

Oh, I thought it was to calculate "0+1+2+4" for the first four bits. It's been 25 years since I practiced any of this stuff :D

[ShortKatz]

That said, it's from 2018. I wouldn't be surprised if it had already been fixed.

Nope, the patch still does apply. So, I was wondering, if this bug is so big and there since (minimum) 2018, why did no one else notice?