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 17th May 2023, 18:20   #81  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,824
Quote:
Originally Posted by HD MOVIE SOURCE View Post
Interesting, are you seeing better encodes using CTU=32? I've seen one encode where the QP only dropped by 0.1 on average, so I didn't know whether to use it or not.

In theory can CTU=32 grab more detail than 64? I might just run some tests for even lower than 32 just to see it.
I have seen --ctu 32 provide better quality with very grainy content at 4K and HD resolutions.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 3rd June 2023, 04:27   #82  |  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 have seen --ctu 32 provide better quality with very grainy content at 4K and HD resolutions.
Thats interesting. Does CTU=32 typically cost more bit-rate to use than CT=64? Is CTU=64, typically better for animation with plain objects, like plain skies, where CTU=64 would be more useful?
HD MOVIE SOURCE is offline   Reply With Quote
Old 18th June 2023, 04:02   #83  |  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 have seen --ctu 32 provide better quality with very grainy content at 4K and HD resolutions.
I noticed that --hme has some settings that goes with it.

--hme-search between 0,1,2. Is 2 the best? / Highest setting?

--hme-range between 0,1,2. Same question.

Is 2 for both settings maxed out?
HD MOVIE SOURCE is offline   Reply With Quote
Old 19th June 2023, 17:59   #84  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,824
Quote:
Originally Posted by HD MOVIE SOURCE View Post
Thats interesting. Does CTU=32 typically cost more bit-rate to use than CT=64? Is CTU=64, typically better for animation with plain objects, like plain skies, where CTU=64 would be more useful?
Yes, its main value is increased compression efficiency for big flatter/gradient areas. It's not a big improvement; 32x32 is already much bigger than prior codecs supported.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 19th June 2023, 18:06   #85  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,824
Quote:
Originally Posted by HD MOVIE SOURCE View Post
I noticed that --hme has some settings that goes with it.

--hme-search between 0,1,2. Is 2 the best? / Highest setting?

--hme-range between 0,1,2. Same question.

Is 2 for both settings maxed out?
The are documented here: https://x265.readthedocs.io/en/maste...search-options

--hme-search is 0-5, just replicating the --me options.
--hme-range replicates --merange, and so can be anything from 0 to 32768
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 26th June 2023, 21:29   #86  |  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
The are documented here: https://x265.readthedocs.io/en/maste...search-options

--hme-search is 0-5, just replicating the --me options.
--hme-range replicates --merange, and so can be anything from 0 to 32768
I appreciate it thanks. Have you experimented with any specific settings here? Are the defaults more than fine?

Is search best at 5, but say, the hme range to follow whichever settings you use for merange? Which for me is 57.
HD MOVIE SOURCE is offline   Reply With Quote
Old 27th June 2023, 22:41   #87  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,824
Quote:
Originally Posted by HD MOVIE SOURCE View Post
I appreciate it thanks. Have you experimented with any specific settings here? Are the defaults more than fine?

Is search best at 5, but say, the hme range to follow whichever settings you use for merange? Which for me is 57.
I've not found any material quality or performance benefit form using --hme instead of not. x265 doesn't seem to be doing frame or GOP level parallelism for the different sizes, so practical speed benefits are a real challenge. I believe the engineering was more focused on the UHDKit product's ability to simultaneously encode, for example, a 540p, 1080p, and 2160p with each higher resolution reusing the motion search of the prior resolution, and getting parallelism from that.

I can see some combination of coarser --me with a wider net (note that 24 px at the 25% size would be 96 px in the final frame) search range for the lower resolutions, and a more precise me with a smaller search range at the higher makes intuitive sense as a potential quality/speed tradeoff improvement. I've not dived deep to try and find that combination, however.

There was some early talk from MCW some years ago that --hme would help improve quality with very grainy content, as the low pass filtering of the downscales would exclude false positive motion vectors resulting from random grain matches, with the full resolution pass refining on the initial matches. Which makes intuitive sense, but I never saw an actual PoC of this benefit.

I didn't find any benefit in a couple of rounds of initial testing. It's on my backlog of things to noodle with further time permitting.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 29th June 2023, 03:57   #88  |  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've not found any material quality or performance benefit form using --hme instead of not. x265 doesn't seem to be doing frame or GOP level parallelism for the different sizes, so practical speed benefits are a real challenge. I believe the engineering was more focused on the UHDKit product's ability to simultaneously encode, for example, a 540p, 1080p, and 2160p with each higher resolution reusing the motion search of the prior resolution, and getting parallelism from that.

