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 4th November 2017, 00:19   #5681  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 63
CRF, preset, grain relationship

Hi,

CRF has obviously a direct influence on the Bitrate and therefor on the Quality.

but is guess the assumption is correct that:

- the slower the preset, the higher the Bitrate?
- using "--tune grain" also increases the Bitrate?

How big is the influence on those two?

if those two increase Bitrate, would it be feasible to increase CRF to a higher value while preserving the Quality and use a faster preset and skip --tune grain which could also speed up the encoding?

Basically I'll aks because I usually use CRF 22, "slower" and --tune grain, which is kind of slow of course and I'm wondering if there is an good alternative to that but faster?

cheers, roland
_kermit is offline   Reply With Quote
Old 4th November 2017, 10:18   #5682  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,717
--tune grain increases the need for bitrate. When I started using x265 as a replacement for x264, I just used --tune grain --preset slower and various CRF values to find out the spot where the visual quality is good enough for me to not notice degrading while watching. For what it's worth, I now use CRF 21.8 for my 720p encodes. I have cherry picked some items from the even slower presets though.

In x264, a slower preset usually means a lower bitrate with the same CRF.
__________________
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 4th November 2017, 11:07   #5683  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 322
Quote:
Originally Posted by Boulder View Post
--tune grain increases the need for bitrate. When I started using x265 as a replacement for x264, I just used --tune grain --preset slower and various CRF values to find out the spot where the visual quality is good enough for me to not notice degrading while watching. For what it's worth, I now use CRF 21.8 for my 720p encodes. I have cherry picked some items from the even slower presets though.

In x264, a slower preset usually means a lower bitrate with the same CRF.
One could think that it would work like that in x265, that it hit's the same quality (since it's crf) at a lower bitrate. But from what i've seen it's the other way arround, I get almost half the bitrate at preset fast compared to slow. The faster presets probably skips alot of fine detail retention.

Quote:
Originally Posted by _kermit View Post
Basically I'll aks because I usually use CRF 22, "slower" and --tune grain, which is kind of slow of course and I'm wondering if there is an good alternative to that but faster?

cheers, roland
Try to compare it to crf18, preset slow and --no-sao. No sao doesnt hurt speed and helps with detail retention at higher bitrates (and hurt overall image quality at lower). Should be 3-4x as fast, there will ofc be tradeoffs in compression (it doesn't just waste all that time).

Last edited by excellentswordfight; 4th November 2017 at 12:04.
excellentswordfight is offline   Reply With Quote
Old 4th November 2017, 13:35   #5684  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by _kermit View Post
Hi,

CRF has obviously a direct influence on the Bitrate and therefor on the Quality.

but is guess the assumption is correct that:

- the slower the preset, the higher the Bitrate?
- using "--tune grain" also increases the Bitrate?

How big is the influence on those two?

if those two increase Bitrate, would it be feasible to increase CRF to a higher value while preserving the Quality and use a faster preset and skip --tune grain which could also speed up the encoding?

Basically I'll aks because I usually use CRF 22, "slower" and --tune grain, which is kind of slow of course and I'm wondering if there is an good alternative to that but faster?

cheers, roland
You should not expect that the same CRF value still gives the same (approximately) quality after influential settings - especially the Preset/Tune - have been changed.

All you really know is that:
  • The same CRF value gives the same (approximately) quality for different sources, as long as no other settings are changed.
  • Using a slower preset improves the "quality per bit" ratio. Conversely, using a faster preset hurts the "quality per bit" ratio. But, in both cases, the absolute bitrate - at a fixed CRF value - may change more or less arbitrarily.

Or, in other words, when influential settings - especially the Preset/Tune - are changed, then the "meaning" of CRF values (in terms of resulting quality) can change as well!

Therefore, I would suggest to first pick the slowest Preset that you are willing to accept (in terms of encoding time). Then, while sticking with the chosen Preset, find the highest CRF value that still gives satisfying quality....

(And for testing Tune options, you should use 2-Pass mode, so that you get a "fair" comparison of files with identical average bitrates. Visually comparing files of different average bitartrates is misleading!)
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 4th November 2017 at 13:53.
LoRd_MuldeR is offline   Reply With Quote
Old 4th November 2017, 14:50   #5685  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 63
Quote:
Originally Posted by excellentswordfight View Post
One could think that it would work like that in x265, that it hit's the same quality (since it's crf) at a lower bitrate. But from what i've seen it's the other way arround, I get almost half the bitrate at preset fast compared to slow. The faster presets probably skips alot of fine detail retention.


