x265 HEVC Encoder

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

[vpupkind]

Originally Posted by ShortKatz

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)

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]

Originally Posted by jpsdr

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/pul...dbc25d50cec5d8 (very interested if this one is to be applyed)
https://github.com/videolan/x265/pul...0c8ffe57bc08b6
https://github.com/videolan/x265/pul...0cc988a0928a11 (this one is big... Maybe not so easy to check the effects ?)
https://github.com/videolan/x265/pul...953a189859ff8b

[vpupkind]

Originally Posted by benwaggoner

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.