x264: Film Grain Optimization

[bokonon]

anyone tried it on a mixed source? (i.e.scenes with varying amounts of grain)

[ToS_Maverick]

as I stated above, I got VERY good results with FGO at preventing x264 from banding! If you like i could post some screens...

[dbzgundam]

I'll have to try this with older cel-style anime... The grain present often gets turned into flat blocking.

[bokonon]

as I stated above, I got VERY good results with FGO at preventing x264 from banding! If you like i could post some screens...

please do!

include the source caps if possible :)

:thanks:

[bokonon]

Source: x264 r830 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):

x264_2pass_vbv.7.diff

x264_fix_win_stdin.diff

x264_FGO.diff (fixed by Dark Shikari & techouse)

x264.gaussian.cplxblur.01.diff

x264_hrd_pulldown.04_interlace.diff

x264_me-prepass_DeathTheSheep.diff

http://techouse.project357.com/builds/x264_x86_r830_techouse.7z

[Tack]

The patch truly does wonders for grain, but the resulting bitrate increase was a bit disappointing (even if not unexpected). VAQ+prestige still satisfies my eyes and the bitrate is quite manageable. I count myself lucky not to be among those tuned into the style of artifacting caused by prestige that others have pointed out.

When the h264 user/developer community sorts out FGM, then I'll launch fireworks from my balcony. :)

[Yoshiyuki Blade]

Looks interesting :eek:! Do you think this will work well on clear sources with artificially-added grain (via avisynth filters)? I'm curious to try that out.

[Dark Shikari]

Looks interesting :eek:! Do you think this will work well on clear sources with artificially-added grain (via avisynth filters)? I'm curious to try that out.Sure, it'll work for any sort of noise.

[desta]

Does fgo need to be enabled during the first pass of a 2-pass encode, as obviously this would require using --subme 6 and --b-rdo?

[Dark Shikari]

Does fgo need to be enabled during the first pass of a 2-pass encode, as obviously this would require using --subme 6 and --b-rdo?It doesn't need to; I'm not sure what benefit it would have.

[desta]

Ok, many thanks, and great work. :)

[cestfait]

what's keeping this patch from being added to the svn at x264.nl? is there more work to be done with this patch, dark shikari? those rate distortion thresholds, or whatever?

[Dark Shikari]

what's keeping this patch from being added to the svn at x264.nl? is there more work to be done with this patch, dark shikari? those rate distortion thresholds, or whatever?Its pretty early on in testing, probably could use some more tuning, and probably could use better asm.

[Sagittaire]

Really good work ... this patch must be quickly in the svn ... ?

There are other good idea like rdo for bframe from libavcodec.

[salehin]

Thanks a lot for another nice little addition to x264, DarkShikari. Hopefully, I'll do some test encodes and post the results here soon :)

[ToS_Maverick]

please do!

include the source caps if possible :)

:thanks:

sry for the delay, didn't have much time the last days...

here is an example for banding + blocking WITH AQ, which is resolved by FGO:

http://img379.imageshack.us/img379/2482/dnsrcsmallfr2.th.jpg (http://img379.imageshack.us/my.php?image=dnsrcsmallfr2.jpg)http://img379.imageshack.us/img379/104/dnaqsmalleq3.th.jpg (http://img379.imageshack.us/my.php?image=dnaqsmalleq3.jpg)http://img379.imageshack.us/img379/7376/dnfgosmalllw4.th.jpg (http://img379.imageshack.us/my.php?image=dnfgosmalllw4.jpg)

AVS

DGDecode_mpeg2source("Black.Pearl.Sample.d2v", idct=7, info=3).trim(2,0)
crop(0,58,0,-62).LanczosResize(768,320)
fft3dfilter().gradfun2db()


Commandline

--crf 20.0 --level 4.1 --keyint 100 --min-keyint 1 --ref 3 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -2,-2 --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 9781 --vbv-maxrate 29400 --threads auto --thread-input --progress --no-dct-decimate --output "output" "input" --fgo 10 --aq-mode 2

[Blue_MiSfit]

