Roba Support?

[jdobbs]

I did four movies overnight. No more oversizing. All came in at 4.1xGB. I may want to tweak a little higher, but I may be getting close to the best it's going to get (without significantly more time in sampling).

[DDogg]

A few questions and comments later, but I wanted to acknowledge I completely understand this is an early implementation of RoBa and that it may continue to grow in functionality. I hope so because it looks like you have a great start going on.

On the above log some of the extras are encoded at a higher quality than the main encode. The "Steal space from extras" crashes at the present, but I assume this is going to be fleshed out more? Do you see the time when that section will be made more automatic?

OPV is a useful encoding method, but only if the Q-Value is within an acceptable range. Arguably, one of the biggest strengths of the logic created by RoBa is the ability to predict quality before the encode begins which allows intelligent decisions by the software to take various automatic actions to reduce the Q-Value to an acceptable quality.

Presently I am a tad confused on your design direction regarding RoBa. Do you see it just as an alternative OPV encoding method where 'you get what you get', or do you plan to move toward a more automatic decision making implementation to maximize quality of the main encode. That is, the smart bitrate allocation thing?

If a OPV Q-Value encode gets above 40, some would argue 32, it is better to go with multipass, or take other actions, instead of continuing the encode. I sense we are from different camps on this "other actions" subject from your sparse comments on filtering and such, but whether that is true is hard for me to completely understand as I don't believe you have ever clearly stated what you see as your final direction for RoBa.

I bring this up attempting to get an idea of where you wish to go on the subject and because of the sense that I may be aggravating you with the continual commentary about the Smart Bitrate Allocation AI thing and the use of selective compression filtering and cropping when prediction shows unacceptable quality will result without them.

Since I respect you greatly, causing you any irritation is about the last thing I want to do. Having a better understanding of your direction would be helpful for shutting me up, so it may be well worth your trouble to do so :D

[jdobbs]

@DDogg,

I guess from my point of view there are two different angles here.

From an intellectual point of view I love to discuss points such as using OPV with predictive analysis (I hesitate to use the term RoBa because I'm not really sure I understand what RoBa really is, how close I am to RoBa, and whether I would offend the RoBa method authors). I see a lot of potential for using that information in an AI manner to created the absolute best backups possible.

But from a product point of view... When implementing useful software the esoteric angles have to take a back seat, and the practical takes precedence. The average user doesn't know what Q is, and really doesn't care. They want to make fundamental choices: I want my output fast with decent quality (OPV) or I don't care how long it takes -- I want the best quality that will fit on a DVD-R.

So my goal is to first give the user base what they want... then if I can use the results of that effort to create a better backup, I will. But only in a way that doesn't require a PhD to use.

One of the best uses I can see is pointed out in your example in this thread. If I can release valuable storage space from an extra by knowing that it's Q value is within a certain range and reallocate it to my main movie -- I've just found a way to steal from the rich and give to the poor... But I will only do that as an invisible function.... If I start asking people to decide what Q they want it is the equivalent of an architect asking his banking customer what stress analysis method they'd prefer he use in determining their structural integrity... the answer is "it's your job to figure that out, use the best one"

So I guess my answer is: Practicality first.

[jdobbs]

Oh... as for the filtering. Yes I am very opinionated on this. In my mind there is little difference between getting a low Q and filtering. With filtering you've purposefully decided to distort the picture -- and the Q reports artificially better because you have corrupted the picture before the Q calculation.

The only plus I can see is that at least in filtering you've made the decision as to what and how the picture gets distorted.

[added] What I mean by low Q is "bad Q" -- not a low numeric number (which would indicate "good" Q)

[hoozdapimp]

JDobbs, I understand what you're saying, but is there any chance you would consider just using the exact method Tylo does for DVD2SVCD? It works VERY well, and he might even write a plugin for DVD-RB, or give you an exported dll you could just call to use with your program.

[jdobbs]

Originally posted by hoozdapimp
JDobbs, I understand what you're saying, but is there any chance you would consider just using the exact method Tylo does for DVD2SVCD? It works VERY well, and he might even write a plugin for DVD-RB, or give you an exported dll you could just call to use with your program. I just don't like to steal other people's code and you never really understand something unless you figure it out for yourself.

[hoozdapimp]

Originally posted by jdobbs
I just don't like to steal other people's code and you never really understand something unless you figure it out for yourself.
Oh I agree. Being a programmer myself (not as good as you obviously), I totally understand wanting to figure it out yourself and not wanting to steal other people's code. And who knows, maybe by working on it yourself you'll figure out an even better way of doing it or making it even more accurate. I'm just trying to suggest maybe just talking with him, and maybe that will give you ideas on how to improve, but still writing the code/algorithm yourself....I love the idea of one pass encoding and I'm just eager (probably a little too impatient) for it to work perfectly (almost :)) with DVD-RB...keep up the good work :)

