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. |
7th August 2012, 14:55 | #1 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
Tweaking x264 for Dark Games.
Okay i would like to know what the good settings are for Dark Games, as x264 is known to be a bit bad with the wrong settings and will blur the darkness to much, and will also do some really nasty Banding.
What settings should be on to reduce this? Film Tuning? No-Fast-p-Skip? A minimum on B,Reference Frames? Thanks! (Size isnīt a real problem, i can do 1-2gb for 20min if necessary. We are talking 720p and 1080p* Last edited by Guest; 7th August 2012 at 16:31. |
7th August 2012, 23:38 | #2 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Yes, I think the "film" tuning is a good idea for this kind of footage.
In order to avoid the banding, going with 10-Bit x264 probably is the best idea. Either that or using GradFun2db() at playback time. About the "no-fast-pskip" option: http://forum.doom9.org/showthread.ph...29#post1384029
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
7th August 2012, 23:57 | #3 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
10 bit is sadly not an option as Youtube doesnīt support it (atleast they didnīt when i last tried?).
And yes i know Youtube till kill the bitrate and add banding, but itīs better to have a clean picture getting crushed, than a crushed picture right XD? Is Debanding really a good idea? I mean the Banding is there on gameplay as well, but to a lesser degree of course, isnīt it meant to be banding? |
8th August 2012, 00:04 | #5 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Yes, as far as I know Youtube will always re-encode.
All you can do is uploading the best quality source you can, but the big quality loss is going to happen in their re-encoding. And there's not much you can do about that, as you have no influence on what they do. And debanding/dithering is a good idea. But an 8-Bit encoding won't be able to retain the dither. So when encoding at 8-Bit, you'd have to do the debanding/dithering at playback time...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
8th August 2012, 11:26 | #6 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
Yeah sadly they donīt allow us to encode without re-encode.
But there isnīt some Golden Rule for best allowing Dark stuff to remain? like MB-Tree off or something? And of course Very high bitrate. (what bitrate are we talking, 720p at 8k?) Hmm, will look at the debanding, but not sure if i will use it, will see how it messes with the video Edit: seems pretty nice wiht debanding, though it "Kills" the color in the places, though that doesnīt matter as the color are like bad painting or something (banding stuff). But is GradFun2db() the Best in terms of speed/quality? I though the 3 was out? Last edited by zerowalker; 8th August 2012 at 11:31. |
8th August 2012, 12:35 | #7 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Why do you worry so much about the details of your encode, if they are going to re-encode anyway and the "real" loss is going to happen on their side?
Alos I think using GradFun2db() or a similar dithering tool is pointless in this case - the dither probably isn't going to survive your 8-Bit encode. And, after that, there will be a second re-encode! After all, I would simply go with "--tune film" plus a sufficiently low CRF value (or even "lossless" mode, if Youtube can process that) and then hope they won't screw it up too much...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
8th August 2012, 12:45 | #8 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
I know itīs weird, but itīs like this:
Before i had slow upload, so i did, Slower Preset and tried to make the best with low size. Now i have fast (800kilobyte up or something), so now i can make much better and faster preset. So now i want to encode it as "lossless" as possibly, so that Youtube wonīt Crush it more than necceserry. I know itīs not Black and White difference, but it will reduce the blurring of details to some degree if itīs left as intact as possible. oh, so GradFun2db() is wasted? if so i will just skip it. Yeah but what is suffient for dark stuff? I canīt really go lossless (20gb for 20min is a Bit to much;P). I currently use Medium Preset, Tune Film, and CRF 16. |
8th August 2012, 13:08 | #9 | Link |
Registered User
Join Date: Jul 2008
Posts: 532
|
That's what I'm doing when there are a lot of dark scenes with Preset=Slower, Tune=Film and a CRF between 18 and 22. I wouldn't say it's a magic rule but it's working fine for me
http://forum.doom9.org/showthread.ph...33#post1476033 |
8th August 2012, 15:06 | #10 | Link |
Guest
Posts: n/a
|
just dedicate more "bits" to the background to lessen banding ...
I find --aq-strength between 1.1 and 1.3 beneficial to reduce dark banding and blocking (and to counteract the MB-tree affect) ... I also find --no-dct-decimate to also preserve a little more dark detail ... However, if you are not constrained for filesize than the absolute best way is reducing CRF (I find I have to go as low as CRF 16 with the above mentioned features on some 720p footage to reduce banding and dark blocking) ... 7ek |
8th August 2012, 15:32 | #11 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
If so and if you have the required bandwidth, then going lossless is a good way, because it ensures there is absoloutely no quality loss, before Youtube starts to re-encode. But on the other hand, I doubt you will be able to spot the difference from their final encode between a lossless H.264 source and a source that was compressed with CRF~16. GradFun2db() can improve things quite a lot. And probably if you take your source, apply some GradFun2db() and directly watch the result, you will be able to improve things. But, as said before, once you pump the GradFun2db()-processed video through the encoder once, the effect will be pretty much gone - the dither simply won't survive when encoding with 8-Bit precision. It might survive the encode if you really could use lossless H.264 or 10-Bit, but then the re-encode done by Youtube will kill it. After all, the only option is applying GradFun2db() when watching the final result. (Of course this isn't possible with Youtube's player. But you can download the clip from Youtube and use your own player) That sounds reasonable. Using a slower Preset would only mean that you might be able to get away with an even lower bitrate (after adjusting the CRF value accoridngly) for the same quality. If you still see some degradation with CRF 16, try an even lower CRF value until you are happy with the result. But always keep in mind that trying to retain tiny details, that Youtube is going to destroy with their re-encode anyway, is pointless. So don't be too pedantic Or in other words: If you change your x264 settings, you always have to judge the difference after that video has been re-encoded by Youtube. If it makes no difference on Youtube, you don't need to care. As long as the source doesn't show obvious artifacts already before the upload, it should be good enough...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 8th August 2012 at 15:39. |
|
8th August 2012, 15:50 | #12 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
Yeah have found that AQ 1.3 is really good, should i have that and Mb-tree on?
I am not sure if it supports Lossless (CRF 0) but i think i does, i may have tried it before. But itīs as you say, when going as low as CRF 16, itīs already "Transparent" more or less that it wonīt matter, so onlything is to prevent nasty banding, but it seems that low enough CRF will prevent that aswell |
8th August 2012, 15:56 | #14 | Link |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Messing with your settings when it's going to be re-encoded anyways is staggeringly pointless. Pick a low CRF and be done with it; if you're spending more than 15 seconds thinking about it, you're wasting your time because it literally won't do anything at all, except perhaps make you feel better.
|
11th August 2012, 17:54 | #16 | Link |
Registered User
Join Date: Mar 2005
Location: Finland
Posts: 2,641
|
He means that the same CRF doesn't give exactly the same quality across different settings, which is a common misconception among new users. Slower presets always improve the quality/bitrate ratio, however. Comparing settings when using CRF takes much more work than just a look at the file size, since quality may also change.
Last edited by nm; 11th August 2012 at 17:58. |
Thread Tools | Search this Thread |
Display Modes | |
|
|