x264: Film Grain Optimization

[BlackSharkfr]

I've done my tests with the 100% non-grainy source.
I wanted to see wha happened with fgo, in case you'd like to encode a video with mixed grain strength (some shots grainy and others not grainy)

Megui preset : DXVA HQ HD
I used --fgo 10 on all encodes with fgo.

source 1280x720p (lagarith) : ( yes i know, the motion blur effect is a bit strong)
http://blacksharkfr.free.fr/media/images/FGOtest/mini/source70.jpg (http://blacksharkfr.free.fr/media/images/FGOtest/source70.png)http://blacksharkfr.free.fr/media/images/FGOtest/mini/source270.jpg (http://blacksharkfr.free.fr/media/images/FGOtest/source270.png)http://blacksharkfr.free.fr/media/images/FGOtest/mini/source760.jpg (http://blacksharkfr.free.fr/media/images/FGOtest/source760.png)http://blacksharkfr.free.fr/media/images/FGOtest/mini/source1090.jpg (http://blacksharkfr.free.fr/media/images/FGOtest/source1090.png)http://blacksharkfr.free.fr/media/images/FGOtest/mini/source1164.jpg (http://blacksharkfr.free.fr/media/images/FGOtest/source1164.png)http://blacksharkfr.free.fr/media/images/FGOtest/mini/source1840.jpg (http://blacksharkfr.free.fr/media/images/FGOtest/source1840.png)http://blacksharkfr.free.fr/media/images/FGOtest/mini/source2272.jpg (http://blacksharkfr.free.fr/media/images/FGOtest/source2272.png)http://blacksharkfr.free.fr/media/images/FGOtest/mini/source2550.jpg (http://blacksharkfr.free.fr/media/images/FGOtest/source2550.png)http://blacksharkfr.free.fr/media/images/FGOtest/mini/source2625.jpg (http://blacksharkfr.free.fr/media/images/FGOtest/source2625.png)

very high bitrate (8000 kbps) : not done

high bitrate (5000 kbps) top fgo, bottom nofgo
1 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo5k70.png)2 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo5k270.png)3 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo5k760.png)4 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo5k1090.png)5 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo5k1164.png)6 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo5k1840.png)7 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo5k2272.png)8 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo5k2550.png)9 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo5k2625.png)
1 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo5k70.png)2 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo5k270.png)3 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo5k760.png)4 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo5k1090.png)5 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo5k1164.png)6 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo5k1840.png)7 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo5k2272.png)8 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo5k2550.png)9 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo5k2625.png)

medium bitrate (3000 kbps) top fgo, bottom nofgo
1 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo3k70.png)2 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo3k270.png)3 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo3k760.png)4 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo3k1090.png)5 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo3k1164.png)6 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo3k1840.png)7 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo3k2272.png)8 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo3k2550.png)9 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo3k2625.png)
1 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo3k70.png)2 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo3k270.png)3 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo3k760.png)4 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo3k1090.png)5 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo3k1164.png)6 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo3k1840.png)7 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo3k2272.png)8 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo3k2550.png)9 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo3k2625.png)

low bitrate (1500 kbps) top fgo, bottom nofgo
1 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo1k70.png)2 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo1k270.png)3 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo1k760.png)4 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo1k1090.png)5 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo1k1164.png)6 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo1k1840.png)7 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo1k2272.png)8 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo1k2550.png)9 (http://blacksharkfr.free.fr/media/images/FGOtest/fgo1k2625.png)
1 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo1k70.png)2 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo1k270.png)3 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo1k760.png)4 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo1k1090.png)5 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo1k1164.png)6 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo1k1840.png)7 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo1k2272.png)8 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo1k2550.png)9 (http://blacksharkfr.free.fr/media/images/FGOtest/nofgo1k2625.png)

Image quality are very similar but i think the fgo ones look a bit sharper than the non-fgo ones.
I think i'd activate fgo on any source by default.

Ok i replaced jpgs with pngs, lucky me i didnt delete the bitmap shots

[Atak_Snajpera]

Next time use png instead of jpg.

[PlazzTT]

Next time use png instead of jpg.

+1

We can't tell if the artifacts are from x264 or jpeg

[Atak_Snajpera]

I see compression artifacts in source images :)