[DDogg]

But I will only do that as an invisible function I completely agree with your thoughts on that. Frankly, I believe we both would like an app where you can have a couple of whiskeys (or three), stick in the DVD and press the "Make me an awesome DVD" button and go snore a little.

To get there does require delving down into the guts. BTW, I completely understand your point about using other people's code. When you start fresh and learn the minute details, it is a good feeling of accomplishment AND you actually know the subject matter in depth, so you can then build more upon it. That is not reinventing the wheel in my book, just a true way to learn something.

So, up to that point you would not hear a peep of disagreement from me. Hehe, here comes the however. I noticed you er, forgot to reply to the Pepsi challenge thing :) I would paraphrase your ex tagline with, "If you can't see any effects of filtering, is it distortion?". I put it that way, because I would never suggest something for compression filtering that you can see. I completely agree with you. However, if you are suggesting that it is better to have an encode with macro-blocks, than one that seems near perfect, I question your intellectual reality :) Especially if you have not actually tried it. Personally I think the "purist" view is fairly antiquated today and is stuck back at the time people did really dumb over-filtering. Believe me when I tell you I am a damn perfectionist when I put a movie on a DVD, else I would use SVCD where I can accept some very minor negatives.

If your suggestion is I do a crap encodes after all these years because I judiciously use filters, then I would suggest we compare encodes of LOTR any day. I'm at a beautiful Q22 and there is no way in hell you can touch that (hoping you are motivated by challenge). I assure you, it looks incredible on my TV as well as a friends 100" projector screen. You cannot tell the difference between the encode and the original DVD whereas the encode without black/overscan crop and light filters is at Q47 and looks very poor. Well perhaps it is an intellectual honest poorness, but poor nevertheless.

I prefer the practical approach,

So I guess my answer is: Practicality first. :D

http://img17.imageshack.us/img17/9749/PDVD_000.jpg

http://img15.imageshack.us/img15/4931/PDVD_008.jpg

http://img15.imageshack.us/img15/3999/PDVD_003.jpg

[ShadowKnight]

@Ddogg

I'm just really starting to delve into making the best quality backups I can... I've used filters in cce (and they seem to do an alright job), and just a bit ago made a new thread and I mentioned something about it. But I'm very curious to hear what methods and filters you use? You filter them before running through dvd-rb right? Could you guide me through your process? Or perhaps just point me to a thread you've mentioned this in before if you have :)
Getting a low Q like that on LOTR3 is awesome, and I'd like to be able to use your method on some of my backups.
I appreciate your help.
Thanks for doing what you do. I have a lot of respect for you sticking around here for so long, driving ideas forward and keeping people informed.

[jdobbs]

@DDogg

Man... you exhaust me. The point I was making is that if you measure Q after a filter... you aren't measuring quality. What Q would you get after running BlankClip()? I choose to stick with my convictions. In this instance I also have the advantage that I own the code...
:)
That doesn't mean I won't use filters. It only means I choose to be right on this one.

BTW -- how the hell could I know whether you do crap encodes? So why would I make that suggestion? You're reading too much into completely innocuous statements.

[DDogg]

Man... you exhaust me. The point I was making is that if you measure Q after a filter... you aren't measuring quality. What Q would you get after running BlankClip()? I choose to stick with my convictions. In this instance I also have the advantage that I own the code... You absolutely do own your code and the project. It is always difficult to know where discussion will be helpful and where it becomes exhausting. It was my wish to stimulate discussion, not tire you out :).

The statement above does show me there is a disconnect in our communication as well as a general misunderstanding about CCE OPV Q mode as well as some of the most basic building blocks of how source complexity dictates the bitrate required to carry, or 'hold' the said complexity.

In closing, I would suggest a simple exercise, do OPV samples of the same source at the same X Q-Value, say Q28, using bilinear, bicubic, and LanczosResize. You will see three different final filesizes.

Do the same thing with something as simple as 8,9, 10 DCT values. Again you will see three different sizes. Do the same with three different matrices and you will get three different sizes.

