Tweaking x264 for Dark Games.

[zerowalker]

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*

[LoRd_MuldeR]

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.php?p=1384029#post1384029

[zerowalker]

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?

[Dark Shikari]

If it's just being re-encoded, you're best off just encoding at a relatively high bitrate. There's not much else you can do except give it good input.

[LoRd_MuldeR]

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

[zerowalker]

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?

[LoRd_MuldeR]

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

[zerowalker]

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.

[Brazil2]

like MB-Tree off or something?
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.php?p=1476033#post1476033

[7ekno]

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

[LoRd_MuldeR]

So now i want to encode it as "lossless" as possibly, so that Youtube won´t Crush it more than necceserry.

Does youtube support lossless H.264, as created by x264, as input?

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.

oh, so GradFun2db() is wasted? if so i will just skip it.

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)

I currently use Medium Preset, Tune Film, and CRF 16.

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

[zerowalker]

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:)

[vivan]

Does youtube support lossless H.264, as created by x264, as input?No, it doesn't.

[Dark Shikari]

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.

[zerowalker]

[nm]

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.