x265 HEVC Encoder

[charliebaby]

For Used max cpu add this --pmode --pme --frame-threads 16 --ctu 16 --qg-size 16 --min-cu-size 16 --max-tu-size 16

:-)

[benwaggoner]

Originally Posted by charliebaby

For Used max cpu add this --pmode --pme --frame-threads 16 --ctu 16 --qg-size 16 --min-cu-size 16 --max-tu-size 16

:-)

And if it wasn't clear, this is actually not good advice !

And if we're really trying to encode 480p on 128 cores to heat the house in the winter, don't forget --slices!

[_kermit]

Originally Posted by charliebaby

For Used max cpu add this --pmode --pme --frame-threads 16 --ctu 16 --qg-size 16 --min-cu-size 16 --max-tu-size 16

:-)

also made no difference, around 50% util, except that the file got around 20% larger

[_kermit]

Originally Posted by benwaggoner

And if it wasn't clear, this is actually not good advice !

And if we're really trying to encode 480p on 128 cores to heat the house in the winter, don't forget --slices!

with 50% util. it's fast enough anyway.
UHD does all, so I don't lose that much time there either.

[benwaggoner]

Originally Posted by _kermit

also made no difference, around 50% util, except that the file got around 20% larger

Those are all parameters that reduce compression efficiency to increase parallelism. And there's a reason they're not used in --preset veryfast, as lots of those tradoffs are Not Good Deals.

[LigH]

OT: We are on page 403 here with the 20 posts/page default ... I start to worry for a moment when I catch a glimpse of the tab title.

[FranceBB]

Originally Posted by LigH

OT: We are on page 403 here with the 20 posts/page default ... I start to worry for a moment when I catch a glimpse of the tab title.

OT2: 2719 days passed ever since the topic was created on the 24th September 2013, with 403 pages and your average of 20 posts per page, not taking into account any outliers, it gives us a total of 8060 replies, which, divided by 2719 gives us an average of 3 posts per day about x265. That's quite alright, I guess.

Originally Posted by benwaggoner

And if we're really trying to encode 480p on 128 cores to heat the house in the winter, don't forget --slices!

ROTFL

Ok, back on topic:

Originally Posted by benwaggoner

Those are all parameters that reduce compression efficiency to increase parallelism.
[...] Lots of those tradoffs are Not Good Deals.

This is absolutely true, no wonder they're not used by default.

@charliebaby... x265 does a pretty good job in using up multicore/multithread CPUs and even multi-socket configurations thanks to the whole Pool/NUMA implementation, especially with UHD contents (a bit less for lower resolutions), so that's generally quite alright. Of course, there is always a trade-off between parallelism and quality and sometimes it's just not worth it, which is why, whenever I have some spare room in my 40c/80th Xeon Platinum, I run more encodes at once rather than being obsessed in getting CPU usage up in one single encode (also 'cause sometimes you see the CPU go up and up without a real improvement in speed or sometimes you do see an improvement in speed at the expense of quality or compression - i.e bigger file).

(for the records, that's one of the server I have a work, I wish I had such a monster at home hehehe... although I would be kinda happy with something like an old Z840 with a 28c/40th Xeon, to be fair, but that's not gonna happen in the near future... )

[LigH]

@FranceBB: I meant the association with HTTP errors 403 (denied) and 404 (not found), so I get worried about forum software errors...

[benwaggoner]

I generally run slower, higher quality encodes (--preset slower and up), and on my Xeon 2x18/36 workstation I rarely get much of a boost from using both sockets below 8K. I generally just use --pools "+,-" and "-,+" to run one encode per socket. That automatically reduces the available threads for calculating defaults that change based on available threads, like --frame-threads.

Latency versus throughput are very different tuning targets.

The newer --abr-ladder presumably improves throughput when encoding the same content multiple times, and thus latency when running them all in parallel.

[ShortKatz]

Originally Posted by Barough

x265 v3.5_RC1+2-f3f27198 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/Release_3.5

Is there some need of macOS binaries? I could provide some. Or are there only Windows users here.