All things effect the compressibility of an encode in varying degrees, thus they effect the final filesize of the encode. Of course you must include those things when sampling for a Q-Value to fit within a certain filesize. What is not clear about this most basic fundamental of compression, or how am I misunderstanding you?

I sense a major disconnect, or some kind of basic knowledge gap, between us, but I do not wish to exhaust you further. Like I said, I respect you very much and I know you are one heck of a lot smarter than I am :)

[jdobbs]

Sigh... It ain't a contest. But it feels more and more like a debate that will never end. That's what is exhausting. I have nothing but respect for you.

[quantum]

Originally posted by jdobbs
... The point I was making is that if you measure Q after a filter... you aren't measuring quality. What Q would you get after running BlankClip()? That's like a beacon in the storm. I was going to bring that point up some time ago but I didn't. I prefer not to get involved when discussions turn endless. If you get tired of the forum, there is a simple solution. Do not reply. Get back to coding ;)

[DDogg]

Originally posted by jdobbs
Sigh... It ain't a contest. But it feels more and more like a debate that will never end. That's what is exhausting. I have nothing but respect for you. We never had a debate, nor was it my intention to have any type of contest. I just wished to have a two way discussion on a topic that is interesting to me, and I thought to you.

I don't know diddle about the inner structure of a DVD, but do feel like I have a pretty decent handle on compression, and what the incremental flow might be to achieve the best possible encode within a given preset space. Thought I could make a small contribution in that area. I think maybe our heads just work a little different from each others. No problem at all. Best of luck on the project.

PS - I thought we would end up at the practical end of discussing the logic flow of how to do this stuff near invisibly to the user. The "Do an awesome encode for me button".

[edited in header]

[DDogg]

Originally posted by quantum
That's like a beacon in the storm. I was going to bring that point up some time ago but I didn't. I prefer not to get involved when discussions turn endless. If you get tired of the forum, there is a simple solution. Do not reply. Get back to coding
quantum, perhaps you could have that discussion with me? You see the statement makes absolutely no sense to me. Since you comment on it, you must understand it intimately. Perhaps you could explain it to me in detail so I can understand it also? Perhaps commenting in the thread mentioned in my Sig might be a better place. If you wish to refute that work piece with logic I would highly enjoy the discussion (I do love to learn).

[Edited in the header and made a few spelling corrections.]

[r6d2]

jdobbs,

I'm surprised I did not notice this thread before. Very interesting! Maybe that PM you sent me the other day was regarding to this. Was the info I gave you of any use? You seem to like to re-discover the wheel a lot. ;)

Anyway, I don't want to get into a religious discussion about if filters reduce quality or not. I know UnDot+Deen() reduces size without any visual impact I can notice. DVDs are created with lots of redundant information, and there are several ways to reduce that information to keep only what you are able to see. Filtering is only one of them.

For instance, as it has been mentioned on this thread, resizers make an impact on the encode size. Also does frame size. For one, I've found that converting some anamorphic sources to Half-D1 anamorphic does not reduce the visual quality. OTOH, in other cases it does.

Normally I stick to 704 width since that's what my projector is able to handle. And I eliminate the anamorpic aspect because of the same thing.

There is probaby not a "best way" to make a DVD9 to DVD5 copy for the general case, but I've found that in quite a few cases this is near the optimum:

Main movie encoded at 704x___, 4:3. OPV 30
Extras encoded at 352x___, 4:3, VBR setting BR to what it's left after encoding the movie. (Number of passed depending on which Q is estimated for extras).

[dragongodz]

at the risk of getting my ears burnt... :)

i agree that light filtering can be helpful for low bitrate encoding to reduce noise, blocks etc. how much and what specific types is a personal thing which need not be gone in to here and now.

however it seems to me that jdobbs is more interested(rightly) in getting DVD-RB working 100% before considering such possible tweaking. as such we should all respect that and leave this discussion until he is ready or interested in having it.

[Noah]

Originally posted by r6d2
Normally I stick to 704 width since that's what my projector is able to handle. And I eliminate the anamorpic aspect because of the same thing.

There is probaby not a "best way" to make a DVD9 to DVD5 copy for the general case, but I've found that in quite a few cases this is near the optimum:

