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.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 3rd November 2022, 17:44   #41  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,331
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.
jpsdr is offline   Reply With Quote
Old 8th November 2022, 00:52   #42  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,824
I don't recall anything HDR-specific about --hevc-aq.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 9th November 2022, 07:23   #43  |  Link
HD MOVIE SOURCE
Registered User
 
HD MOVIE SOURCE's Avatar
 
Join Date: Mar 2021
Location: North Carolina
Posts: 138
Quote:
Originally Posted by benwaggoner View Post
I suspect the gap will be larger with a more representative number of frames. You need to encode a decent multiple of --keyint to get accurate performance numbers. 10 frames is less than default --rc-lookahead, and fps is typically way higher for the --rc-lookahead duration.

--rc-lookahead is really a secret weapon for improving quality and reducing quality fluctuations with single-pass encoding.
Sorry for the late response to this one, but what if I'm using constant rate factor with a keyint of 24 and an rc-lookahead of 24. Is there any quality gains to be had past this? I used to try 48 for rc-lookahead to be 1 second in front just to cover my back, but I was told that going over the keyint is never worth it / a waste of time.

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.
HD MOVIE SOURCE is offline   Reply With Quote
Old 9th November 2022, 07:35   #44  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,991
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 :)
Blue_MiSfit is offline   Reply With Quote
Old 10th November 2022, 07:15   #45  |  Link
HD MOVIE SOURCE
Registered User
 
HD MOVIE SOURCE's Avatar
 
Join Date: Mar 2021
Location: North Carolina
Posts: 138
Quote:
Originally Posted by Blue_MiSfit View Post
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
Thats the keyint required for uhd-bd=1.
HD MOVIE SOURCE is offline   Reply With Quote
Old 10th November 2022, 22:23   #46  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,824
Quote:
Originally Posted by HD MOVIE SOURCE View Post
Thats the keyint required for uhd-bd=1.
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 30th November 2022, 07:19   #47  |  Link
HD MOVIE SOURCE
Registered User
 
HD MOVIE SOURCE's Avatar
 
Join Date: Mar 2021
Location: North Carolina
Posts: 138
Quote:
Originally Posted by benwaggoner View Post
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.
Good question, honestly not sure. I've always thought UHD-bd was always a 1 second GOP. I may have tried 2 seconds before and I think the encode failed, but I could be wrong.
HD MOVIE SOURCE is offline   Reply With Quote
Old 1st December 2022, 01:57   #48  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,824
Quote:
Originally Posted by HD MOVIE SOURCE View Post
Good question, honestly not sure. I've always thought UHD-bd was always a 1 second GOP. I may have tried 2 seconds before and I think the encode failed, but I could be wrong.
I don't know if UHD-BD's spec allows for 2-sec GOP in any case. UHD BD was intentionally as small as possible delta from the original Blu-ray spec. it's basically support for higher density discs plus HEVC 4K. But all the BD-J and overlays are still only 1080p.

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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 1st December 2022, 02:13   #49  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,824
Quote:
Originally Posted by HD MOVIE SOURCE View Post
Sorry for the late response to this one, but what if I'm using constant rate factor with a keyint of 24 and an rc-lookahead of 24. Is there any quality gains to be had past this? I used to try 48 for rc-lookahead to be 1 second in front just to cover my back, but I was told that going over the keyint is never worth it / a waste of time.
--rc-lookahead is capped at --keyint in any case, so it doesn't really matter.

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:
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.
--aq-mode 3 is identical to --aq-mode 2 except that it lowers QP as luma values get nearer to black. This gets around Rec. 709's perceptual non-uniformity, where the difference between luma of 16 and 17 is much more visible than between, say 216 and 217. So the same compression artifacts can be much more visible near black than near white.

--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
And make --aq-mode 3 essentially an alias to

Code:
--aq-mode 2 --low-luma-bias 1.0
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 1st December 2022, 05:57   #50  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,764
Quote:
Originally Posted by benwaggoner View Post
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
And make --aq-mode 3 essentially an alias to

Code:
--aq-mode 2 --low-luma-bias 1.0
For example jpsdr's recent x265 mods have this kind of a feature. There is the parameter --aq-bias-strength which is a multiplier on top of aq-strength. I believe it should make --sbrc work more efficiently. (aq-mode 5 mentioned here is aq-mode 4 + low luma bias)

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...
Boulder is offline   Reply With Quote
Old 1st December 2022, 12:30   #51  |  Link
madey83
Guest
 
Posts: n/a
Quote:
Originally Posted by benwaggoner View Post
--rc-lookahead is capped at --keyint in any case, so it doesn't really matter.

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.


--aq-mode 3 is identical to --aq-mode 2 except that it lowers QP as luma values get nearer to black. This gets around Rec. 709's perceptual non-uniformity, where the difference between luma of 16 and 17 is much more visible than between, say 216 and 217. So the same compression artifacts can be much more visible near black than near white.

