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 November 2022, 17:44 | #41 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,375
|
I took a quick look at the part code of hevc-aq, and it realy doesn't look like aq-mode 4...
Real question : Is the purpose of hevc-aq of being more suitable to HDR-PQ than the others standard aq-mode ? (If i ask this it's because of the hevc part in the name... )
__________________
My github. |
9th November 2022, 07:23 | #43 | Link | |
Registered User
Join Date: Mar 2021
Location: North Carolina
Posts: 138
|
Quote:
Responding to some thoughts about aq-modes. I have personally found that aq-mode 3 seems to be best for all the content that Ive encoded, and seems to cover your back with any scenes that have black level detail. One thing that I noticed is that using aq-mode 3, and with a relatively high strength like 1.7 seems to remove microbanding, and any odd banding or bit-depth errors. Last edited by HD MOVIE SOURCE; 9th November 2022 at 07:37. |
|
9th November 2022, 07:35 | #44 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,997
|
Any reason you're punching yourself in the face with such a short keyint? I'd suggest at least 2 seconds (and ideally 4-10) to let x265 stretch its legs
I don't think there's any benefit to rc-lookahead > keyint but I'll let Ben chime in on that
__________________
These are all my personal statements, not those of my employer :) |
10th November 2022, 22:23 | #46 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,893
|
OG Blu-ray would allow a 2-sec GOP if the --vbv-maxrate was 15000 Kbps or below. Does UHD-BD have any equivalent option?
Back when I was trying to fit BD content on a DVD-R, I'd often use the 15 Mbps cap so I could get the longer GOPs. Going to level 4.0 instead of 4.1 also eliminates the requirement for four slices, although takes the vbv-maxrate down to 25 Mbps from 40 Mbps. With a 2 sec GOP and single slice, most 1080p24 content could still look excellent at a 15 Mbps peak, and the improved efficiency would make average quality better than with higher peaks but with slices and 1 sec GOP. Only mattered when trying to stick a good amount of content on a small disc, though. |
30th November 2022, 07:19 | #47 | Link | |
Registered User
Join Date: Mar 2021
Location: North Carolina
Posts: 138
|
Quote:
|
|
1st December 2022, 01:57 | #48 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,893
|
Quote:
I don't think that the special <25 Mbps (can use a single slice instead of 4) or <15 Mbps (can use 2 sec GOP) modes were used much (if ever) with commercial discs, nor was consumer authoring a concern with the UHD upgrade, so it'd be unsurprising if there's no equivalent. |
|
1st December 2022, 02:13 | #49 | Link | ||
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,893
|
Quote:
I've certainly seen valuable quality improvements (specifically big reductions in quality variations that yield visibly poor quality) when increasing keyint and rc-lookahead from 2 to 5 seconds, and that was mostly due to the higher --rc-lookahead (comparing --keyint 120 --rc-lookahead 48 versus 128). That said, --rc-lookahead is most impactful with single-pass --crf encodes. It offers benefit with 1-pass CBR, but a full two-pass encode is basically rc-lookahead=total frames. Quote:
--aq-mode 3 can really help shadow detail and reduce banding near black. However, those lower QPs use more bits. For CBR and VBV-limited encodes, this increases QP of brighter frames, which can introduce new quality issues. Or in CRF mode, increase ABR quite a bit. It's a great tool when there's enough bandwidth, but needs to be used delicately at lower bitrates. It's not a safe feature to just leave always on when targeting best possible quality at low bitrates. It helps sometimes, and hurts others. Lower --aq-strength values are optimal with aq-mode 3 than 2 as well, as high values can really starve brighter macroblocks of bits. It's also not appropriate for HDR-10, which is much more perceptually uniform, and where the visible difference between luma values is pretty much identical at any brightness. 10-bit encoding can make --aq-mode less needed as well, as the difference between 8-bit 16 and 17 now is the difference between 64 and 68, and those four extra steps make for more efficient encoding, reduce the need for dithering, and generally makes for much less visible banding and blocking. I'm confident that --aq-mode 3 could be improved to be more content-adaptive. It'd prefer x264 to have aq-mode algorithm selection decouple from luma bias. So we could do stuff like Code:
--aq-mode 4 --low-luma-bias 0.7 Code:
--aq-mode 2 --low-luma-bias 1.0 |
||
1st December 2022, 05:57 | #50 | Link | |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,803
|
Quote:
Code:
--aq-bias-strength <float> Adjust the strength of dark scene bias in AQ modes 3 and 5. Setting this to 0 will disable the dark scene bias, meaning modes will be equivalent to their unbiased counterparts (2 and 4). Default 1.0.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
|
1st December 2022, 12:30 | #51 | Link | |
Guest
Posts: n/a
|
Quote:
Hi, What could be your settings recommendation for Dolby vision encoder to have quite small file for 43 minutes episode ( 1-1.5GB)? |
|
4th December 2022, 06:40 | #52 | Link | |
Registered User
Join Date: Mar 2021
Location: North Carolina
Posts: 138
|
Quote:
I have thought about having bit-rate starved on brighter scenes, but I haven't found it to be an issue when bit-rates are high enough. I guess it could be an issue for bit-rate-restricted content. I typically find that black-level detail can still be an issue even on 4K discs. So even using it as a tool to distribute more bits into black-level detail is useful. Do you think this is why it potentially could improve gradients from black to full color? Because there are more bits being distributed in the low end of the spectrum and now the gradients look smoother? Last edited by HD MOVIE SOURCE; 5th December 2022 at 07:13. |
|
7th December 2022, 20:10 | #53 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,893
|
Quote:
I don't really use other private forks much to keep my settings compatible with other x265 implementations. I'm going to try this one out; I have some content types where those tweaks could really make a difference. |
|
8th December 2022, 06:00 | #54 | Link | |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,803
|
Quote:
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
|
9th December 2022, 22:18 | #55 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,893
|
Quote:
Those file sizes give around 3-4.5 Mbps; pretty darn low for 4K. I'd look at scaling down to 1080p or maybe 1440p. I think only clean animation would encode well at those bitrates. Something with even light noise might require --crf 30 at full resolution. 2-pass encoding could be preferable as final file sizes would vary a lot depending on source specifics. The job is more about artifact suppression than fine detail retention at those bitrates. So definitely you'll want --sao, default in-loop deb locking, some --nr-intra, maybe some <100 --nr-inter. And I'd start with --preset slower at a minimum. |
|
9th December 2022, 22:27 | #56 | Link | ||
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,893
|
Quote:
There is some slowdown with higher values, but I find it's relatively cheap as quality/speed tradeoff features go. The bigger limitation is the RAM requirements, which can increase almost linearly with --rc-lookahead. I've had a 60 GB single x265 process doing 8K 10-bit encoding with --rc-lookahead 96. Quote:
Using 10-bit instead of 8-bit can also really help gradients in general. And use the --dither parameter if you're encoding at a lower color depth than the source, which can help reduce 8-bit SDR banding as well. Lots of these things are bitrate related. If you have enough bits, they may not be much of an issue. But if trying to really maximize bang for the bit, careful tuning can really help. Optimal --aq-mode and --aq-strength can vary quite a bit in different shots and scenes. A whole lot of deep amazing things can be done using x265 as .dll instead of an .exe, where some parameters can be varied by GOP, frame, and even CU. It'd be lovely to have some sort of standard XML syntax for .dll specific tweaks with an .exe that would parse those and pass them on to the .dll in a predictable and portable way. |
||
10th December 2022, 21:28 | #57 | Link | |
Guest
Posts: n/a
|
Quote:
Sorry but I did not mention that I will downscale to 1080p profile 5 as original source and for noise source I'd probably use some denise filter. My preference for encode is crf |
|
10th December 2022, 22:33 | #58 | Link | |
Registered User
Join Date: Mar 2021
Location: North Carolina
Posts: 138
|
Quote:
|
|
12th December 2022, 22:03 | #59 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,893
|
Quote:
This looks a lot like fades to the encoder, so having p- and b-frame weighted prediction on is important. The --fades feature could help as well, although I've never actually gotten it to result in different output than not using it. The expanded range can also through off tools that presume encoding to actually perceptually linear code values. The impact of --nr-* could vary in strength on the same content if they got mapped to different code values. The broader range of code values the image gets mapped to, the stronger the AC coefficients will be, and so the less impact a given --nr-* strength would have. Long way of saying that it might be better to apply denoising in uncompressed PQ ICtCp before or after scaling, and send denoised frames to the encoder instead of using the built-in tools. I've not actually tested this empirically, but it seems kind of inevitable barring some DoVi Profile 5 specific optimization in x265 that would compensate for the range expansion. |
|
13th December 2022, 11:11 | #60 | Link | |
Guest
Posts: n/a
|
Quote:
Thank you for this but this is to deep explanation for me. I have found below and I would like to ask if belove settings are good or there is something to change to get better results: Cry Macho 2021 1080p UHD BluRay DD+5.1 DoVi x265-DON Writing library : x265 3.5+39-931178347:[Windows][MSVC 1933][64 bit] 10bit Encoding settings : cpuid=1049583 / frame-threads=4 / numa-pools=24 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x804 / interlace=0 / total-frames=0 / level-idc=51 / high-tier=1 / uhd-bd=0 / ref=6 / no-allow-non-conformance / repeat-headers / annexb / aud / no-eob / no-eos / hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=16 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=40 / lookahead-slices=4 / scenecut=40 / no-hist-scenecut / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=4 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=4 / limit-refs=1 / limit-modes / me=3 / subme=5 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / weightb / no-analyze-src-pics / deblock=-3:-3 / no-sao / no-sao-non-deblock / rd=4 / selective-sao=0 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=2.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=13.7 / qcomp=0.80 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=160000 / vbv-bufsize=160000 / vbv-init=0.9 / min-vbv-fullness=50.0 / max-vbv-fullness=80.0 / crf-max=0.0 / crf-min=0.0 / ipratio=1.20 / pbratio=1.10 / aq-mode=1 / aq-strength=0.85 / no-cutree / zone-count=8 / zones: / start-frame=112 / end-frame=430 / bitrate-factor=4.000000 / zones: / start-frame=14684 / end-frame=15005 / bitrate-factor=7.000000 / zones: / start-frame=16507 / end-frame=17008 / bitrate-factor=1.500000 / zones: / start-frame=17009 / end-frame=17145 / bitrate-factor=2.000000 / zones: / start-frame=17601 / end-frame=23536 / bitrate-factor=2.500000 / zones: / start-frame=31365 / end-frame=37290 / bitrate-factor=3.000000 / zones: / start-frame=44733 / end-frame=50608 / bitrate-factor=3.000000 / zones: / start-frame=140360 / end-frame=140415 / bitrate-factor=3.000000 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=16 / colormatrix=9 / chromaloc=1 / chromaloc-top=2 / chromaloc-bottom=2 / display-window=0 / master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50) / cll=1134,104 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / hdr10 / hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass Of course without providing zones to encoder. Last edited by madey83; 13th December 2022 at 12:03. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|