Main movie encoded at 704x___, 4:3. OPV 30
Extras encoded at 352x___, 4:3, VBR setting BR to what it's left after encoding the movie. (Number of passed depending on which Q is estimated for extras).
For the rest of us who don't have your projector or your eyes, this isn't terribly optimum. This is why I think its best for Rebuilder not to assume anything and just come closest to a pure reencode as possible. If you know what else you want done, there's a lot you can do through the Avisynth scripts.

There are cases where the original DVD is far enough away from a generally accepted optimum, and that's why the 4:3 letterbox -> 16:9 option makes good sense to me, and also why I'd like to see either official support for IVTC or even the possibility of manually scripting IVTC.

[tylo]

Oh, my. This thread was really about RoBa, wasn't it?

jdobbs, I don't know much about how you implemented your Q-estimation routine. I know you use 0.5% sample, which in my experience gives a too high error variance. I use 1% sample which is barely OK. (0-2% estimation error most of the time, but sometimes up to 3%).

If you want, I could give you a simple condensed algorithm how to search for Q. It's not very complicated.

The way D2SRoBa does it is somewhat more advanced because it must deal with the max-bitrate limitation for SVCD. The Q-function normally follows an exponential (almost straight) slope, but near max-bitrate it suddenly bends a lot. In that case I switch from newton-raphson to binary search for Q.

For DVD bitrates, that shouldn't be an issue, and it should be fast and easy to find the closest Q that match the target bitrate. Btw. you have to subtract about 1.2% from the estimated size, when determining the Q. Also check 'Restrict auto I-frame insertion' in CCE (fix_gop_length=1) - it improves the estimation accuracy a little (tips from jonny).

/More technical talk: Another note about the accuracy of the final mpv bitrate (from an OPV encode) versus the original target bitrate:

In D2SRoBa, I compute the current estimated Q-step size in percentage, i.e. 100*(estBR(Q) - estBR(Q+1))/targetBR. This varies from 0.8% to 4%.
Example: if this number is 3%, it means that it is 3% between each Q (in that Q-area), which again means that, in worst case you cannot hit better than 1.5% on target, even if your estimates are absolutely correct. What I'm saying is that this error comes on top of the possible estimation error (e.g. if test samples are not representable).
Anyway, normally this all equals out, and D2SRoBa has proven that the method works excellent.

[jdobbs]

@tylo

What I do now is:

- Estimate a rough order of magnitude (ROM) Q value using:
(framecount / targetsectors) * 256
I pulled that out of the air after a few tests.
- I then start with the ROM Q and do these steps until estimated total sectors is within 1% of target or the Q doesn't change.

1. Do a .5% sample using SelectRangeEvery(2400,12)
2. Get the resulting M2V size and estimate sectors for complete encode
3. Set Q = Q * (estimated_sectors / target_sectors)

As a final step, if the estimated_sectors is greater than target_sectors I set Q = Q + 1

So you are saying estimated_sectors should be (estimated_sectors * .988)?

I also throw out the first 12 frames because they are blank so often.

[jdobbs]

One more question: I don't have to restrict auto I-Frame insertion on the final encode, do I? You're just talking about the predictive encodes?

[tylo]

Here is what I suggest you do:

0. Possible add an ROM_Q_const=256 in your ini file. Advanced users may want to tweak it.

