x265 HEVC Encoder

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

[Boulder]

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

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]

Originally Posted by Boulder

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]

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

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

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

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

Originally Posted by jpsdr

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

[ShortKatz]

Originally Posted by benwaggoner

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?