[BlackSharkfr]

switching to png,
will edit when done

i've got some problems.
i'm trying to batch convert my bmp files with XNview but for some reason my resulting png files are completely white when viewed in firefox.
how do you generate your pngs ?

edit : FOUND!
it was the transparency channel that was defaulted to fully transparent.
uploading pngs now

[BlackSharkfr]

done, replaced all images with pngs

[Sharktooth]

ok, from what i see, the FGO encodes have more details on super-fine details but tend to blur the already blurry textures. one example is the grass on shot 7. it looks better on the non-fgo encode but the rear-right wheel, the water reflections on the left and the right are of the picture look better in the FGO encode.
from what i see, i'd say FGO wont be good for toons/anime and blurry sources, while it should be good if the source has very fine details and you want to preserve them.

[Atak_Snajpera]

from what i see, i'd say FGO wont be good for toons/anime and blurry sources, while it should be good if the source has very fine details and you want to preserve them.
It reminds me somebody saying that VAQ would not be good for cartoon/Anime either :) If FGO works very well on grainy source and on normal clean sources difference is very small I would vote for default set FGO 10 all the time.

[Sharktooth]

look at the picture in the example i've made.
the grass area is very large on that picture and at high bitrates it gets sacrificed for few details while at low bitrates the FGO effect seems to give the picture a better overall look.
so, if it is going to stay as it is, FGO cant be set as the default.

[ToS_Maverick]

It reminds me somebody saying that VAQ would not be good for cartoon/Anime either :) If FGO works very well on grainy source and on normal clean sources difference is very small I would vote for default set FGO 10 all the time.

my vote for this too.

FGO has a huge benefit on most of the material out there. the people who encode anime use special settings anyway...

[lexor]

look at the picture in the example i've made.
the grass area is very large on that picture and at high bitrates it gets sacrificed for few details while at low bitrates the FGO effect seems to give the picture a better overall look.

I don't see that happening, both on the skidding-on-grass car and flying-over-grass car pictures. I see that both FGO and noFGO are about equal on the car, but noFGO blurs the whole background extensively while FGO still blurs it, but a lot less and appears to be closer to the source.

[survivant001]

one question. is it more efficiant to use a avs noise optimizer or use the build-in FGO ?

I'm not good in avs scripting with all the filters out there, but I saw a post from Dark Shikari about grain Optimizer avc script.

[cestfait]

I use similar settings on anime to those I would use on movies. The kept grain only fights blocking, which the eye is much keener on than small shifting bits of noise. Also, the anime that I like have very detailed backgrounds, which need to be given their fair share of bits. Anime encoders that don't try to retain grain smooth their movies, while my denoising is only temporal degraining and minor deringing.

In essence, the difference between anime and movie sources as far as my encoding goes is that the anime compresses better, on the whole. The compression process itself is pretty much the same between sources.

[Yoshiyuki Blade]

Also, the anime that I like have very detailed backgrounds, which need to be given their fair share of bits. Anime encoders that don't try to retain grain smooth their movies, while my denoising is only temporal degraining and minor deringing.

Same here. I only go as far as temporal smoothing on anime sources to keep still scenes steady. Spatial smoothing looks horrible, and it just kills details from what I've seen. The only drawback for using strong temporal smoothing is that it completely smears low-lit panning/zooming scenes, so I tend to use it lightly.

I'll check out how FGO turns out on high bitrate anime encodes with/without grain.

[Dark Shikari]

one question. is it more efficiant to use a avs noise optimizer or use the build-in FGO ?

I'm not good in avs scripting with all the filters out there, but I saw a post from Dark Shikari about grain Optimizer avc script.FGO serves a different purpose. The old GrainOptimizer is pretty crappy anyways; I purposely never released the source code because its honestly a piece of crap :p

[cestfait]

did you ever try motion compensated temporal denoising?

[Dark Shikari]

did you ever try motion compensated temporal denoising?That isn't the job of x264; use MVDegrain, MC_spuds, or TemporalDegrain for that.

[survivant001]