1. Do a sample using SelectRangeEvery(GOP_len * 100/sample_percent, GOP_len) Possible add sample_percent=0.5 in your .ini file for advanced users. (I'd like to use 1.0% sample).

2. Get the resulting M2V size and estimate sectors for complete encode

3. Set Q[i+1] = Q[i] * (F*(estimated_sectors[i] / target_sectors - 1) + 1). Use F=1.35 as default (do experiment). If you try it on DDogg's log (page 3), you will notice that it hits optimal Q on second test for most of the VTS's. You can adaptively update F if it doesn't hit optimal Q on second test:F = (Q[i]/Q[i-1] - 1) / (estimated_sectors[i-1]/estimated_sectors[i] - 1), which makes it very likely to hit optimal Q on the third test. (Again, DDoggs log got F=1.35 on most tests).
So you are saying estimated_sectors should be (estimated_sectors * .988)?No. the other way around. Set adjusted_target_sectors = target_sectors * 1.012, and use that as target. I have recently discovered that GOP length may influence on how large this factor should be. It seems that GOP_len=12 requres a little higher adjustment than GOP_len=15, which is common to use with SVCD.
I also throw out the first 12 frames because they are blank so often.Yes, that seems wise for shorter clips (like extras).
I don't have to restrict auto I-Frame insertion on the final encode, do I? You're just talking about the predictive encodes?Correct.
/Add:As a final step, if the estimated_sectors is greater than target_sectors I set Q = Q + 1Well, actually if you skip the adjusting step (1.2% thing) mentioned, you can also skip doing the Q increase. These two actions will equal out. There is always a small chance of oversizing anyway. (You could do a Rejig pass then, like D2SRoBa...) Good luck.

[jdobbs]

@tylo

I appreciate all the tips. I'm going to implement this and give it some trial spins tonight. This is one of the things I love about Doom9... I can get advice from the master!

[jdobbs]

Originally posted by r6d2
jdobbs,

I'm surprised I did not notice this thread before. Very interesting! Maybe that PM you sent me the other day was regarding to this. Was the info I gave you of any use? You seem to like to re-discover the wheel a lot. ;)

Anyway, I don't want to get into a religious discussion about if filters reduce quality or not. I know UnDot+Deen() reduces size without any visual impact I can notice. DVDs are created with lots of redundant information, and there are several ways to reduce that information to keep only what you are able to see. Filtering is only one of them.

For instance, as it has been mentioned on this thread, resizers make an impact on the encode size. Also does frame size. For one, I've found that converting some anamorphic sources to Half-D1 anamorphic does not reduce the visual quality. OTOH, in other cases it does.

Normally I stick to 704 width since that's what my projector is able to handle. And I eliminate the anamorpic aspect because of the same thing.

There is probaby not a "best way" to make a DVD9 to DVD5 copy for the general case, but I've found that in quite a few cases this is near the optimum:

Main movie encoded at 704x___, 4:3. OPV 30
Extras encoded at 352x___, 4:3, VBR setting BR to what it's left after encoding the movie. (Number of passed depending on which Q is estimated for extras). Same comment to you r6d2, I appreciate your help... just a question -- when you use undot().deen() do you ever use any parameters for deen? I ran a test just to see if I could tell any difference. I couldn't... but I also didn't get any change in resulting Q or visible improvement at a given bitrate. Am I missing something?

[ShadowKnight]

Stupid question, but it needs to be asked...
are the dlls for undot and deen in your avisynth plugins directory?
thats about the only thing I can think of...
when I use undot and deen on a source it yields about 12Q lower than without them. At least with about Q40-50, cause I dont really remember how much improvement the lower ones yielded, but it was definately an improvement.

EDIT: oh and I personally dont use any paramaters. I'm still learning all these filters and its a bit brainracking at first. Can anyone list the applications of the modes of deen, and what the values mean and do. I've been looking all over for a detailed explanation, and I've not been able to find. Anyways... thanks for the avs filter edit option in DVD-RB Jdobbs :) Its working great. Awesome job on this program!

[r6d2]

Originally posted by jdobbs
Same comment to you r6d2, I appreciate your help... just a question -- when you use undot().deen() do you ever use any parameters for deen? Nope, I don't. Mainly because I don't understand s**t about the meaning of the parameters. :) Seriously, what Deen does is a sort of convolution with a certain matrix. I know you can tweak it, but my guess is that marcfd did set up the defaults to the most reasonable, useful, and tested thing, so I'd rather buy his stuff instead of experimenting with something I do not understand.
but I also didn't get any change in resulting Q or visible improvement at a given bitrate. Am I missing something? This I don't buy. I have yet to find a single source where Deen() has little effect on output size. Of course this only makes sense if you use OPV. If you use VBR Multipass the output size will be exactly the same no matter the filtering, so the purpose of using Deen in the first place is kind of useless.

But that's precisely the point. If you use OPV to have the movie encoded with the quantization you want, you get the leftover available BR for extras as a side effect. Some users may not be comfortable with that, but it works for me. Personally, I seldom encode extras since I always have my originals to watch them from time to time. And I use the movie backups (several per DVD) for everyday life.

[DDogg]

Filters used in multipass can be very effective also as they reduce the complexity of the source just like they do for OPV. Yes, they will not effect size because multipass is bitrate based, but by reducing the complexity, the encode will 'fit' more efficiently within the 'bitrate basket'.

In other words, bitrate by and of itself, is irrelevant to the measurement of quality. Like a basket, it is only the vehicle that holds the source complexity. How much material that can be packed in it is based on how complex the shapes of the contents are. Many more small compact square blocks will fit in the basket than irregularly shaped odd blocks. Light filtering, when used carefully, allows a reduction of complexity of the video (just my own theory). That allows a corresponding reduction of bitrate. When you make the shapes more compact, you can use a smaller basket. When the shapes are oddly shaped and off sized, you need a bigger basket to hold them all.