I've noticed a pretty significant increase in bitrate when FGO is used in CRF mode. I did an episode of planet earth, and with the latest SVN at CRF20 it came out to ~ 1.8 GB video only. The FGO build came out at 2.2 GB roughly. The differences were very apparent in grainy scenes, and (of course) not very apparent in clean scenes. A ~20% increase in bitrate is pretty significant, but worth it IMO, especially for real film content. Planet earth is a real mix of footage - some film, some HD, some upconverted SD.

I'll do some tests with 2001 A Space Odyssey BluRay. I haven't watched it yet (picked it up last weekend hearing it's probably the best looking BluRay in terms of video quality), but I assume there will be some film grain.

Also, there hasn't been a huge drop in speed. I averaged 5.7 FPS on my Q6600 with a minimal AVS script when using FGO - obviously including RDO, trellis etc... That's pretty standard, and entirely acceptable.

~MiSfit

[akupenguin]

@Blue_MiSfit
Never visually compare 2 encodes at different bitrates. Your intuition is not able to judge whether a given change in quality is worth x% bitrate. (Unless of course you're deciding what bitrate to use. But that's not the case here)

If you already knew this, then shame on you for posting meaningless reports pretending to support FGO. If you didn't, then now you know.

If you're complaining that FGO changed your bitrate, then that's valid, but you shouldn't have gone on to post a visual comparison.

@ToS_Maverick
Same to you, except even more so because you didn't even say what relative size those encodes were.
BTW, do you really think it's better? All I see in that screen is banding vs banding+noise. And more noise than the source, for that matter.

[Blue_MiSfit]

@ akupenguin

Now hold on a second... what's wrong with visually comparing encodes at different bitrates? I'm comparing encodes at the same CRF (since that's about the only mode I use these days), and trying to learn where FGO is appropriate, and roughly what the bitrate cost tends to be.

In this specific case it probably wasn't worth it.

I respect you and your opinions tremendously, but I'm a little put off by your tone!

What exactly is wrong with comparing two encodes as I have done?

Thanks,

~MiSfit

[Dark Shikari]

What exactly is wrong with comparing two encodes as I have done?Let's say I made a fake FGO that didn't actually do anything except raise bitrate by 20% at the same CRF.

It would still look better, wouldn't it?

So you always have to compare at the same bitrate.

[Blue_MiSfit]

Fair enough, but I wouldn't expect that of you! :)

Still, I think I get the point. I've gotten very used to CRF encoding, and didn't really think about it as a test.

Would comparisons between CRF encodes still be valid when (for example) looking at how denoisers perform?

Thanks
~MiSfit

[akupenguin]

Fair enough, but I wouldn't expect that of you! :)
Don't make me implement --placebo ;)

Would comparisons between CRF encodes still be valid when (for example) looking at how denoisers perform?
Maybe, but only insofar as different denoisers might result in similar enough bitrates. 2pass is still a better bet, especially since you can probably get away with reusing the first pass.

[Dark Shikari]

Don't make me implement --placebo ;)Its called --me tesa --merange 64 ;)

[Blue_MiSfit]

dark_shiraki beat me to it ;)
The best part is, if you implemented some feature that DRASTICALLY slowed encoding time or skyrocketed bitrate, I guarantee some wacko out there would swear by it (Divx exhaustive motion search / blatant SSE4 advertising anyone?)

I think you're absolutely right regarding the denoiser tests.. Thanks for the information. My perspective has adjusted accordingly!

~MiSfit

[ToS_Maverick]

Let's say I made a fake FGO that didn't actually do anything except raise bitrate by 20% at the same CRF.

It would still look better, wouldn't it?

So you always have to compare at the same bitrate.

well... i know how that sample looks at the various bitrates, and crf20 and crf19.5 is not really a great difference. but i will post the results of a 2pass test, when i've got some time, so satisfiy everyone.

@ToS_Maverick
Same to you, except even more so because you didn't even say what relative size those encodes were.
BTW, do you really think it's better? All I see in that screen is banding vs banding+noise. And more noise than the source, for that matter.

1. for me if the filesize difference is < 10 %, then i think this test is vaild enough, since i'm testing a encoding techique that's fundamental different than the one x264 currently uses.

2. about the noise: i like noise, especially if it preserves the look and if it hides ugly blocks. this point is about taste, and thank god everyone has a different one ;)

[saint-francis]

