x264: Film Grain Optimization

[Dark Shikari]

example:
with (http://mirror05.x264.nl/Dark/FGO.png), without (http://mirror05.x264.nl/Dark/noFGO.png)

fprofiled win32 build (http://files.x264.nl/x264.826.fgo.1.exe)
patch (http://pastebin.com/m2e601b27) (updated to work on latest revision and on 64-bit)
explanation (how it works, etc) (http://x264dev.blogspot.com/2008/05/film-grain-optimization.html)

usage:

--fgo, see --help for more info. Requires RDO, i.e. --subme 6 or higher and --b-rdo. Obviously doesn't work well on non-grainy sources.

[Sagittaire]

You use nssd?
Come from libavcodec?

[Dark Shikari]

You use nssd?
Come from libavcodec?Yes, I ported NSSD from libavcodec and drastically simplified the assembly. Other changes include some modifications to RD thresholds.

[IgorC]

Is it good idea if I try to encode with fgo enabled and trellis 2 + deblock -1:-1?

[Dark Shikari]

Is it good idea if I try to encode with fgo enabled and trellis 2 + deblock -1:-1?It should work fine with trellis 2. I haven't experimented much, so feel free to do whatever you want and see how well it works.

[Adub]

So, would this be used instead of your Grain Optimizer? Or in conjunction with?

[Dark Shikari]

So, would this be used instead of your Grain Optimizer? Or in conjunction with?Unrelated, though I really don't think grainoptimizer is that effective nor that reliable.

[ToS_Maverick]

now that you created another mysteriously patch, would you please explain how it is supposed to work? i'm very interested, and can only trust a patch if i know what it does :D

[Blue_MiSfit]

<3!!!!

I've been waiting for this one for a long time!!

I was under the impression that FGM had to be supported decoder side as well?

~misfit

[Dark Shikari]

now that you created another mysteriously patch, would you please explain how it is supposed to work? i'm very interested, and can only trust a patch if i know what it does :DRDO normally uses sum of squared differences as its metric. That is, it rewards modes which approximate the source the most accurately according to that metric, and which don't cost too many bits.

FGO uses NSSD instead. NSSD consists of two components:

1) SSD as before.

2) abs( Noise(Reference Block) - Noise(Coded Block) ) * Weight, where "weight" is the --fgo parameter (this parameter also controls a few other things in FGO).

The resulting score is SSD + ND (Noise Difference).

Noise is measured as follows:

If X(i,j) is a pixel in a block, the noise score for that pixel is abs(X(i,j) - X(i+1,j) - X(i,j+1) + X(i+1,j+1)). This is summed up over all pixels in the block.

In other words, NSSD rewards modes which have a similar amount of noise and approximate the source reasonably well. This noise need not be exactly like the source's noise; it merely needs to be good enough.

I was under the impression that FGM had to be supported decoder side as well?This isn't FGM, its FGO.

[Blue_MiSfit]

ooooo...

right :D

I guess I mis-read it.

I like the results, at any rate!

[mahsah]

The pictures and Binary are down... anyone got a mirror?

Also should this be used with AQ or not...?

and for that matter, how exactly does it work (in layman's terms perhaps? :D)

[Dark Shikari]

The pictures and Binary are down... anyone got a mirror?

Also should this be used with AQ or not...?

and for that matter, how exactly does it work (in layman's terms perhaps? :D)It should be used with AQ, the server isn't down (works fine here), and a somewhat simple explanation was posted above.

In incredibly simple terms: it measures only that the amount of noise in a candidate block is the same as it should be, not that its the same noise as in the source.

[K0zi]

What CQM's would you recommend to use with FGO?
How about prestige? :D

[Dark Shikari]

What CQM's would you recommend to use with FGO?
How about prestige? :DI have no idea; I haven't tried any.

I've never really had good experiences with Prestige.

[ToS_Maverick]

OMG Dark Shikari, you just wrote the XviD-KILLER!!!

everything that was better with xvid is GONE! with FGO i simply got the best encode of the BlackPearl-Sample. looks like 60 mb, at only 32 mb!!!

and forget about matrices, who needs matrices now?

if you don't believe it, here are some screens :D
Left AQ (29,4 MB), Right AQ + FGO (32,1 MB)

http://img291.imageshack.us/img291/8816/74aqsmallcu1.th.jpg (http://img291.imageshack.us/my.php?image=74aqsmallcu1.jpg)http://img232.imageshack.us/img232/7581/74fgosmallqw6.th.jpg (http://img232.imageshack.us/my.php?image=74fgosmallqw6.jpg)

http://img232.imageshack.us/img232/9311/182aqsmallws6.th.jpg (http://img232.imageshack.us/my.php?image=182aqsmallws6.jpg)http://img120.imageshack.us/img120/2057/182fgosmallzz9.th.jpg (http://img120.imageshack.us/my.php?image=182fgosmallzz9.jpg)

and the most amazing image-pair:
http://img241.imageshack.us/img241/2042/590aqsmallwk8.th.jpg (http://img241.imageshack.us/my.php?image=590aqsmallwk8.jpg)http://img241.imageshack.us/img241/3584/590fgosmallns1.th.jpg (http://img241.imageshack.us/my.php?image=590fgosmallns1.jpg)

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

[Sagittaire]

--fgo, see --help for more info. Requires RDO, i.e. --subme 6 or higher and --b-rdo. Obviously doesn't work well on non-grainy sources.

The resulting score is SSD + ND (Noise Difference).



Perhaps SSD problem here (with non-grainy source certainely that ND ~ 0). Why not choose other metric like SAD/SATD if ND ~ 0 or if ND < Threshold. Why not SAD + ND or SATD + ND too.

[Dark Shikari]

Perhaps SSD problem here (with non-grainy source certainely that ND ~ 0). Why not choose other metric like SAD/SATD if ND ~ 0 or if ND < Threshold. Why not SAD + ND or SATD + ND too.SAD/SATD are really measures of bit cost, not distortion.

[Inventive Software]

Wow, Dark Shikari with another wonder-patch that'll surely make it's way to SVN within a matter of weeks! :D

How optimised is it? And do I now have to re-encode most of my movies to fit? :p

[Dark Shikari]

Wow, Dark Shikari with another wonder-patch that'll surely make it's way to SVN within a matter of weeks! :D

How optimised is it? And do I now have to re-encode most of my movies to fit? :pHow optimized?

Its probably erring on the side of caution in the disabling of certain RD thresholds; I'm guessing I might want to reinstate them, just at a higher level than normal.

The "noise" operation is SIMD-optimized but its not nearly as optimized as it could be; it can definitely get faster.

[Ranguvar]

Massive ownage!

This is gonna be fun to play with. Thanks DS!

[Snowknight26]

Would there be any reason not to use FGO for something like transcoding 300?

[Dark Shikari]

Would there be any reason not to use FGO for something like transcoding 300?Sure, what if you wanted all the grain to be removed? :p

[[P]ako]

Awesome! It has even the aq patch... well I shouldn't be surprised about the aq patch, now that it is part of x264 cvs.

[Snowknight26]

Sure, what if you wanted all the grain to be removed? :p

Is it ready enough to be used for non-development environments?

[Dark Shikari]

Is it ready enough to be used for non-development environments?Probably not, but you can try :p

[Dust Signs]

Hi Dark Shikari,

looks like a very nice patch, but there is one thing which keeps bothering me when talking about H.264 film grain... the standard specifies a SEI film grain message which I have not seen yet in any implementation. Wouldn't there be a much bigger gain in quality if the grain was just removed with a filter, the filtered movie encoded, and the grain added with this SEI message? This would save a lot of noise from being encoded with an enourmous amount of bits... just an idea, as I don't know if there are any decoders which consider this SEI message for it is optional.

Dust Signs

[Sagittaire]

Hi Dark Shikari,

looks like a very nice patch, but there is one thing which keeps bothering me when talking about H.264 film grain... the standard specifies a SEI film grain message which I have not seen yet in any implementation. Wouldn't there be a much bigger gain in quality if the grain was just removed with a filter, the filtered movie encoded, and the grain added with this SEI message? This would save a lot of noise from being encoded with an enourmous amount of bits... just an idea, as I don't know if there are any decoders which consider this SEI message for it is optional.

Dust Signs

Decoder (hardware and software) must be compatible with FGM. As far I know it's not the case for libavcodec, coreavc ...

[McCauley]

Hi Dust Signs,

the problem is that there's no way to remove the grain without loosing any details, you can degrain and sharpen afterwards to (re-)amplify the softened details, but you are always altering the picture. If it would be that easy, you could just degrain and apply AddGrain(x.x) during playback to it.

@DS
Thanks for all your work on x264, this patch could be the next big step after AQ.

Regards
McCauley

[CruNcher]

Subjective wise this works really well especially on B-frames where prestige fails even with b-rdo (b-frames) FGO has no problems to keep the grainy Look & Feel constantly (and very visible) throughout every frame very impressive, indeed it fakes the eye really efficient and can even bring back the grain feeling after resizing :)


Prestige = 15.30 fps Global:45.183 Y:0.9806016
RD Prestige = 10.74 fps Global:45.404 Y:0.9799006
RD FGO 15 = 9.40 fps Global:44.612 Y:0.9758523
RD FGO 100 = 9.40 fps Global:44.153 Y:0.9739887


Speed wise it's also not much slower and for sure you can optimize on other options and still keep the grain but get almost as fast as without RD (not with the full detail preservation then but still with the grain feeling) :)

[Dark Shikari]

Hi Dark Shikari,

looks like a very nice patch, but there is one thing which keeps bothering me when talking about H.264 film grain... the standard specifies a SEI film grain message which I have not seen yet in any implementation. Wouldn't there be a much bigger gain in quality if the grain was just removed with a filter, the filtered movie encoded, and the grain added with this SEI message? This would save a lot of noise from being encoded with an enourmous amount of bits... just an idea, as I don't know if there are any decoders which consider this SEI message for it is optional.

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

Subjective wise this works really well especially on B-frames where prestige fails even with b-rdo (b-frames) That's partially because I cheated; FGO lowers B-frame quantizers somewhat to ensure they stay grainy :p

[ToS_Maverick]

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

oh your such a bad boy :p

i tested your new patch in combination with fft3dgpu > gradfun2db > x264. the results were excellent.
the banding is almost reduced to nothing.

your work is really amazing. this is a real great visual upgrade!

[mahsah]

Ah, the links are working for me now, thanks!

Anyway, this looks like a real breakthrough in encoding. The results I'm getting are fantastic!

[woah!]

same settings with --fgo 10 turned on and off



OFF
http://www.cif-forums.com/png/small/FGO_SMALL.png (http://www.cif-forums.com/png/FGO_NO.png)

ON
http://www.cif-forums.com/png/small/FGO_SMALL.png (http://www.cif-forums.com/png/FGO_10.png)

the bitrate used would give me a dvd9 result at 1080p...

[squid808]

Hello Dark,

I'm curious about the reasoning behind the formula for "noise score". Would you mind to elaborate?


Noise is measured as follows:

If X(i,j) is a pixel in a block, the noise score for that pixel is abs(X(i,j) - X(i+1,j) - X(i,j+1) + X(i+1,j+1)). This is summed up over all pixels in the block.

In other words, NSSD rewards modes which have a similar amount of noise and approximate the source reasonably well. This noise need not be exactly like the source's noise; it merely needs to be good enough.

[Dark Shikari]

Hello Dark,

I'm curious about the reasoning behind the formula for "noise score". Would you mind to elaborate?
1. The noise score itself represents the absolute gradient at each point, summed up; this is a relatively good indicator of noise level.

2. Because it doesn't matter exactly what noise we retain as long as its similar, two similar noise scores are a good thing.

[survivant001]

oh your such a bad boy :p

i tested your new patch in combination with fft3dgpu > gradfun2db > x264. the results were excellent.
the banding is almost reduced to nothing.

your work is really amazing. this is a real great visual upgrade!

can you put a screenshoot, I'm curious :)

[Razorholt]

In incredibly simple terms: it measures only that the amount of noise in a candidate block is the same as it should be, not that its the same noise as in the source.

So, with a non-grainy source the picture shouldn't be degraded when using FGO, correct? Also, how FGO will "play" with non-grainy source + addGrain? I guess I should try... :)


Thanks,
- Dan

[elguaxo]

amazing! thanks!!

[Dark Shikari]

So, with a non-grainy source the picture shouldn't be degraded when using FGO, correct?Oh, it should, but not that badly.

[burfadel]

With a non-grainy source, any chance of a film grain threshold? Adaptive strength based on threshold? That would be particularly useful for mixed videos!

I have noticed with the couple of clips I did the file size increased significantly, but I guess thats expected! (the results are great).

I read somewhere that the b-frame decision of x264 could be improved, is this true? Would that affect the FGO? Would storing the main film grain in b-frames and using the principles of your grain optimiser plugin actually work, in an effort to reduce the output size impact (maybe as a different mode to fgo)?

[Dark Shikari]

With a non-grainy source, any chance of a film grain threshold? Adaptive strength based on threshold? That would be particularly useful for mixed videos!If we can get a good measurement of film grain that doesn't have false positives (this method, for example, would get a high "noise" value on a very sharp edge, which would be a problem for very clean sources), that might be possible.
I read somewhere that the b-frame decision of x264 could be improved, is this true?Yes.
Would storing the main film grain in b-frames and using the principles of your grain optimiser plugin actually work, in an effort to reduce the output size impact (maybe as a different mode to fgo)?You mean storing the grain in P-frames? That's actually already done in a sense since the B-frames often simply take the grain from the neighboring P-frames instead of re-encoding their own new grain. FGO makes this much more likely, since the bidirectional mode, which generally gives the best RD score, tends to blur out grain (making FGO less likely to select it).

[MfA]

Hell, someone is being paid this summer to work on improving the b-frame decision ... someone we know?

[Dark Shikari]

Hell, someone is being paid this summer to work on improving the b-frame decision ... someone we know?Its a GSOC project; Robert Deaton will be the student responsible for B-frame decision improvement.

[donis]

Awesome news :thanks:

[cestfait]

on fgo:

I've never liked the flat matrix so much. Always wanted to use it, but it was too prone to banding and blocking.

This patch is a keeper. Spectacular work, Dark Shikari.

:)

[bokonon]

Decoder (hardware and software) must be compatible with FGM. As far I know it's not the case for libavcodec, coreavc ...

Does anyone know if it is supported by the sigma decoder in Network Media Tanks such as Popcorn Hour

[MfA]

the problem is that there's no way to remove the grain without loosing any details
There is no way to do lossy compression without loosing any detail either, there is going to be a crossover point where the saved bits provide a net gain.

[Razorholt]

@DS: I remember you say to enable p4x4 with GrainOptimizer. Do you recommend to do the same with FGO?

Thanks,
- Dan

[Dark Shikari]

@DS: I remember you say to enable p4x4 with GrainOptimizer. Do you recommend to do the same with FGO?

Thanks,
- DanNo, they're totally different; no benefit here to p4x4 really.

[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

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

[nm]

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.
But the version that takes more space could also have much higher visual quality. CRF doesn't measure quality in the same way as humans do, so you'll just need to use your own eyes for that. I'd listen to DS and akupenguin and use the same bitrate for quality comparisons :)

[DarkZell666]

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 .

The question that still needs answering : was the 30% bitrate increase worth it ? Was it well spent ? Would increasing the bitrate manually by 30% without enabling FGO produce the same benefit (or not, since FGO is supposed to do better, otherwise it would be useless, which I doubt :D) ? So now, you'd need to compare a 30% bigger FGO encode, and a 30% bigger non-FGO encode to compare, and here we go, comparing an FGO and non-FGO encode at the same bitrate. Back to start :rolleyes:

[Inventive Software]

I did a 2 pass encode at 2800 Kbps of the Open All Hours pilot (Ronnie Barker God rest his soul is hilarious), and noticed that the SSIM in the first pass was higher than the second pass, even though the first had something like this commandline:

--bitrate 2800 --pass 1 --subme 3 --partitions none --ref 1 --bframes 8 --me dia --interlaced --sar 16:15

Whereas the 2nd pass had this:

--bitrate 2800 --pass 3 --subme 7 --partitions all --ref 8 --bframes 8 --me tesa --interlaced --fgo 10 --bime --weightb --b-pyramid --b-rdo --mixed-refs --sar 16:15

The difference was 0.001 in pass 1's favour if I remember correctly.

[Dark Shikari]

I did a 2 pass encode at 2800 Kbps of the Open All Hours pilot (Ronnie Barker God rest his soul is hilarious), and noticed that the SSIM in the first pass was higher than the second pass, even though the first had something like this commandline:

--bitrate 2800 --pass 1 --subme 3 --partitions none --ref 1 --bframes 8 --me dia --interlaced --sar 16:15

Whereas the 2nd pass had this:

--bitrate 2800 --pass 3 --subme 7 --partitions all --ref 8 --bframes 8 --me tesa --interlaced --fgo 10 --bime --weightb --b-pyramid --b-rdo --mixed-refs --sar 16:15

The difference was 0.001 in pass 1's favour if I remember correctly.That's because FGO lowers SSIM.

By the way guys, I suspect that FGO is going to be obsoleted by my upcoming psy RDO metric, which will probably come out in a few days or weeks ;)

[Heaud]

I suspect that FGO is going to be obsoleted by my upcoming psy RDO metric, which will probably come out in a few days or weeks ;)

I can't wait for the release of that! I have been playing with FGO and I am amazed at how it works so well with noise that prevents banding.

[Dark Shikari]

I can't wait for the release of that! I have been playing with FGO and I am amazed at how it works so well with noise that prevents banding.Copypasta'd from another thread:
Here's a simple unthreaded build (http://mirror05.x264.nl/Dark/force.php?file=./x264_new_metric.exe); note its my dev build so it contains a few unrelated patches related to b8x8 and p4x4 (minor RD improvements).

How to use: The more RD, the better. Subme6? Good. B-rdo? Better. Subme7? Even better.

Use deadzones (trellis 0) with it; I'm not sure how well trellis 1 would perform. Trellis 2 should be fine I guess.

The purpose of the algorithm used here is to attempt to weight higher the importance of retaining complexity in the output video; this generally results in better-kept dither and sometimes results like this (http://i27.tinypic.com/a4ldtj.png) (without new algorithm, same bitrate (http://i29.tinypic.com/344fpd3.png)).

Note that this is a general-purpose psy optimization that, ideally, should improve any source, even very clean sources.

[Sagittaire]

By the way guys, I suspect that FGO is going to be obsoleted by my upcoming psy RDO metric, which will probably come out in a few days or weeks ;)

Good news because actual FGO outperform by far GrainOptimisation from MC/Elecard.

[Mug Funky]

ooh, i missed this thread, but it's definitely relevant to my interests.

i'm gonna throw some 16mm at it and see how it stands up in HD (or should i go 2k? avisynth kinda hates 2k).

[techouse]

Since the FGO patch fails to patch r877 I made a cosmetic fix so it works ;)