--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
And make --aq-mode 3 essentially an alias to

Code:
--aq-mode 2 --low-luma-bias 1.0


Hi,

What could be your settings recommendation for Dolby vision encoder to have quite small file for 43 minutes episode ( 1-1.5GB)?
  Reply With Quote
Old 4th December 2022, 06:40   #52  |  Link
HD MOVIE SOURCE
Registered User
 
HD MOVIE SOURCE's Avatar
 
Join Date: Mar 2021
Location: North Carolina
Posts: 138
Quote:
Originally Posted by benwaggoner View Post
--rc-lookahead is capped at --keyint in any case, so it doesn't really matter.

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.


--aq-mode 3 is identical to --aq-mode 2 except that it lowers QP as luma values get nearer to black. This gets around Rec. 709's perceptual non-uniformity, where the difference between luma of 16 and 17 is much more visible than between, say 216 and 217. So the same compression artifacts can be much more visible near black than near white.

--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
And make --aq-mode 3 essentially an alias to

Code:
--aq-mode 2 --low-luma-bias 1.0
Very valuable info, thank you. I'd be interested in trying the 5x keyint for lookahead. Does higher lookahead require much more processing time? If so, it really depends on what can be gained from 5x lookahead.

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.
HD MOVIE SOURCE is offline   Reply With Quote
Old 7th December 2022, 20:10   #53  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,824
Quote:
Originally Posted by Boulder View Post
For example jpsdr's recent x265 mods have this kind of a feature. There is the parameter --aq-bias-strength which is a multiplier on top of aq-strength. I believe it should make --sbrc work more efficiently. (aq-mode 5 mentioned here is aq-mode 4 + low luma bias)

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.
Well, that's just lovely! Have these changes been contributed back to MCW for x265? I've exactly this feature with MCW developers before, and they showed some interest.

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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 8th December 2022, 06:00   #54  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,764
Quote:
Originally Posted by benwaggoner View Post
Well, that's just lovely! Have these changes been contributed back to MCW for x265? I've exactly this feature with MCW developers before, and they showed some interest.

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.
Unfortunately not, at least I've not seen it discussed in the x265-devel list. In my opinion, it is too difficult to contribute since it's not just about submitting a pull request but requires more effort.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 9th December 2022, 22:18   #55  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,824
Quote:
Originally Posted by madey83 View Post
What could be your settings recommendation for Dolby vision encoder to have quite small file for 43 minutes episode ( 1-1.5GB)?
Profile 5 or 8.1?

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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 9th December 2022, 22:27   #56  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,824
Quote:
Originally Posted by HD MOVIE SOURCE View Post
Very valuable info, thank you. I'd be interested in trying the 5x keyint for lookahead. Does higher lookahead require much more processing time? If so, it really depends on what can be gained from 5x lookahead.
--rc-lookahead can't be higher than --keyint. For single pass encodes when I have enough RAM and time, I try to use keyint=rc-lookahead.

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:
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?
Yeah, --aq-mode 3 lowers QP near black, and so a gradient that has one end that dark will benefit from it.

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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 10th December 2022, 21:28   #57  |  Link
madey83
Guest
 
Posts: n/a
Quote:
Originally Posted by benwaggoner View Post
Profile 5 or 8.1?

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.
Hi,
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
  Reply With Quote
Old 10th December 2022, 22:33   #58  |  Link
HD MOVIE SOURCE
Registered User
 
HD MOVIE SOURCE's Avatar
 
Join Date: Mar 2021
Location: North Carolina
Posts: 138
Quote:
Originally Posted by benwaggoner View Post
--rc-lookahead can't be higher than --keyint. For single pass encodes when I have enough RAM and time, I try to use keyint=rc-lookahead.

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.


Yeah, --aq-mode 3 lowers QP near black, and so a gradient that has one end that dark will benefit from it.

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.
Great info, thank you.
HD MOVIE SOURCE is offline   Reply With Quote
Old 12th December 2022, 22:03   #59  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,824
Quote:
Originally Posted by madey83 View Post
Hi,
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
Profile 5 can be somewhat challenging for an encoder, as it shifts the PQ EOTF to maximize the dynamic range of the current shot. So, if encoding something that's only 100 nits, it'll expand the Y' range higher so there are more code values.

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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 13th December 2022, 11:11   #60  |  Link
madey83
Guest
 
Posts: n/a
Quote:
Originally Posted by benwaggoner View Post
Profile 5 can be somewhat challenging for an encoder, as it shifts the PQ EOTF to maximize the dynamic range of the current shot. So, if encoding something that's only 100 nits, it'll expand the Y' range higher so there are more code values.

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.
Hi,

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.
  Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 00:18.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.