Try to compare it to crf18, preset slow and --no-sao. No sao doesnt hurt speed and helps with detail retention at higher bitrates (and hurt overall image quality at lower). Should be 3-4x as fast, there will ofc be tradeoffs in compression (it doesn't just waste all that time).
my bad, I already use "slow", not slower. so I guess that wouldn't make a difference, but using CRF 18 certainly increases size a lot.
But does "slower" make it 3-4 times slower?
_kermit is offline   Reply With Quote
Old 4th November 2017, 15:03   #5686  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 63
Quote:
Originally Posted by LoRd_MuldeR View Post
You should not expect that the same CRF value still gives the same (approximately) quality after influential settings - especially the Preset/Tune - have been changed.

All you really know is that:
  • The same CRF value gives the same (approximately) quality for different sources, as long as no other settings are changed.
  • Using a slower preset improves the "quality per bit" ratio. Conversely, using a faster preset hurts the "quality per bit" ratio. But, in both cases, the absolute bitrate - at a fixed CRF value - may change more or less arbitrarily.

Or, in other words, when influential settings - especially the Preset/Tune - are changed, then the "meaning" of CRF values (in terms of resulting quality) can change as well!

Therefore, I would suggest to first pick the slowest Preset that you are willing to accept (in terms of encoding time). Then, while sticking with the chosen Preset, find the highest CRF value that still gives satisfying quality....

(And for testing Tune options, you should use 2-Pass mode, so that you get a "fair" comparison of files with identical average bitrates. Visually comparing files of different average bitartrates is misleading!)
alright. so far CRF 22 worked pretty well while using slow and grain.
So, if I skip grain, which costs a lot of time, I would either need to lower CRF (to what?) or use a slower preset (in my case "slower")?

Skipping "grain" may speed up encoding, "slower" would slow it down again and using a lower CRF improves Quality, compensating for the changes?

BTW: I already use --no-sao.

And that is applicable to 1080p and UHD?
_kermit is offline   Reply With Quote
Old 4th November 2017, 15:15   #5687  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by _kermit View Post
alright. so far CRF 22 worked pretty well while using slow and grain.
So, if I skip grain, which costs a lot of time, I would either need to lower CRF (to what?) or use a slower preset (in my case "slower")?

Skipping "grain" may speed up encoding, "slower" would slow it down again and using a lower CRF improves Quality, compensating for the changes?

BTW: I already use --no-sao.

And that is applicable to 1080p and UHD?
IMO, you should first decide what is the slowest Preset you are willing to use, in terms of encoding time. Then stick with that in the following.

Secondly, decide wether to use "--tune grain" or not. This can only be decided visually. And visual comparison requires both files to be compared to have exactly the same average bitrate - otherwise your visual comparison would be "unfair" and therefore meaningless/misleading. So, do two 2-Pass encodes - one with option "--tune grain" and one without it. And be sure to pick the same target average bitrate for both encodes. Also, the chosen target average bitrate for these 2-Pass encodes needs to be "reasonable", which means that it should be in the same range that your final encodes will be as well (i.e. the target average bitartrate should neither be unrealistically low, nor unrealistically high). Furthermore, you need to do this test with a source that represents the kind of stuff you are going to encode. Use the two resulting encodes to decide, visually, whether you prefer "--tune grain" or not. Then stick with that in the following.

Finally, now that you have decided the Preset and Tune, go figure out the highest possible CRF value that still gives satisfying result, quality-wise. Again this needs to be done visually, with an appropriate source, or a set of sources...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 4th November 2017 at 15:21.
LoRd_MuldeR is offline   Reply With Quote
Old 4th November 2017, 15:58   #5688  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 63
Quote:
Originally Posted by LoRd_MuldeR View Post
IMO, you should first decide what is the slowest Preset you are willing to use, in terms of encoding time. Then stick with that in the following.

Secondly, decide wether to use "--tune grain" or not. This can only be decided visually. And visual comparison requires both files to be compared to have exactly the same average bitrate - otherwise your visual comparison would be "unfair" and therefore meaningless/misleading. So, do two 2-Pass encodes - one with option "--tune grain" and one without it. And be sure to pick the same target average bitrate for both encodes. Also, the chosen target average bitrate for these 2-Pass encodes needs to be "reasonable", which means that it should be in the same range that your final encodes will be as well (i.e. the target average bitartrate should neither be unrealistically low, nor unrealistically high). Furthermore, you need to do this test with a source that represents the kind of stuff you are going to encode. Use the two resulting encodes to decide, visually, whether you prefer "--tune grain" or not. Then stick with that in the following.

Finally, now that you have decided the Preset and Tune, go figure out the highest possible CRF value that still gives satisfying result, quality-wise. Again this needs to be done visually, with an appropriate source, or a set of sources...
thanks!
_kermit is offline   Reply With Quote
Old 4th November 2017, 15:58   #5689  |  Link
excellentswordfight
Lost my old account :(
 
Join Date: Jul 2017
Posts: 322
Quote:
Originally Posted by _kermit View Post
my bad, I already use "slow", not slower. so I guess that wouldn't make a difference, but using CRF 18 certainly increases size a lot.
But does "slower" make it 3-4 times slower?
Slower together with tune grain is that much slower yes, or atleast if the source is of very high quality/detailed/grainy.

I use slow, no-sao, crf18 for 1080p and crf22 for UHD. This is my sweetspot for compression/speed ratio. It doesnt give me visually lossless encodes (which i wouldnt use x265 for anyway), but they are most definitely transparent under normal viewing conditions. I found that for 1080p crf22 without tune grain isnt enough to keep fine details on grainy/detailed sources, but that crf18 with only no-sao is close enough.

LoRd_MuldeR is giving you a very good base for doing tests that will lead you to your sweetspot.

Last edited by excellentswordfight; 4th November 2017 at 16:09.
excellentswordfight is offline   Reply With Quote
Old 4th November 2017, 16:04   #5690  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,717
--tune grain disables recursion skip which makes things really slow. I forgot to mention that I use --rskip to re-enable it, I've not seen any side effects for doing that.
__________________
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 4th November 2017, 16:20   #5691  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 63
Quote:
Originally Posted by excellentswordfight View Post
Slower together with tune grain is that much slower yes, or atleast if the source is of very high quality/detailed/grainy.

I use slow, no-sao, crf18 for 1080p and crf22 for UHD. This is my sweetspot for compression/speed ratio. It doesnt give me visually lossless encodes (which i wouldnt use x265 for anyway), but they are most definitely transparent under normal viewing conditions. I found that for 1080p crf22 without tune grain isnt enough to keep fine details on grainy/detailed sources, but that crf18 with only no-sao is close enough.

LoRd_MuldeR is giving you a very good base for doing tests that will lead you to your sweetspot.
grain on 1080p is actually ok, it's UHD were it gets really slow and I might use rskip as mentioned.
We have similar Settings, so I guess I'm good as Long as I can Speed up uhd a bit also.
_kermit is offline   Reply With Quote
Old 4th November 2017, 18:16   #5692  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 63
Quote:
Originally Posted by Boulder View Post
--tune grain disables recursion skip which makes things really slow. I forgot to mention that I use --rskip to re-enable it, I've not seen any side effects for doing that.
that's a good tip. thanks.
_kermit is offline   Reply With Quote
Old 7th November 2017, 06:46   #5693  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,480
x265.exe 2.5+37-aa9649a2aa8c

https://forum.videohelp.com/threads/...68#post2501168
Midzuki is offline   Reply With Quote
Old 7th November 2017, 13:49   #5694  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
Version 2.5+38 will introduce a new parameter pair to "denote VBV emptiness after inserting all the frames into it".

Quote:
This enables basic support for chunk-parallel encoding where each segment can specify the starting and ending state of the VBV buffer so that VBV compliance can be maintained when chunks are independently encoded and stitched together.
Release withheld due to a cosmetic issue in the produced help text (missing line breaks).
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 8th November 2017, 10:46   #5695  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
x265 2.5+47-6a882a9300c2

Speed-ups, API changes, more internal analysis features, new CLI parameters:

Code:
   --vbv-end <float>             Final VBV buffer emptiness (fraction of bufsize or in kbits). Default 0 (disabled)
   --vbv-end-fr-adj <float>      Frame from which qp has to be adjusted to achieve final decode buffer emptiness. Default 0
   --lowpass-dct                 Use low-pass subband dct approximation. Default disabled
   --refine-mv-type <string>     Reuse MV information received through API call. Supported option is avc. Default disabled - 0
Docs: refine-mv-type, vbv-end
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 8th November 2017 at 12:45.
LigH is offline   Reply With Quote
Old 9th November 2017, 01:23   #5696  |  Link
Magik Mark
Registered User
 
Join Date: Dec 2014
Posts: 666
Thanks for the new switches.

I was just wondering what could be a good value for these switches in order to optimize my encoding? Does it have any prerequisites?
__________________
Asus ProArt Z790 - 13th Gen Intel i9 - RTX 3080 - DDR5 64GB Predator - LG OLED C9 - Yamaha A3030 - Windows 11 x64 - PotPlayerr - Lav - MadVR
Magik Mark is offline   Reply With Quote
Old 9th November 2017, 05:31   #5697  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by Magik Mark View Post
Thanks for the new switches.

I was just wondering what could be a good value for these switches in order to optimize my encoding? Does it have any prerequisites?
None of these are likely to help you.
--vbv-end
--vbv-end-fr-adj
are only useful for companies who want to do segmented encoding

--lowpass-dct has potential to speed up encoding for faster presets, but it was just contributed (thank you!), and we haven't had a chance to run the experiments that will help us understand where and when it makes sense to use in terms of speed vs. efficiency.
--refine-mv-type <string> is only useful for 2 pass encoding where the first encoder is different than x265... like, a hardware encoder that can do a lower efficiency, but fast first pass. This won't help anyone doing x265 software encodes. This is all still highly developmental.
  Reply With Quote
Old 9th November 2017, 05:37   #5698  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,255
@MagikMark:
As far as I see:
'vbv-end' is only useful if you want to stitch together multiple encodes and 'vbv-end-fr-adj' requires the use of '--frames' when used with pipe input so that x265 does know the frame count of the input.
'lowpas-dct' is only for those in the need for speed and quality isn't your concern. ('Empirical analysis shows marginal loss in compression and performance gains up to 10%, paticularly at moderate bit-rates.' see: https://x265.readthedocs.io/en/lates...on-lowpass-dct)
'refine-mv-type' <- not sure how to use this and when this could really help, see: http://x265.readthedocs.io/en/latest...refine-mv-type
-> you probably don't want to use these values at all


Cu Selur

Ps.: x265_Project was faster
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 13th November 2017, 15:19   #5699  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
A recent API change made libx265 temporarily incompatible with e.g. ffmpeg calling it in C convention; a patch converting C++ style to C style is submitted in the mailing list but not yet commited to the repo...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 13th November 2017, 23:41   #5700  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,986
What's the usefulness of these new VBV params when you're doing segment encoding?
Blue_MiSfit 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 04:17.


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