Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
7th October 2007, 06:44 | #1 | Link |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
New Filter: GrainOptimizer (2.02 -- Bug fixed with certain temporal denoisers)
>>>GrainOptimizer 2.02<<<
The only temporal-only grain reducer! Simple summary: This filter "slows down" the progression of grain over time to vastly decrease the bits required to encode that grain. On a per-frame basis, the filtered clip will look almost exactly the same as the original. Pros: Huge bitrate drop over unfiltered clip (up to 40-50%+), and often higher image quality due to better bit distribution in encoding. Keeps the grainy look of the original source. Cons: Temporal grain pattern isn't exactly the same as the original. Not as effective at lowering bitrate as a real, strong denoiser, if used alone. Less effective in very high-motion scenes; doesn't usually have negative effects but doesn't reduce the grain as effectively as in stationary scenes. Requires a powerful denoiser to input the denoised clip, so while fast alone, it isn't as fast in practice. Full information: One of the main problems with film grain is it is completely uncorrelated with the grain from the previous frame. This means that in low-detail blocks, such as the background of a frame (usually most of the blocks), the encoder is forced to use intra blocks instead of inter blocks, since the current frame's block is almost completely unrelated to the previous frame's block. This filter resolves that by removing grain temporally but not spatially, in a manner in which the visual difference between the result and the original is minimal, and not even necessarily a negative difference. Using a combination of heuristics, it decides which areas of the frame should be acted on, and then which blocks should be retained between frames. As far as I have found in my testing, no visual artifacts are created by this technique as long as the proper heuristics are used. This filter is somewhat motion-adaptive but not motion-compensated, and as a result it is quite fast (real-time on SD footage easily, even though it has no assembly code and is completely unoptimized). However, this also means it is not very effective in moving areas. This isn't really what the filter was meant to do to begin with though: its goal is to deal with background grain eating up bits, and that's what it does. The end result is a basically "free" bitrate reduction of up to 50% at the same CRF/QP for high-grain sources, assuming that your bitrate is high enough that the encoder actually does attempt to preserve the grain--this is particularly important in x264, known for decimating grain at all but the lowest CRFs. Note that theoretically this filter will work for all encoders, not just x264--the benefits aren't as large in non-H.264 codecs, but both VC-1 and Xvid have shown bitrate drops of nearly 25% in my tests. Note that you should have at least a few bframes and p4x4 blocks enabled to take full advantage of this filter. If it isn't clear at this point, the GrainOptimizer is intended as a preprocessing algorithm for a video encoder. Syntax: GrainOptimizer(clip,denoisedclip,blocksize,strength,tdist,minrep) Colorspaces supported: YV12 only (YUY2 and YV24 are possible in the future, RGB24/32 are not possible without drastically changing the algorithm.) denoisedclip is the clip used for most of the internal heuristics and as such is very important. The better the denoiser you use, the better results you will get. A strong denoiser is recommended--losing details doesn't matter in this case, what matters is temporal stability. Inspect your denoised output if the filter doesn't seem to be working as well as it should; the denoised clip should have no noticable grain at all for maximum effectiveness. FFT3DGPU with a very high sigma (10+ for strong grain) + TTempSmooth works quite well, though I assume others like RemoveGrain(19) will work well also. Note this clip must be YV12. blocksize is the size of the block (width/height) used for the block retention algorithm. 4 and 8 are the values currently supported, and 4 is the recommended default. strength is by default 1 and is a decimal value. Note that as of version 2.0 the strength is automatically determined on a frame-by-frame basis--this number is simply a multiplier for the value determined internally. Don't change it unless the default has problems. tdist is the maximum temporal distance, in frames, over which a block can remain static for due to the retention algorithm. It is by default 6: higher values will make the grain seem to move "slower", and lower values will make it seem to move "faster". A value as low as 2 will reduce the effectiveness of the filter somewhat but keep the grain's appearance almost exactly the same as the original. Higher values result in slower and slower grain, making it appear more like a static dither. minrep sets the minimum number of grain replacements per macroblock. This is by default 8--higher values result in fewer blocks acted upon but more efficient action on those that are acted upon. Values cannot be above (256 / Blocksize^2) or below 0. The old behavior of the program, before this option existed, was equivalent to minrep=0. Recommended: keep it at 8. Perhaps different values might be better with other codecs? Lowering the value will decrease efficiency but might make the result look more grainy. This filter is experimental--report bugs and cases where it creates problems here, but don't complain about it doing so! New version 2.02 New version 2.01 Old version 1.2 Version History: 2.02 -- Some temporal denoisers have very overly strong effects at scene changes, which tend to confuse the GrainOptimizer. This has been compensated for in most cases. 2.01 -- Bugs fixed with 2.0. 2.0 -- Rewrote over half the code. It now automatically determines the strength necessary on a frame-by-frame basis, to deal with changing grain patterns. The biggest change is that it requires a denoised clip as a second input, for much more accurate motion detection. Chroma option was removed for code simplicity. 1.2 -- Major improvements. Randomized starting array, resulting in slightly nondeterministic behavior but no "solid" appearance for the first few frames of an encode. A lot of improvements were made to considerably lower the bitrate by optimizing specifically for MPEG-4 ASP/AVC encoding styles and dealing with the residual costs of macroblocks. Additionally quality should be slightly improved, and some quality bugs fixed. New option added. Blocksize can now be 8, but is not recommended (though it should work). Functional changes: the new version now should decrease bitrate on almost all input sources, including some reduction on already-denoised sources. 1.11 - Minor algorithm updates 1.1 - Major bugfix: GrainOptimizer now works correctly on longer sequences. Chroma heuristic added. 1.02 - Feature improvement: non-mod16 resolutions now supported. 1.01 - Minor bugfix: non-mod16 resolutions now correctly result in an error instead of a crash. 1.0 - Initial Release Last edited by Dark Shikari; 19th November 2007 at 18:43. |
7th October 2007, 07:40 | #4 | Link |
Fighting spam with a fish
Join Date: Sep 2005
Posts: 2,699
|
This certainly looks interesting. Do you mind if I ask were you go the 30% reduction numbers from? Just curious.
Unfortunately, I don't have any sources right now that would benefit from this filter, but as soon as I do, I will give it a try. Unless you recommend using it on every single clip I might ever use? |
7th October 2007, 08:09 | #7 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
Last edited by Dark Shikari; 7th October 2007 at 08:24. |
|
7th October 2007, 09:23 | #8 | Link |
Fighting spam with a fish
Join Date: Sep 2005
Posts: 2,699
|
Huh. Good to know.
Theoretically, this might be a good filter for anime, no? They tend to have flat backgrounds and very little motion. I may have to try that out. I could also create some synthetic tests using addgrain() or something. |
7th October 2007, 09:28 | #9 | Link |
Errant Knight
Join Date: Oct 2004
Location: St Louis, M0 US
Posts: 364
|
@Dark Shikari
Thanks for the new filter. |
7th October 2007, 11:00 | #10 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,729
|
I can't get the dll to load at all.. I'm running WinXP SP2. Autoloading or LoadPlugin doesn't do the trick, with LoadPlugin I just get the error message "Cannot load grainopt.dll". When autoloading, the function GrainOptimizer is not available.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
7th October 2007, 11:23 | #11 | Link |
unrecognized user
Join Date: Oct 2005
Location: home of Stella Artois
Posts: 303
|
Not working here either. The script loads in vdm, but when I try to scroll it crashes.
Been following the other thread about this filter and the examples seemed to be pretty good, especially considering x264 kinda detemporalizes the grain by itself at medium bitrates, so maybe this can do same thing while preventing other side effects x264 makes at medium quants (~21 and up).
__________________
zzz |
7th October 2007, 11:24 | #12 | Link | |
Errant Knight
Join Date: Oct 2004
Location: St Louis, M0 US
Posts: 364
|
Quote:
Sorry didn't see that or more like notice before. Ok, I promise. Last edited by Ebobtron; 7th October 2007 at 11:30. |
|
7th October 2007, 19:35 | #18 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
No, it doesn't, but the algorithm requires it. The only way to get around it is basically to pad the sides or similar. I could have my filter simply pad the sides, do the algorithm, and then unpad the sides, of course.
Wait... quick question. In x264, when a video isn't mod16, does it pad all sides of the video or just one? The problem is that if the macroblocks in the video are off from what my filter thinks are the macroblocks, the filter will be drastically less effective. Quote:
I replaced it with a non-compacted version--try it out now. Last edited by Dark Shikari; 7th October 2007 at 19:39. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|