FGO serves a different purpose. The old GrainOptimizer is pretty crappy anyways; I purposely never released the source code because its honestly a piece of crap :p

that's a answer that I like.. simple and go to the fact :)

[gav1577]

@ Dark Shikari nice work indeed. i ran a few tests of my own and i have to say
from what i have seen fgo really does help to to keep that grainy look and help prevent the effects of banding which for me is one of the most annoying effects ever. i have tried fgo with a few cqms inc flat matrix IMHO fgo and the prestige cqm seem to work very well together. also some clips i encoded had very light grain it seemed to work well on those too not just the heavy grain sources btw i have not tested Anime so have no idea how fgo would fair thanks for the good work much appreciated :)

[cestfait]

that's what I meant. :)

I was asking "yoshiyuki blade" if he had tried those avisynth methods.

[Ranguvar]

Slightly off topic, but how about an option in x264 to add grain? Yeah, I know you can just add grain in AviSynth and then use FGO and VAQ in x264, but it seems to me that it would be even more efficient if the grain was arranged in a pattern, not obvious to the eye, but x264 knows this pattern, and can therefore encode it with minimal efficiency loss.

Sorry if it's a stupid idea :p

[ToS_Maverick]

another idea in this direction:
what about dithering during quantization?

didn't you mention something like this some time ago? quantizer noise shaping or something like that :D

[Dark Shikari]

Slightly off topic, but how about an option in x264 to add grain? Yeah, I know you can just add grain in AviSynth and then use FGO and VAQ in x264, but it seems to me that it would be even more efficient if the grain was arranged in a pattern, not obvious to the eye, but x264 knows this pattern, and can therefore encode it with minimal efficiency loss.

Sorry if it's a stupid idea :pI had this idea a while back and it isn't a particularly bad one, but if you're going to add artificial grain, it would make more sense to me to just go all-out and write FGM support.
another idea in this direction:
what about dithering during quantization?

didn't you mention something like this some time ago? quantizer noise shaping or something like that :DQNS doesn't really help grain preservation, and while it can be useful... it is slow.

[Yoshiyuki Blade]

that's what I meant. :)

I was asking "yoshiyuki blade" if he had tried those avisynth methods.

I haven't yet actually. There are so many filters, I have no clue which does what ;). If it does what I think it does, it would help me a lot in that particular issue.

By the way, does FGO affect general noise as well? Noise that's more subtle than clearly visible film grain, and moves in a seemingly random fashion. Whether mpeg compression "noise," or noise from a crappy VHS-to-DVD conversion, does FGO affect those random motions as well as film grain?

[ToS_Maverick]

I haven't yet actually. There are so many filters, I have no clue which does what ;). If it does what I think it does, it would help me a lot in that particular issue.

By the way, does FGO affect general noise as well? Noise that's more subtle than clearly visible film grain, and moves in a seemingly random fashion. Whether mpeg compression "noise," or noise from a crappy VHS-to-DVD conversion, does FGO affect those random motions as well as film grain?

it even keeps the dithering of gradfun2db...

[Sagittaire]

hmmm ... this fgo option work really well for grain retention. The result is really on the top now. If tou want the best possible setting try with this command line:

--trellis 0 --deadzone-intra 10 --deadzone-inter 10 --fgo 10

With really noisy source trelli produce really better average quantizer but with less noise retention. Not possible to have trelli with good grain retention?

[smekoslav]

So basicly FGO 10+prestige should produce better results also on little/medium grainy sources, not just heavily grained ones like 300 was, right?

[Sharktooth]

no. prestige is bad for non noisy stuff.

[bokonon]

Test to demonstrate behavior with trellis 1 + 2 and low deadzones
2 pass encoding with turbo enabled on the first pass
bitrate: 4260kbps
Source was 1080i MPEG-2 resized + IVTCed with avisynth

typical command line: --pass 2 --bitrate 4260 --stats ".stats" --level 4.1 --deadzone-inter 6 --deadzone-intra 4 --ref 6 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -3,-3 --subme 7 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input" --fgo 10

source
http://xs127.xs.to/xs127/08212/source298.png.xs.jpg (http://xs.to/xs.php?h=xs127&d=08212&f=source298.png)

