x265 HEVC Encoder

[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

[benwaggoner]

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

So, --aq-auto itself would be Rec. 709 tuned?

Is there not a way to have hdr + hyst?

[ShortKatz]

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)

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

[jpsdr]

Originally Posted by benwaggoner

So, --aq-auto itself would be Rec. 709 tuned?

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

Originally Posted by benwaggoner

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]

Originally Posted by ShortKatz

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

Originally Posted by jpsdr

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]

Originally Posted by 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".

It was this one: https://mailman.videolan.org/piperma...ry/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.

Originally Posted by jpsdr

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]

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

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]

Originally Posted by jpsdr

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

Originally Posted by ShortKatz

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]

Originally Posted by FranceBB

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/piperma...ry/012907.html
https://mailman.videolan.org/piperma...ry/012908.html
https://mailman.videolan.org/piperma...er/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)