2. about the noise: i like noise, especially if it preserves the look and if it hides ugly blocks. this point is about taste, and thank god everyone has a different one ;)

If you like the noise then why are you using an aggressive denoiser like FFT3DFilter? I'm not exactly sure what you are getting at here with FGO. Are you saying that your combination of filtering and FGO keeps just the right amount and type of noise to keep the blocking and banding in the source under control? Or are you saying that the banding you are trying to eliminate is caused by x264 without FGO? From what I can gather FGO is aimed at retaining the grain inherent in the source where in the past x264 has been itself more aggressive with noise than some desire.

[ToS_Maverick]

the point of this test was, that with this sorce, if denoised with

only AQ => blocks
AQ + FGO => the dithering from gradfun2db is kept.

in another thread someone did a test with a heavily denoised clip of "V for Vendetta", which needed < 1 mbit, but had severe banding. with gradfun2db you can "dither away" the banding, but if you encode the dithered clip, x264 blocks and bands again, without FGO.

[kolak]

Film Grain Modelling is a great idea but nearly nobody has implemented it (not even JM), so there's very little to go off of. We'd basically be starting from nothing, and we'd need to implement it in libavcodec too.

That's partially because I cheated; FGO lowers B-frame quantizers somewhat to ensure they stay grainy :p

Thomson encoder (NexCode) has it- doesn't it?

Andrew

[bokonon]

i think this has got to be made default in the main builds just like AQ was - it's improved every source I've thrown at it so far!

[ACrowley]

I made a reencode from Underworld ExtendedCut HDDVD with --fgo 10 ,Deadzones 6,6 ,CQM none (flat),10Mbps VBR, AQ default (1,0)

Very nice Result with this very grainy Source.
Quants are around 1-1,5 higher compared to no fgo bit it looks better imho

I will make a reencode from 300 Bluray cause my old encode was with Prestige CQM ( i dont use Prestige CQM anymore since Month). I think FGO will work very very good on such Sources like 300 or BlackhawkDown etc

Actually im running Elecard ConverterStudio ProHD with FilmGrainOptimizer at 80. I will compare the encode with x264 FGO

Nice work DarkShikari :)

[Inventive Software]

Its called --me tesa --merange 64 ;)

I don't get that one, explain it to me. :)

[J_Darnley]

It is very slow and provides negligible benefit over something much quicker. If someone believes it does then it is the placebo effect.

[desta]

I'm pretty sure Inventive was joking.

[Inventive Software]

I'm pretty sure Inventive was joking.

I wasn't, but at least I'm aware. ;)

[cestfait]

ok, I'll apologize in advance, but I'm gonna be "that guy" now:

so, how's progress? :p

I've done some more testing of this patch, and I like it more the more I use it. I'm pretty uninformed when it comes to the innards of x264, but I'm really keen to see how well this patch will work when it's "finished." What I mean to say is that my encoding has effectively come to a standstill because I'm waiting to hear news that there's not much more progress to be made with this patch.

Pretty shallow. :)

I guess the only good way that I can spin this is: look how much I love you're work, Dark Shikari. I'm not being a nuisance, I'm just excited!

[techouse]

I encoded 300 (BluRay source) using --fgo 10 and got these results:

SOURCE (~17000 kbps) vs my encode with FGO and prestige (9222 kbps) vs another encode without FGO and with prestige (~13000 kbps)