Trellis 1
http://xs127.xs.to/xs127/08212/trellis_1635.png.xs.jpg (http://xs.to/xs.php?h=xs127&d=08212&f=trellis_1635.png)

Trellis 2
http://xs127.xs.to/xs127/08212/trellis_2131.png.xs.jpg (http://xs.to/xs.php?h=xs127&d=08212&f=trellis_2131.png)

Deadzones 6,4
http://xs127.xs.to/xs127/08212/dead_6_4356.png.xs.jpg (http://xs.to/xs.php?h=xs127&d=08212&f=dead_6_4356.png)

Also tried Deadzones 10,10 because someone in this thread said this produced their best results with FGO

Deadzones 10,10
http://xs127.xs.to/xs127/08212/dead_10_10536.png.xs.jpg (http://xs.to/xs.php?h=xs127&d=08212&f=dead_10_10536.png)

[R3Z]

Arent Deadzones ignored when trellis is enabled ?

[ACrowley]

Arent Deadzones ignored when trellis is enabled ?

yes, ignored when Trellis is active

[guada2]

Hello,

It seems that the couple FGO + Grain Retention gives good results at high bitrate.
What happens at low bitrate?

[Sagittaire]

Hello,

It seems that the couple FGO + Grain Retention gives good results at high bitrate.
What happens at low bitrate?

1) All the encoder produce good result for grain retention at high bitrate (aka low quantizer).

2) FGO is grain retention optimisation. FGO produce really good result at "low bitrate" (q24) and for really fine grain at "medium bitrate" (q20).

[Dark Shikari]

yes, ignored when Trellis is activeNot entirely; on trellis 1 deadzones are still used for macroblock type decision, so using bizarre deadzones in combination with trellis will probably be of slight negative effect.

[Blue_MiSfit]

god what a brutal choice of a comparison image :(

Interesting though, I will have to mess around with deadzones for my grainy stuff..

~MiSfit

[UsedUser]

Were there changes to FGO b/w builds 851 and 859?

They both appear to have "x264_fgo.2.diff (made compilable for 826)". In fact, they both appear to have the same abbr. change log:

http://forum.doom9.org/showthread.php?p=1138634#post1138634
http://forum.doom9.org/showthread.php?p=1140024#post1140024

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_fgo.2.diff (made compilable for 826)
http://forum.doom9.org/showthread.php?t=137117
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.8.diff
http://thread.gmane.org/gmane.comp.v...093/focus=3972
x264_hrd_pulldown.04_interlace.diff
HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.ph...19#post1047919
x264_fix_win_stdin.diff
http://mailman.videolan.org/pipermai...ch/004325.html

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[bob0r]

@UsedUser

The difference are the x264 changes.

[UsedUser]

@UsedUser

The difference are the x264 changes.
Still not getting it. Feeling a bit obtuse. :confused:

Perhaps someone can confirm my assumptions:

The diffs listed in the post are the new patches applied to the build? So if the patches listed are the same, builds 851 and 859 are the same?

If x264_fgo.2.diff was applied to both builds, then nothing re: FGO has changed in the builds?

[LoRd_MuldeR]

Still not getting it. Feeling a bit obtuse. :confused:

The "diffs" listed in bobor's posts are the patches that were applied to his build. Those patches are not included in the official x264 SVN yet!
Every time a new SVN revision is out, a new build will be created and the same patches/diffs will applied again, unless they are accepted officially or become obsolete.
So those patches/diffs indicate the difference between bobor's build and the "official" x264 codebase...

If x264_fgo.2.diff was applied to both builds, then nothing re: FGO has changed in the builds?

The "FGO" patch itself has not changed, but other changes were made to x264 in the meantime.
So the new build was made from the current x264 SVN in order to include the latest changes/improvements and the (experimental) patches were applied again.
Usually patches are accepted for "officical" SVN as soon as they are fully tested and optimized. Some patches will be rejected though...


// EDIT

Oooops, official x264 codebase is maintained via GIT now, not SVN ;)

[bob0r]

When dark_shikari updates FGO, it will be x264_fgo.3.diff :)