x264_FGO_techouse_fix.diff (http://pastebin.com/f7dcb4e0f)

The problem was this:

patching file `common/pixel.c'
Hunk #4 succeeded at 581 (offset -1 lines).
Hunk #6 FAILED at 671.
1 out of 6 hunks FAILED -- saving rejects to common/pixel.c.rej

So I changed these problematic lines:
@@ -614,6 +671,7 @@ void x264_pixel_init( int cpu, x264_pixel_function_t *pixf )
if( cpu&X264_CPU_SSE2 )
{
INIT5( ssd, _sse2 );
+ INIT5( nssd, _sse2);
pixf->ssim_4x4x2_core = x264_pixel_ssim_4x4x2_core_sse2;
pixf->ssim_end4 = x264_pixel_ssim_end4_sse2;
pixf->sa8d[PIXEL_16x16] = x264_pixel_sa8d_16x16_sse2;

To these fixed lines:
@@ -605,6 +662,7 @@ void x264_pixel_init( int cpu, x264_pixel_function_t *pixf )
if( cpu&X264_CPU_SSE2 )
{
INIT5( ssd, _sse2 );
+ INIT5( nssd, _sse2);
INIT5( satd, _sse2 );
INIT5( satd_x3, _sse2 );
INIT5( satd_x4, _sse2 );

As you can see the fix is only cosmetic ;)

Enjoy :)

[Sagittaire]

Well, first this patch work incredibily well. The ability to keep grain at low/medium bitrate is really good now. Even better than Mainconcept/Elecard implementation.

+/* The weights chosen (5 for each) are arbitrary. They should probably be the same for SATD and SA8D but */
+/* the overall weight is chosen for no particularly good reason. */

Grain/noise is really hard to see on low luma level. Why not choose luma level for weight:

-> Low luma value imply classic RDO way with low grain/noise retention.

-> High luma value imply PSY RDO with high grain/noise retention.

[Dark Shikari]

Well, first this patch work incredibily well. The ability to keep grain at low/medium bitrate is really good now. Even better than Mainconcept/Elecard implementation.Know why? Mainconcept's "film grain optimization" is nothing but a bias in favor of inter blocks. Just a simple, one-line, non-adaptive numerical bias :pGrain/noise is really hard to see on low luma level. Why not choose luma level for weight:

-> Low luma value imply classic RDO way with low grain/noise retention.

-> High luma value imply PSY RDO with high grain/noise retention.This would completely eliminate the ability of psy RDO to keep fine detail on dark gradients and other places where x264 normally blurs out detail; IMO this is one of the places where it does best.

[Sagittaire]

This would completely eliminate the ability of psy RDO to keep fine detail on dark gradients and other places where x264 normally blurs out detail; IMO this is one of the places where it does best.

Grain/noise are high temporal complexity. Detail on dark area generaly not. The best HVS way for dark area is:

1) Eliminate noise/grain on dark area because it's hard to see fine gradiant here.

2) Eyes are really sensitive to global in dark area (banding and blocking artefact). Use lower quantisation (AQ) without grain/noise (after filtering ... or other way) is a really better HVS way at equivalent size.

VC1 from MS work like that for very high quality encoding. VC1 PEP use Dark Noise Filtering for eliminate grain in dark area and after use AQ with luma masking for better quality in dark area.

http://jfl1974.free.fr/upload/Sans%20titre.PNG

[dimzon]

fgo rocks!
C:\12>"C:\Program Files\megui\tools\x264\x264.exe" --pass 2 --fgo 10 --bitrate 1
791 --aq-strength 1.2 --stats "C:\12\ss12.stats" --ref 10 --mixed-refs --no-fast
-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --filter
-2,-1 --subme 7 --trellis 2 --partitions all --8x8dct --me umh --merange 24 --t
hreads auto --thread-input --sar 1:1 --progress --no-dct-decimate --output "C:\1
2\video12.mp4" "C:\12\12_video.avs"
avis [info]: 720x576 @ 25.00 fps (432825 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX MMX2 SSE SSE2 SSE3 3DNow
mp4 [info]: initial delay 2 (scale 25)
x264 [info]: slice I:2350 Avg QP:19.59 size: 34844 PSNR Mean Y:44.94 U:48.55
V:48.69 Avg:45.79 Global:45.23
x264 [info]: slice P:180307 Avg QP:21.74 size: 13950 PSNR Mean Y:42.54 U:46.94
V:47.05 Avg:43.55 Global:43.19
x264 [info]: slice B:250168 Avg QP:22.00 size: 5112 PSNR Mean Y:42.44 U:47.06
V:47.14 Avg:43.44 Global:42.89
x264 [info]: mb I I16..4: 10.9% 73.7% 15.4%
x264 [info]: mb P I16..4: 2.3% 7.9% 0.7% P16..4: 44.1% 20.6% 16.6% 0.3% 0
.1% skip: 7.4%
x264 [info]: mb B I16..4: 0.1% 1.4% 0.1% B16..8: 47.8% 1.5% 3.5% direct:
6.5% skip:39.1%
x264 [info]: 8x8 transform intra:75.0% inter:63.9%
x264 [info]: direct mvs spatial:98.2% temporal:1.8%
x264 [info]: ref P 60.0% 13.8% 8.0% 4.1% 3.4% 3.2% 2.7% 1.6% 1.5% 1.6%
x264 [info]: ref B 76.2% 11.3% 4.1% 2.2% 1.7% 1.5% 1.3% 0.9% 0.7%
x264 [info]: SSIM Mean Y:0.9843682
x264 [info]: PSNR Mean Y:42.494 U:47.019 V:47.114 Avg:43.500 Global:43.022 kb/s:
1791.03

encoded 432825 frames, 4.17 fps, 1791.08 kb/s
http://ipicture.ru/uploads/080612/thumbs/NSSTwit5Y1.png (http://ipicture.ru/Gallery/Viewfull/2470115.html) http://ipicture.ru/uploads/080612/thumbs/zs7eq412p2.png (http://ipicture.ru/Gallery/Viewfull/2470116.html) http://ipicture.ru/uploads/080612/thumbs/W3LH6wnS3i.png (http://ipicture.ru/Gallery/Viewfull/2470117.html) http://ipicture.ru/uploads/080612/thumbs/kdtepx6fWH.png (http://ipicture.ru/Gallery/Viewfull/2470118.html) http://ipicture.ru/uploads/080612/thumbs/kfLC263jWr.png (http://ipicture.ru/Gallery/Viewfull/2470119.html) http://ipicture.ru/uploads/080612/thumbs/AOx3pSIKbY.png (http://ipicture.ru/Gallery/Viewfull/2470210.html) http://ipicture.ru/uploads/080612/thumbs/106cUOCuep.png (http://ipicture.ru/Gallery/Viewfull/2470211.html) http://ipicture.ru/uploads/080612/thumbs/7C7v41Vieq.png (http://ipicture.ru/Gallery/Viewfull/2470212.html) http://ipicture.ru/uploads/080612/thumbs/0DYWgT7SFx.png (http://ipicture.ru/Gallery/Viewfull/2470213.html) http://ipicture.ru/uploads/080612/thumbs/2WXOHKUPd1.png (http://ipicture.ru/Gallery/Viewfull/2470214.html)http://ipicture.ru/uploads/080612/thumbs/3Bg1FpOGGN.png (http://ipicture.ru/Gallery/Viewfull/2470272.html) http://ipicture.ru/uploads/080612/thumbs/gW6ngH2sri.png (http://ipicture.ru/Gallery/Viewfull/2470273.html) http://ipicture.ru/uploads/080612/thumbs/zfZV6cR63s.png (http://ipicture.ru/Gallery/Viewfull/2470274.html) http://ipicture.ru/uploads/080612/thumbs/XBTvTs3mKU.png (http://ipicture.ru/Gallery/Viewfull/2470275.html) http://ipicture.ru/uploads/080612/thumbs/aYadBmJNVT.png (http://ipicture.ru/Gallery/Viewfull/2470276.html)

http://rapidshare.com/files/121784904/video12-007.mkv.html

[Razorholt]

Try psyRDO with trellis 2, it's even better ;)

[e-Pawel]

When will the FGO be adapted into the "official" release?

[Dark Shikari]

When will the FGO be adapted into the "official" release?If something is adopted, it will probably be psy-RDO, since its more general-purpose, but I may end up combining the concepts of the two; I'll have to do more investigation.

[foxyshadis]

Off topic discussion moved to Reverse Engineering Discussion (https://forum.doom9.org/showthread.php?t=138654). Keep it there.

[TheCreamCrackerBoy]

Is the psyRDO/FGO development interrupted somehow? I was hoping to see some news lately. :)

[Shinigami-Sama]

Is the psyRDO/FGO development interrupted somehow? I was hoping to see some news lately. :)

FGO is being replaced or merged with psyRO
and theres still some work on it, mostly in dark's head/testbuild at the moment it seems

[TheCreamCrackerBoy]

What are those "diff" files (x264_fgo.2.diff, x264_FGO_techouse_fix.diff)?

Should I download them to use in my MeGui? If affirmative, which one(s) should I get?

Thank you,

TheCreamCrackerBoy.

[LoRd_MuldeR]

The "diff" files are patches. You apply them to the source codes before you compile your x264.exe and then you can use that EXE with MeGUI ;)

BTW: FGO seems to be obsolete, now that Psy RDO has become popular...

[Sharktooth]

Psy-RDO is more general use.
FGO is still unbeaten on heavy grain however Psy-RDO is constantly improving and i hope it gets as near as possible or even better than FGO.

[TheCreamCrackerBoy]

Can I try (psy)RDO with this MeGui (latest version 0.3.0.1020, downlodaded at http://www.videohelp.com/tools/MeGUI" (http://www.videohelp.com/tools/MeGUI)) our should I use a different build?

Note: I´ve found another forum concerning PsyRDO at http://forum.handbrake.fr/viewtopic.php?f=4&p=37755. Is that another research for PsyRDO?

My best regards,

TheCreamCrackerBoy.

[LoRd_MuldeR]

I think the latest x264 build that comes with MeGUI per auto-update already has PsyRDO ...

[Sharktooth]

yes. it already has psy-rdo 0.5 and it is enabled by default.

[TheCreamCrackerBoy]

yes. it already has psy-rdo 0.5 and it is enabled by default.

Shouldn´t I use psy-RDO 10?

[LoRd_MuldeR]

Shouldn´t I use psy-RDO 10?

There no no Psy RDO "10" :confused:

The latest version of the Psy RDO patch available now is v0.5 and the default value for "--psy-rd" is 1.0000 ...

[TheCreamCrackerBoy]

There no no Psy RDO "10"

On the first page of this forum, I saw references to the setting "FGO 10"... is psy-RDO different then?

[LoRd_MuldeR]

On the first page of this forum, I saw references to the setting "FGO 10"... is psy-RDO different then?

"Psy RDO" and "FGO" are two a completely different patches! Also Psy RDO is a more general approach and it will most likely replace FGO...

[Soichiro]

PsyRDO defaults to on at a setting of 1.0, and it shouldn't be changed unless you have a good reason to. The 0.5 refers to the version number.

It might be interesting to see what would happen if you set Psy-RDO to strength 10 though. :p

[Ranguvar]

It might be interesting to see what would happen if you set Psy-RDO to strength 10 though. :p
It puts the psycho in psychovisual :p