http://shrani.si/t/21/A9/497T9X6B/source1.jpg (http://shrani.si/?21/A9/497T9X6B/source1.png) vs http://shrani.si/t/3J/2b/4MVip4kI/ctrlhd1.jpg (http://shrani.si/?3J/2b/4MVip4kI/ctrlhd1.png) vs http://shrani.si/t/L/tN/2Xd1vebn/hdv1.jpg (http://shrani.si/?L/tN/2Xd1vebn/hdv1.png)
http://shrani.si/t/3N/x7/3rFTVXNo/source2.jpg (http://shrani.si/?3N/x7/3rFTVXNo/source2.png) vs http://shrani.si/t/m/mK/1C0yB5pz/ctrlhd2.jpg (http://shrani.si/?m/mK/1C0yB5pz/ctrlhd2.png) vs http://shrani.si/t/L/Ss/390zNDOs/hdv2.jpg (http://shrani.si/?L/Ss/390zNDOs/hdv2.png)
http://shrani.si/t/3Q/lv/YCkm54F/source3.jpg (http://shrani.si/?3Q/lv/YCkm54F/source3.png) vs http://shrani.si/t/30/3C/4do4xkDO/ctrlhd3.jpg (http://shrani.si/?30/3C/4do4xkDO/ctrlhd3.png) vs http://shrani.si/t/3s/r3/4GNQIKqS/hdv3.jpg (http://shrani.si/?3s/r3/4GNQIKqS/hdv3.png)
http://shrani.si/t/3L/8S/38WRhymI/source4.jpg (http://shrani.si/?3L/8S/38WRhymI/source4.png) vs http://shrani.si/t/y/cY/4TEnQ13L/ctrlhd4.jpg (http://shrani.si/?y/cY/4TEnQ13L/ctrlhd4.png) vs http://shrani.si/t/2p/Ar/2HDcTgTL/hdv4.jpg (http://shrani.si/?2p/Ar/2HDcTgTL/hdv4.png)
http://shrani.si/t/3/QC/2XOXuent/source10.jpg (http://shrani.si/?3/QC/2XOXuent/source10.png) vs http://shrani.si/t/13/e3/1PPX3lez/ctrlhd10.jpg (http://shrani.si/?13/e3/1PPX3lez/ctrlhd10.png) vs http://shrani.si/t/A/Va/eOqcUgX/hdv10.jpg (http://shrani.si/?A/Va/eOqcUgX/hdv10.png)

[DarkZell666]

@techouse : There is some obvious loss of detail in Column 2, compared to Column 3 (which is closer to the source). But then again, the bitrate is 40% higher in column 3, which means the comparison is bogus. ... unless you actually posted them the wrong way round, meaning that Column 3 would actually be your encode with FGO (in that case it would point out how much FGO kicks ass, but right now the screenshots are meaningless).

Edit : But such fine loss of detail is definately worth 40% bitrate savings if that's what you were trying to show, but is it thanks to FGO alone ? Or would the mere fact of using 40% less bitrate yield a similar result without FGO ? That is the question :)

[Sharktooth]

could you please avoid:
1- Prestige
2- CRF

just use the standard quantization and 2pass RC to ensure the average bitrate of all the clips is the same.

[Sagittaire]

Test in progress here with BD9 profil and encoding at 6.9 Mbps. I use x264, x264 with fgo, Mainconcept, VC1 from PSE, VC1 from SDK, MPEG2 from libavocodec. Movie is Casino Royal (extra high quality source) with really complexe pre-process for best quality and best preserving grain. Unfortunaly VC1 is really really really slow even with my c2d at 2.6 Ghz (less than 1 fps at quality max).

[Japhsoncross]

fullhd encoding is extremely slow, i got 0.8fps on my dual core system, and i upgrade to quad core here to get 2fps, keeping a crf movie encode less than a whole day.
fgo makes me consider to re-encode some of my movies again :)

[nm]

fullhd encoding is extremely slow, i got 0.8fps on my dual core system, and i upgrade to quad core here to get 2fps, keeping a crf movie encode less than a whole day.
Sounds like you are using somewhat overkill x264 settings. I get ~1 fps for 1080p24 on a 1.8 GHz Athlon64 with moderate parameters, which is a good balance for me. Of course, people are free to max the settings out for few percent gain in bitrate, but at some point disk space is usually cheaper than the electric bill.

[CruNcher]

fullhd encoding is extremely slow, i got 0.8fps on my dual core system, and i upgrade to quad core here to get 2fps, keeping a crf movie encode less than a whole day.
fgo makes me consider to re-encode some of my movies again


As nm said you have to balance it right you can reach different results @ different speeds, there are alot factors that play a role here like the compression factor you wan't to gain compared to the original and also the detail depth you wan't to preserve and another factor (tough it plays not that big role for many nowdays) which cpu(gpu) utilization is your target (decoding speed) :) you can balance more resources or less in all these directions if you wan't, that's up to you.

[lexor]

How come no FGO only test techouse?

As for the results I'm somewhat torn in comparing them, on one hand when viewed 1:1 the third column is much closer to source than second column. However if I let that image site scale the images to fit screen width, second column wins by a large margin...

