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. |
4th November 2017, 00:19 | #5681 | Link |
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 |
4th November 2017, 10:18 | #5682 | Link |
Pig on the wing
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... |
4th November 2017, 11:07 | #5683 | Link | |
Lost my old account :(
Join Date: Jul 2017
Posts: 322
|
Quote:
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. |
|
4th November 2017, 13:35 | #5684 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
All you really know is that:
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. |
|
4th November 2017, 14:50 | #5685 | Link | |
Registered User
Join Date: Apr 2017
Posts: 63
|
Quote:
But does "slower" make it 3-4 times slower? |
|
4th November 2017, 15:03 | #5686 | Link | |
Registered User
Join Date: Apr 2017
Posts: 63
|
Quote:
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? |
|
4th November 2017, 15:15 | #5687 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
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. |
|
4th November 2017, 15:58 | #5688 | Link | |
Registered User
Join Date: Apr 2017
Posts: 63
|
Quote:
|
|
4th November 2017, 15:58 | #5689 | Link | |
Lost my old account :(
Join Date: Jul 2017
Posts: 322
|
Quote:
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. |
|
4th November 2017, 16:04 | #5690 | Link |
Pig on the wing
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... |
4th November 2017, 16:20 | #5691 | Link | |
Registered User
Join Date: Apr 2017
Posts: 63
|
Quote:
We have similar Settings, so I guess I'm good as Long as I can Speed up uhd a bit also. |
|
7th November 2017, 13:49 | #5694 | Link | |
German doom9/Gleitz SuMo
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:
|
|
8th November 2017, 10:46 | #5695 | Link |
German doom9/Gleitz SuMo
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 Last edited by LigH; 8th November 2017 at 12:45. |
9th November 2017, 01:23 | #5696 | Link |
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 |
9th November 2017, 05:31 | #5697 | Link | |
Guest
Posts: n/a
|
Quote:
--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. |
|
9th November 2017, 05:37 | #5698 | Link |
Registered User
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 |
13th November 2017, 15:19 | #5699 | Link |
German doom9/Gleitz SuMo
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...
|
Thread Tools | Search this Thread |
Display Modes | |
|
|