Now, sure, you can also take a hacksaw and hammer to the shapes and get them to fit in an even smaller size, but who wants a basket full of junk. This is analogous to the over filtering that makes so many of the senior people on this forum whacko :)


In short and IMO, each specific source, by the very nature of its individual complexity, requires a certain bitrate to achieve a certain defined quality. When there is not enough bitrate available to match the requirements of the source complexity, inferior quality will result.

In this case using filters to reduce the complexity of the source allows a better match to be achieved to a given bitrate and better quality results.

Where there is ample bitrate to match the source's complexity requirement nothing much is gained from filtering. In fact, the point can be made that you should never use a filter unless tests show the bitrate is not already adequate to carry the desired quality.

[r6d2]

Originally posted by DDogg
In fact, the point can be made that you should never use a filter unless tests show the bitrate is not already adequate to carry the desired quality. Precisely what RoBaConditional does. Pretty much well said, DDogg. :goodpost:

[tylo]

If you are concerned if Undot().Deen() gives visual artifacts, you could try FluxSmooth() (tips I picked up form wmansir). I've used it lately, and it certainly reduces Q quite a bit (haven't really compared with U&D), and is also a little faster. In theory it should have less visual artifacts, because it only works on parts of the picture that has motion (flux), which is where the eyes really can't pick up possible differences.
/Add: could be interesting to try it with SPR (saving private ryan).

[jdobbs]

Where there is ample bitrate to match the source's complexity requirement nothing much is gained from filtering. In fact, the point can be made that you should never use a filter unless tests show the bitrate is not already adequate to carry the desired quality. Completely agree. All filtering is distortion and should be avoided. But sometimes it's better for you as the viewer to decide which distortion is better (e.g. image smoothing from a filter as opposed to gross macroblocks caused by lack of bitrate).

[DDogg]

Yeah, most especially when light filtering is a near invisible form of mathematical distortion not readily apparent to the eye, while macro-blocks are just ugly and very easy to see.

[jdobbs]

DDogg, you're kinda' like Mark Twain's father. It's amazing how much you've learned since I decided to start trusting your opinion. You are stubborn, though ;)


BTW: For anyone who doesn't decode this: it's a compliment

[jdobbs]

@tylo,

Just wanted to let you know that the algorithm above works great. In my tests I hit the correct Q value on the second encode most of the time and have yet to have needed more than three. I'm running tests now to see how closely the end results match the prediction. I will add the INI entries you suggested -- 1% sampling is a lot more palatable when you only have to do two prediction passes.

Thanks for the great advice.

[tylo]

You're welcome, my friend. It's my small donation to your great project. :)

[tylo]

@jdobbs, although you haven't needed more than three sample tests so far, the Newton-Raphson method used in D2SRoBa, may converge safer to the optimal Q (from third test).

Q[i+1] = Q[i] - NRoot(i)*(Q[i] - Q[i-1])/(NRoot(i) - NRoot(i-1))
NRoot(i) : (estimated_sectors[i] - target_sectors)

So you don't need to update F - just use this formula instead.

Again, D2SRoBa uses this because optimal Q for SVCDs is harder to find than for DVDs. So if the current algorithm proves to work fine, you don't need it.

Cheers.

[SansGrip]

Originally posted by tylo
In theory [FluxSmooth] should have less visual artifacts, because it only works on parts of the picture that has motion (flux), which is where the eyes really can't pick up possible differences.
I realise I'm dredging up a month-old thread, but I just thought I'd clarify how FluxSmooth works. The algorithm is exceptionally simple, and is designed to avoid filtering motion when at all possible. It's more or less a median filter: it looks for pixels that are inconsistent with their temporal neighbours and applies smoothing to those pixels only. For example:


Frame Pixel value
1 150
2 175
3 158

FluxSmooth will consider the pixel in frame 2 "noise" and will average it. However:


Frame Pixel value
1 150
2 165
3 170

FluxSmooth will consider the pixel in frame 2 part of an overall trend (an unsophisticated, but quick, motion detection method, really) and will not average it.

It's unsophisticated but in my experience seems to reduce noise quite nicely (not necessarily visibly, depending on settings, but enough to have a positive effect on compressibility) without the usual side-effects of most temporal smoothers.

But I might be biased... ;)