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. |
20th January 2019, 15:39 | #21 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,729
|
Yes, there's a clear difference between CTU 64 and 32 what comes to parallel processing in the encoder. Of course, if you do extensive processing in Avisynth or better yet, Vapoursynth before feeding data into the encoder, the general utilization level should be higher by default.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
20th January 2019, 15:56 | #23 | Link | |
Registered User
Join Date: May 2005
Posts: 1,462
|
Quote:
So, what I don't understand then is how running two x265 processes concurrently lowers the amount of threads each uses. Or is that something you can actually set? Thanks.
__________________
Gorgeous, delicious, deculture! |
|
20th January 2019, 16:45 | #24 | Link | |
Registered User
Join Date: Nov 2013
Posts: 577
|
Quote:
For HD and SD res. I maximalize threads and lookahead threads to 12&4 and 6&2 correspondingly. |
|
20th January 2019, 16:55 | #25 | Link | |
Registered User
Join Date: May 2005
Posts: 1,462
|
Quote:
__________________
Gorgeous, delicious, deculture! |
|
20th January 2019, 18:57 | #26 | Link |
Registered User
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
|
Wait, you mean the devs of x265 didn't make its threading resolution aware as to not have it degrade image quality by spawning excess threads (by default)? I know x264 has that problem, but I thought I read that x265 was smarter about threading...
|
21st January 2019, 03:10 | #27 | Link | ||
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,407
|
Quote:
Quote:
"The number of frame threads used is auto-detected from the (hyperthreaded) CPU core count" Cores: Frames > 32: 6..8 >=16: 5 >= 8: 3 >= 4: 2 Source
__________________
madVR options explained |
||
21st January 2019, 13:07 | #28 | Link | ||
Registered User
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
|
Quote:
There certainly is no warning (or even a vague suggestion for that matter) to limit threading manually based on the input resolution for the sake of quality. In fact there's pretty much a statement to the opposite. Quote:
|
||
21st January 2019, 19:21 | #29 | Link | |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,407
|
Quote:
__________________
madVR options explained |
|
21st January 2019, 20:49 | #30 | Link | |
Registered User
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
|
Quote:
|
|
21st January 2019, 22:36 | #31 | Link |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,407
|
The first sentence in your quote doesn't make any sense then.
It cannot both sometimes improve quality when disabled and not impact quality when enabled. I think the second sentence is contrasting frame level parallelism against slices as a way to allow parallelism, slices change the bitstream.
__________________
madVR options explained Last edited by Asmodian; 21st January 2019 at 22:40. |
22nd January 2019, 03:39 | #32 | Link | |
Registered User
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
|
Quote:
|
|
22nd January 2019, 22:24 | #34 | Link | ||
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,407
|
Quote:
It also does not make sense technically. If you do not wait for all previous frames to be encoded sometimes you cannot chose what would have been the best reference block because it isn't available yet. Quote:
Edit: Maybe it is saying that once --frame-threads = 2 more frame threads should have no effect? I find this hard to believe, because more incomplete frames seems like it has to mean fewer reference blocks available, but it might be what is meant and I don't know how the details of reference block selection interacts with frame parallelism.
__________________
madVR options explained Last edited by Asmodian; 22nd January 2019 at 22:40. |
||
22nd January 2019, 22:34 | #35 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
I read it as saying that frame-threads on/off can make a difference, but if frame threading is being used, the number of threads being used doesn't impact output quality.
This is not true with different number of frame-threads (with quality going down as the number goes up, although not nearly the impact it was in prior years). It might be true when frame-threads is constant but the number of threads in general varies. |
22nd January 2019, 22:51 | #36 | Link |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,407
|
But it explicitly says "the number of frame threads should have no effect on the output bitstream" which really doesn't seem like it could be true if it means size v.s. quality.
Oh wait, it means the number of threads working on each frame, not the number of frames being worked on at once?
__________________
madVR options explained |
23rd January 2019, 01:03 | #37 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
|
|
7th March 2019, 23:35 | #39 | Link | |
Registered User
Join Date: Jan 2015
Posts: 118
|
Quote:
Here is what I use: 1080P for high quality: CRF: 17 to 19 - depending on the movie type / image noise no-sao frame-threads=3 to 4 ctu=32 merange=27 me=3 subme=4 rd=4 deblock=-1;-1 no-strong-intra-smoothing bframes=4 ref=4 psy-rd=3.0 aq-mode=2 / aq=3 for dark movies level-idc=51 high-tier qcomp=0.63 vbv-maxrate=75000 vbv-bufsize=75000 4K HDR: CRF 17 to 19 - same as above --profile main10 --output-depth 10 --no-sao --frame-threads=3 --pme --hdr-opt --colorprim bt2020 --ctu=32 --qcomp=0.7 --no-strong-intra-smoothing --aq-mode=2 --deblock=-1:-1 --level-idc=51 --high-tier --qg-size=16 |
|
Tags |
handbrake, hevc, x265 |
Thread Tools | Search this Thread |
Display Modes | |
|
|