I can see some combination of coarser --me with a wider net (note that 24 px at the 25% size would be 96 px in the final frame) search range for the lower resolutions, and a more precise me with a smaller search range at the higher makes intuitive sense as a potential quality/speed tradeoff improvement. I've not dived deep to try and find that combination, however.

There was some early talk from MCW some years ago that --hme would help improve quality with very grainy content, as the low pass filtering of the downscales would exclude false positive motion vectors resulting from random grain matches, with the full resolution pass refining on the initial matches. Which makes intuitive sense, but I never saw an actual PoC of this benefit.

I didn't find any benefit in a couple of rounds of initial testing. It's on my backlog of things to noodle with further time permitting.
Interesting, thanks.
HD MOVIE SOURCE is offline   Reply With Quote
Old 1st July 2023, 21:01   #89  |  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've not found any material quality or performance benefit form using --hme instead of not. x265 doesn't seem to be doing frame or GOP level parallelism for the different sizes, so practical speed benefits are a real challenge. I believe the engineering was more focused on the UHDKit product's ability to simultaneously encode, for example, a 540p, 1080p, and 2160p with each higher resolution reusing the motion search of the prior resolution, and getting parallelism from that.

I can see some combination of coarser --me with a wider net (note that 24 px at the 25% size would be 96 px in the final frame) search range for the lower resolutions, and a more precise me with a smaller search range at the higher makes intuitive sense as a potential quality/speed tradeoff improvement. I've not dived deep to try and find that combination, however.

There was some early talk from MCW some years ago that --hme would help improve quality with very grainy content, as the low pass filtering of the downscales would exclude false positive motion vectors resulting from random grain matches, with the full resolution pass refining on the initial matches. Which makes intuitive sense, but I never saw an actual PoC of this benefit.

I didn't find any benefit in a couple of rounds of initial testing. It's on my backlog of things to noodle with further time permitting.
One thing I've noticed, and I think it's when I started using hme, and that's...Even when I set my encoder to placebo, me=2 gets set to 2 and I believe placebo should be set to 5. merange=48 gets set to 48 and placebo is 92.

I re-encoded with me=5 and that got set fine. However, I set merange to the default of 57 and it still gets set to 48. Is hme controlling this?
HD MOVIE SOURCE is offline   Reply With Quote
Old 1st July 2023, 22:05   #90  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,846
Quote:
Originally Posted by HD MOVIE SOURCE View Post
One thing I've noticed, and I think it's when I started using hme, and that's...Even when I set my encoder to placebo, me=2 gets set to 2 and I believe placebo should be set to 5. merange=48 gets set to 48 and placebo is 92.

I re-encoded with me=5 and that got set fine. However, I set merange to the default of 57 and it still gets set to 48. Is hme controlling this?
hme has its own search radius, which you can set using --hme-range
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 3rd July 2023, 01:59   #91  |  Link
HD MOVIE SOURCE
Registered User
 
HD MOVIE SOURCE's Avatar
 
Join Date: Mar 2021
Location: North Carolina
Posts: 138
Quote:
Originally Posted by microchip8 View Post
hme has its own search radius, which you can set using --hme-range
Okay, thank you. I haven't had much experience with this so I'm still learning how hme affects other settings. Thanks
HD MOVIE SOURCE is offline   Reply With Quote
Old 3rd July 2023, 17:46   #92  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,824
Quote:
Originally Posted by HD MOVIE SOURCE View Post
One thing I've noticed, and I think it's when I started using hme, and that's...Even when I set my encoder to placebo, me=2 gets set to 2 and I believe placebo should be set to 5. merange=48 gets set to 48 and placebo is 92.

I re-encoded with me=5 and that got set fine. However, I set merange to the default of 57 and it still gets set to 48. Is hme controlling this?
When you're using --hme, the --hme-search and --hme-range override --me and --me-range. So --preset has no impact on those.

To get a "placebo" --hme, you'd probably use

--hme-search 3,3,3 --hme-range 92,92,92

it's the last digit of each that's most important, as those are for the full resolution final pass. I imagine that

--hme-search 2,2,3 --hme-range 57,57,92

Would give you essentially equal results.

I don't think that --hme would offer much benefit at all in placebo. To get a better speed-quality benefit, something like the below would be more likely to be net beneficial. HME techniques are generally about improving quality @ speed, not maximum quality when not speed bound.

--hme-search 2,2,3 --hme-range 25,25,26

