Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
3rd March 2021, 11:34 | #8021 | Link | |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 480
|
Quote:
Skickat från min SM-G988B via Tapatalk
__________________
Do NOT re-post any of my Mediafire links. Download & re-host the content(s) if you want to share it somewhere else. |
|
4th March 2021, 02:35 | #8026 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
|
Quote:
And if we're really trying to encode 480p on 128 cores to heat the house in the winter, don't forget --slices! |
|
4th March 2021, 14:22 | #8028 | Link | |
Registered User
Join Date: Apr 2017
Posts: 63
|
Quote:
UHD does all, so I don't lose that much time there either. |
|
5th March 2021, 11:11 | #8031 | Link | |||
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
|
Quote:
Quote:
Ok, back on topic: Quote:
@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... ) |
|||
6th March 2021, 00:10 | #8033 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
|
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. |
7th March 2021, 19:18 | #8034 | Link | |
Registered User
Join Date: Aug 2018
Location: Germany
Posts: 118
|
Quote:
|
|
8th March 2021, 20:29 | #8035 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
|
Quote:
I'd be quite interested in seeing a native M1 ARM version for Mac as well. My vague understanding today is that x265 has better perf running in x64 emulation than native ARM on M1 due to how good Apple's emulator is, even with AVX2 code. But it'd be great to be able to test head-to-head, and see how perf evolves as the ARM (including M1 and AWS's Graviton) optimizations get added. A good justification to expense a new MacBook Pro . |
|
10th March 2021, 19:33 | #8039 | Link |
Registered User
Join Date: Aug 2018
Location: Germany
Posts: 118
|
x265 3.5_RC2 for macOS, Universal binary 2 (x86_64 / arm64)
https://polysom.verilite.de/tmp/x265_3.5_RC2_macOS.zip sha256 checksum: 60c93733f5d3703f8d7d9e1a9152fc5a84f7d35f4ccb9a1ca55c855c3b9f32a7 x265 3.5_RC2 for macOS, Universal binary 2 (x86_64 / arm64e) https://polysom.verilite.de/tmp/x265_3.5_RC2_macOS2.zip sha256 checksum: d46ac744a683db0453f77b856c286a789530ef47caf1f3470fa08279c4d2d956 To install, extract x265_3.5_RC2_macOS.tar.gz. With Terminal cd into the folder "x265_3.5_RC2_macOS" and drag&drop install.command into the Terminal window. Hit Enter. To check if x265 is properly installed, open Terminal and type: Code:
x265 --version I had to include Apple's Neon patch, otherwise arm64(e) did not build properly. arm64e adds Pointer authentication, Nested virtualization and Advanced SIMD complex number support. I don't have a M1, so I can't test if the arm64e binary will work. Last edited by ShortKatz; 10th March 2021 at 21:13. |
17th March 2021, 08:39 | #8040 | Link |
Registered User
Join Date: Jan 2020
Posts: 34
|
Hello, I have a problem with my settings since version 3.4 + 26 of x265 (I am currently in 3.5_RC2, windows 10 64bit, PC Ryzen 3900x).
My concern is in increasing my Avg QP, I am almost always above 24, whereas before with version 3.4 + 20 I managed to have my Avg QP below 20. here are the parameters used for the3.5_RC2 : --scenecut-aware-qp 3 --masking-strength 500,2,0,200,-1,-1 **** I also tested: --scenecut-aware-qp 1 --masking-strength 300,2,2 *** --scenecut-aware-qp 3 --masking-strength 500,5,6.5,100,-1,-1 for the rest of the parameters : --rd 6 --rskip 2 --deblock -3:-3 --cutree --ctu 64 --min-cu-size 8 --bframes 4 --b-adapt 2 --rc-lookahead 60 --ref 4 --limit-refs 2 --merange 57 --subme 7 --aq-mode 4 --aq-strength 0.70 --me 3 --psy-rd 2.10 --psy-rdoq 1.35 --gop-lookahead 54 I tested by increasing my --bframes and reducing my --gop-lookahead, it is a little better but nothing more. In 3.4 + 20 I had this in parameters: --scenecut-aware-qp --scenecut-window 500 --qp-delta-ref 6 --qp-delta-nonref 7 and my QP was impeccable Thank you for your help |
Thread Tools | Search this Thread |
Display Modes | |
|
|