So yes, same FGO (same patches) only x264 GIT code updates for those versions.

But in the latest patched .exe, vbv9 was updated and a new patch by DeathTheSheep was added.

But for FGO, all remains the same, as long as the file is named:
x264_fgo.2.diff

[guada2]

Many thanks Sagittaire :)

Bye.

[UsedUser]

The "diffs" listed in bobor's posts are the patches that were applied to his build. Those patches are not included in the official x264 SVN yet!

When dark_shikari updates FGO, it will be x264_fgo.3.diff :)

So yes, same FGO (same patches) only x264 GIT code updates for those versions.
Got it. Thanks, guys.

Now I just need to figure out what patches were applied to the build 851 downloaded with MeGUI, to figure out which version of FGO I used: x264_fgo.1.diff or x264_fgo.2.diff.

[bob0r]

Got it. Thanks, guys.

Now I just need to figure out what patches were applied to the build 851 downloaded with MeGUI, to figure out which version of FGO I used: x264_fgo.1.diff or x264_fgo.2.diff.

Thats very simple:
http://forum.doom9.org/showthread.php?p=1138634#post1138634

[J_Darnley]

They both produce the same results. I don't recall Dark Shikari saying he has changed what it does. The update for r826 was to make it work or apply-able again after the changes made to x264.

[Dark Shikari]

They both produce the same results. I don't recall Dark Shikari saying he has changed what it does. The update for r826 was to make it work or apply-able again after the changes made to x264.Yes, it was just an update to make it so that people didn't have to futz with the code to get it to apply properly.

[UsedUser]

Well, good! Then I don't have to re-encode anything.

[Inventive Software]

I have a blind test at hand to see whether it's worth using FGO at CRF 18. The file grew in size by about 30% compared to the non-FGO file, so I hope it's worth it.

Most 70s TV shows had interlaced cameras for indoor scenes, but film cameras for outside scenes, which is why the movement outside seemed jerkier. I've taken the same frame from an inside scene from: the source AVS (DGAVCDec's MPEG2Source), the FGO encoded file, and the non-FGO encoded file. All you have to do is attempt to figure out which one is which. I expect Dark Shikari to get full marks since it's his patch. ;)

Command-line:
x264 --crf 18 --bframes 8 --ref 8 --subme 7 --me tesa --interlaced --partitions all --no-fast-pskip --b-rdo
--mixed-refs --weightb --b-pyramid --bime --me-prepass --threads 3 --progress
I added --fgo 10 for the FGO encoded file.


PNGs, thumbnails, click for full view

http://img133.imageshack.us/img133/3379/73208490ny6.th.png (http://img133.imageshack.us/my.php?image=73208490ny6.png) | http://img142.imageshack.us/img142/8445/45527705el4.th.png (http://img142.imageshack.us/my.php?image=45527705el4.png) | http://img142.imageshack.us/img142/8169/40926248ch7.th.png (http://img142.imageshack.us/my.php?image=40926248ch7.png)

http://img133.imageshack.us/img133/7060/95267329dq8.th.png (http://img133.imageshack.us/my.php?image=95267329dq8.png) | http://img341.imageshack.us/img341/6836/16497155rh0.th.png (http://img341.imageshack.us/my.php?image=16497155rh0.png) | http://img133.imageshack.us/img133/6800/24781684nh4.th.png (http://img133.imageshack.us/my.php?image=24781684nh4.png)

[Dark Shikari]

I have a blind test at hand to see whether it's worth using FGO at CRF 18. The file grew in size by about 30% compared to the non-FGO file, so I hope it's worth it.Comparisons are worthless unless they're at the same bitrate ;)

[Inventive Software]

Oh NOW you tell me. :p

[saint-francis]

Comparisons are worthless unless they're at the same bitrate ;)

This is not entirely true. The name of the game here is reducing file size so using crf in comparisons to judge how certain settings effect the need for bitrate has its place. So maybe crf's place isn't in this application. Note that I say maybe since it was clearly marked that the crf version took 30% more space and this is a clear concern. At a certain point we would be all but throwing away processing power by encoding if we only gained (for example) a 5% reduction in size .