Where the motion search range can be constrained for the higher resolution passes as the coarser stages were able to identify good matches to refine in the later stages. a 25 range at quarter resolution maps to 100 at the final resolution.

(25 constrains motion search to 32x32 in hex, as does 26 to 32x32 in star. That allows another 32x32 row to be parallelized in WPP versus higher values).
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 11th July 2023, 22:07   #93  |  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
When you're using --hme, the --hme-search and --hme-range override --me and --me-range. So --preset has no impact on those.

To get a "placebo" --hme, you'd probably use

--hme-search 3,3,3 --hme-range 92,92,92

it's the last digit of each that's most important, as those are for the full resolution final pass. I imagine that

--hme-search 2,2,3 --hme-range 57,57,92

Would give you essentially equal results.

I don't think that --hme would offer much benefit at all in placebo. To get a better speed-quality benefit, something like the below would be more likely to be net beneficial. HME techniques are generally about improving quality @ speed, not maximum quality when not speed bound.

--hme-search 2,2,3 --hme-range 25,25,26

Where the motion search range can be constrained for the higher resolution passes as the coarser stages were able to identify good matches to refine in the later stages. a 25 range at quarter resolution maps to 100 at the final resolution.

(25 constrains motion search to 32x32 in hex, as does 26 to 32x32 in star. That allows another 32x32 row to be parallelized in WPP versus higher values).
I really appreciate the explanation on this, because I've been testing some search and range settings for hme and my encodes have been crashing. Now, you've provided the command lines to be more understandable I'll give them a try.

I've recently been testing placebo vs straight hme, and hme gave me 0.1 QP average QP more than not using it vs placebo that then uses me=5 and 92 for the merange.
Interestingly enough the hme encode was faster than placebo when just stating hme, and not stating the range or search values. So, I think you might be right that under placebo it may not be needed. However, now knowing what I can change, I might be able to eek more out of it, LOL.

Placebo with no hme = Job completed (Elapsed Time: 8h 16m)
Placebo with basic hme turned on = Job completed (Elapsed Time: 7h 09m)

Placebo with no hme average QP= Avg QP:8.74
Placebo with basic hme turned on = Avg QP:8.73

So, unless you can tune hme significantly with the settings you said
--hme-search 3,3,3 --hme-range 92,92,92, maybe there's some more quality to be gained? But, I assume you'd lose speed with these settings vs the default which is 16,32,48 for the range, but I'm not sure what for the search.

My media info says hme / Level / merange / L0,L1,L2=16,32,48, which is me just stating hme in the command line. I did a search for hme-search and that isn't there. I assume that you have to manually state that?

The big this is, is there a visual difference when using hme vs not using it when using placebo? Also, I wonder when the speed crosses over? Meaning, I wonder which preset hme becomes slower? Because the merange is always 57 on every other preset. If hme-range is the equivalent and by default only goes to 48, is hme always better to use?

hme-range <integer>,<integer>,<integer> is the last number the most important number? Does the first and second number matter if they are lower-resolution searches?

Thanks.

Last edited by HD MOVIE SOURCE; 11th July 2023 at 22:10.
HD MOVIE SOURCE is offline   Reply With Quote
Old 12th July 2023, 08:06   #94  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,846
If you're encoding Full HD or lower, I wouldn't bother with HME.
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 12th July 2023, 22:25   #95  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,824
Quote:
Originally Posted by HD MOVIE SOURCE View Post
My media info says hme / Level / merange / L0,L1,L2=16,32,48, which is me just stating hme in the command line. I did a search for hme-search and that isn't there. I assume that you have to manually state that?
It's the same values as --me and --me-range, so

--hme-search:
0: dia
1: hex (default)
2: umh
3: star
4: sea
5: full


Thus the default search modes for HME are Dia for 1/4 res, Hex for 1/2 res, and UMH for full res. --preset placebo uses 3: Star. So for placebo-equivalent you'd want at least the third --hme-search value to be 3.

Quote:
The big this is, is there a visual difference when using hme vs not using it when using placebo? Also, I wonder when the speed crosses over? Meaning, I wonder which preset hme becomes slower? Because the merange is always 57 on every other preset. If hme-range is the equivalent and by default only goes to 48, is hme always better to use?
You can always use --me 48. But the key goal of a HME algorithm is that you can do an initial coarse search at a lower resolution, and then refine with more accuracy but smaller search range as the resolutions go up. So, in theory, a --me 92 gets handled by having the first motion search range be 92/4=23. There are intricacies between search modes and such, but that's the basic idea.

