x265 HEVC Encoder

[benwaggoner]

Originally Posted by higher

It's likely that Zen 5 is not much of an advance in x265 encoding compared to other workloads.

It has full native AVX512 support, which could make using that flag improve performance more, and in more scenarios.

[benwaggoner]

Originally Posted by cubicibo

VFR can be signaled both on the entire stream or at a CWS level. But specifying the actual picture output-presentation delay is overly complicated here.

Anyway, it does not matter for the current problem. pic_struct should be used with CFR. But frame entry time in decoder must be adapted with respect to the last pic struct instruction. I can't find any such code in x265, so VBV conformance must be way off.

Back in the VC-1 days we handled this by having the frame in the bitstream, containing just the frame_repeat tag. Didn't require any VFR, time shifts, etcetera.

[Z2697]

Originally Posted by benwaggoner

It has full native AVX512 support, which could make using that flag improve performance more, and in more scenarios.

If my test is anything to be believed, it's around 5% to 8% "free performance" (more or less), depending on the target quality somehow.
(5% with CRF-14, 6.3% with CRF-18, 6.6% with CRF-22 and 8% with CRF-26, the 4 quality targets I often use to draw RD curve (there's no difference in the RD curve in this case, of course))

[tormento]

Benchmarking with different builds, I've noticed that Patman86's x265-4.1+79+12-81640d428 ICC standard/AVX/AVX2 builds are identical but 1-2 bytes.

It seems a bit strange to me and I've opened a issue on GitHub.

Please be aware of that in the mean time.

[benwaggoner]

Originally Posted by Z2697

If my test is anything to be believed, it's around 5% to 8% "free performance" (more or less), depending on the target quality somehow.
(5% with CRF-14, 6.3% with CRF-18, 6.6% with CRF-22 and 8% with CRF-26, the 4 quality targets I often use to draw RD curve (there's no difference in the RD curve in this case, of course))

Hmm. Perhaps higher QP makes for fewer early exists so doing more in parallel helps? Can you share the command line? I imagine stuff like TU size could have different impact.

[Z2697]

Originally Posted by tormento

Benchmarking with different builds, I've noticed that Patman86's x265-4.1+79+12-81640d428 ICC standard/AVX/AVX2 builds are identical but 1-2 bytes.

It seems a bit strange to me and I've opened a issue on GitHub.

Please be aware of that in the mean time.

You should compare with both setting no-info, and do a proper bytes compare instead of just telling from the size

Never mind, so you were talking about the executable, I thought you were talking about the encoded hevc stream.

[Z2697]

Originally Posted by benwaggoner

Hmm. Perhaps higher QP makes for fewer early exists so doing more in parallel helps? Can you share the command line? I imagine stuff like TU size could have different impact.

--preset slow
--rd 6
--ctu 32
--no-rect
--no-sao
--no-strong-intra-smoothing
--no-open-gop
--b-intra
--weightb
--aq-mode 1
--aq-strength 0.8
--qcomp 0.7
--pbratio 1.2
--bframes 3
--cbqpoffs -2
--crqpoffs -2
--deblock -3,-3
--rc-lookahead 80

[benwaggoner]

Originally Posted by Z2697

--preset slow
--rd 6
--ctu 32
--no-rect
--no-sao
--no-strong-intra-smoothing
--no-open-gop
--b-intra
--weightb
--aq-mode 1
--aq-strength 0.8
--qcomp 0.7
--pbratio 1.2
--bframes 3
--cbqpoffs -2
--crqpoffs -2
--deblock -3,-3
--rc-lookahead 80

Huh. What are you trying to encode/optimize for with those settings? And this is with 1080p --crf, right?

Nothing pops out as impacting performance in particular. However, as CABAC is single threaded per frame, just reducing the bitrate itself will improve performance on many systems.

[Z2697]

Originally Posted by benwaggoner

Huh. What are you trying to encode/optimize for with those settings? And this is with 1080p --crf, right?

Nothing pops out as impacting performance in particular. However, as CABAC is single threaded per frame, just reducing the bitrate itself will improve performance on many systems.

I don't usually optimize x265 parameters for every different sources based on their "style" or characteristic, unless the image quality of the source is very characterized.
These are just... "generic" settings.
I choose my encoding parameters based on the performance (FPS & RD), and the "dark biased AQ" based on... I see fit. I frankensteined AQ 1 and drak-bias as new mode in my mod build, yes
(AQ is not really about the RD performance, of course. The FPS performance also don't seem to affected much by AQ except edge based ones.)

However, the major portion of the things I encode is anime. When I do non-test encoding I use slower parameters. (e.g. hme)

And yes, the test is 1080p CRF.

[Sagittaire]

Originally Posted by higher

It's likely that Zen 5 is not much of an advance in x265 encoding compared to other workloads.

TPU uses x265 with preset slow at 4K resolution. It fully saturates my 5900X and I'm guessing it fully saturates a 9900X as well. Yet, the 9900X is only 25% faster than 5900x while the 9950x is 27% faster than 5950x in he TPU benchmark and it sounds about right.

Power consumption is on a different level though. The 9900X consumes around 170W fully loaded while an M4 Pro consumes less than 50W.
Unfortunately X86 is years behind in this regards and also in single core performance.

No, x265 at 4K with x265 at slow preset don't saturate 32 threads and by far. And saturate all thread mean 100% CPU charge at power limit during all encoding time.

If TPU codec benchmark saturate all CPU, the difference between 5900X, 5950X, 9900X and 9950X could be equivalent to blender benchmark, for exemple. And it's not the case.