1:1 superiority matters little if I never see it, since the resize ruins it and I don't have screen to see 1080p 1:1. What would've been nice is to see if FGO alone can do good enough job on 300 to satisfy both needs. (I don't have such noisy blu-rays to test unfortunately)

[ACrowley]

fullhd encoding is extremely slow, i got 0.8fps on my dual core system, and i upgrade to quad core here to get 2fps, keeping a crf movie encode less than a whole day.
fgo makes me consider to re-encode some of my movies again :)

No ,1080p x264 encoding isnt to slow on a fast CPU.

With my Intel q6600 @3.2Ghz i get 22-32Fps in 1st pass and 4-6fps 2nd Pass for x264 1080p ~10Mbps ,2.35:1 . No extra Filtering ,only crop/Resize

My old DualCore A64 X2 4200 delivers only 1,8Fps 2nd pass and ~10fps 1st pass or 1080p 2.35:1

Profile is similar to sharktooth DXVA HQ HD Profile with some extra HQ Settings .

Example : I took me ~8.5h to encode Bourne Ultimatum HDDVD to 9Mbps 1080p x264.
On my old X2 it takes me minimum 24h

I suggest to by a Quadcore. Its a big Perfomance Jump

[techouse]

Edit : But such fine loss of detail is definately worth 40% bitrate savings if that's what you were trying to show, but is it thanks to FGO alone ? Or would the mere fact of using 40% less bitrate yield a similar result without FGO ? That is the question :)

I was just trying to show that my encode with FGO and Prestige @9222 kbps looks almost the same as another encode (not mine) without it @ ~13000 kbps (both encodes are made with recent versions of x264). This way my encode of 300 could even fit on one DVD9 if muxed with AC3.

I also tried without prestige (=flat matrix) and the results were catastrophic. It seems that prestige somehow "doubles" the effect of FGO. Ask Dark Shikari why. ;)

And, yes it was a 2pass encode :D

P.S.: Thank prestige for the fine detail loss.

[R3Z]

I was just trying to show that my encode with FGO and Prestige @9222 kbps looks almost the same as another encode (not mine) without it @ ~13000 kbps (both encodes are made with recent versions of x264). This way my encode of 300 could even fit on one DVD9 if muxed with AC3.

I also tried without prestige (=flat matrix) and the results were catastrophic. It seems that prestige somehow "doubles" the effect of FGO. Ask Dark Shikari why. ;)

And, yes it was a 2pass encode :D

P.S.: Thank prestige for the fine detail loss.

Prestige certainly keeps alot of grain, certain peeps dont recomend using it but i havent seen any issues with my encodes and no one has posted any examples of issues to look for.

[Sharktooth]

we're testing FGO here.. not the matrices. please use the STANDARD QUANTIZATION for testing.

[desta]

From what I've noticed, it does appear that it's better to keep fgo for both passes of a 2 pass encode, and also to keep the ME settings (merange, subme, etc) as close together as possible. It seemed that not doing so produced some chroma problems. This seemed to happen when doing crf encodes too.

Unfortunately I can't show results or replicate them at the moment, but as soon as I can I'll try to show what I mean. The results I got were from relatively short clips though (1000 - 4000 frames).

[BlackSharkfr]

i'd like to test this on a 100% CG non grainy source (videogame : since it's the kind of source i work with) and see if it causes some garbage or if there is few/no visible impact.

can you give me x264 command lines ? (i've never worked with the cli)
thanks
my source is 1280x720 30p lagarith RGB in .avi

[ACrowley]

I was just trying to show that my encode with FGO and Prestige @9222 kbps looks almost the same as another encode (not mine) without it @ ~13000 kbps (both encodes are made with recent versions of x264). This way my encode of 300 could even fit on one DVD9 if muxed with AC3.

I also tried without prestige (=flat matrix) and the results were catastrophic. It seems that prestige somehow "doubles" the effect of FGO. Ask Dark Shikari why. ;)

And, yes it was a 2pass encode :D

P.S.: Thank prestige for the fine detail loss.

I go the best Results with FGO+Flat(none)+Deadzones~ 4,6.

However, i never used Prestige again in my encodes since 6 Month, im satisfied with Flat(none) + low Deadzones+high Bitrate for Grainy Sourcs