Quote:
hme-range <integer>,<integer>,<integer> is the last number the most important number? Does the first and second number matter if they are lower-resolution searches?
I'm not sure which number is the most "important" - it gets down to finding the right combination of quality, speed.

Sure --hme-search 3,3,3 --hme-range 24, 48, 92 should match placebo quality, but I don't know that it would look better than placebo, or that it would save any encoding time.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 23rd September 2023, 16:50   #96  |  Link
N'Cha
Registered User
 
Join Date: Sep 2023
Posts: 28
[QUOTE=benwaggoner;1975353]
Quote:
Originally Posted by HD MOVIE SOURCE View Post
Hi,

I'm looking to find settings that increase detail and sharpness. In turn, I'm also looking for settings that apply blurring or softness and can be turned off.

Here are the settings that I know of so far that do this.
  1. subme=7 (A sharpener, detail increase)
  2. no-deblock / deblock (Blurring/detail loss the more deblock is used)
  3. no-sao / sao (High Blur)
  4. no-strong-intra-smoothing / strong-intra-smoothing (Smoother/Blur)
  5. psy-rd=-- & psy-rdoq=-- rdoq-level=-- (Detail increase as the cost of accuracy - Can look over-digital)
I am unaware of any evidence that --strong-intra-smoothing reduces visible detail in any scenario.
Nor does --deblock if used appropriately. Both will reduce detail at moderate-low bitrates, as they reduce compression efficiency and drive QPs higher, which itself is a low-pass filter. The HEVC built-in deblocking filter is better turned than H.264's.

--subme only goes up to 5 in --preset placebo. I've not seen visible quality improvements from using higher values.

If you have sharp synthetic details (text, line art, noise-free anime), --tskip can increase detail.

In theory --hme can help with very noisy content.
--amp and --rect can improve detail by allowing TUs to better match the shape of content, for example encoding a mild horizontal curve as 32x8 instead of forcing it to be square.

But in general, a lot of these things are controlled by the preset. It's best to pick the slowest preset that is fast enough, and start tweaking from there.


That "blurrs" differences in QP to reduce quality fluctuations. It has no direct impact on sharpness.


I'd start doing a test encode at --preset slower --crf 18 --no-sao and see if the detail retention and file size are okay for you. If not, tweak from there. Jumping in with parameters without having some reference encodes to compare with the source and each other makes for a lot more work.
Is it still your opinion that subme 7 is not sharper/more detailed than subme 5 ? (especially for anime)

Last edited by N'Cha; 23rd September 2023 at 16:59.
N'Cha is offline   Reply With Quote
Old 26th September 2023, 01:11   #97  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,824
Quote:
Originally Posted by N'Cha View Post
Is it still your opinion that subme 7 is not sharper/more detailed than subme 5 ? (especially for anime)
I haven't tested this is many years, but I'm not aware of any changes that could make a difference. MCW's testing showed that --subme 7 wasn't even worth using in --preset placebo.

If anyone has more recent or specific results, I'd love to hear about them!
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 22nd January 2024, 09:58   #98  |  Link
brad86
Registered User
 
Join Date: Jun 2019
Posts: 48
Recently found a good balance of settings and quality I would like for my encodes, except for one issues that I can not seem to fix.
I'm getting a great image overall with these settings, other than blurring near the top of the canvas. It's like it doesn't know how to handle the edge very well.
I would love to find a setting that can stop this. A lower CRF value (even 0 for testing) does not stop it. aq-strength, is really the only tweak I make between different films (1.0-1.3), but again, even a high value here does not help.

You can see the issue I'm having below.



My settings current settings are;
10-bit. CRF 17. Slow preset.
selective-sao=2:no-strong-intra-smoothing:rskip=2:rskip-edge-threshold=3:aq-mode=3:aq-strength=1.2:deblock=-3:-3
brad86 is offline   Reply With Quote
Old 22nd January 2024, 10:50   #99  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,764
Borders cropped off before encoding? Mod-8/16 vertical resolution?
__________________
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 22nd January 2024, 11:00   #100  |  Link
brad86
Registered User
 
Join Date: Jun 2019
Posts: 48
Quote:
Originally Posted by Boulder View Post
Borders cropped off before encoding? Mod-8/16 vertical resolution?
No cropping. I despise doing such a thing. It is as it is on my disc.
brad86 is offline   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:02.


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