Описание Опций Nandub

Описание Опций Nandub: V1.0

Last updated 25.06.2001.

0. About this document

This document is created and maintained by Koepi , it was created on 12th of May, 2001 (first public version).

Updates:
0.112.05.2001 First public announcement.
0.213.05.2001 Fixing some typos, more parts precised (e.g. gauge, luma,...)
0.313.05.2001 Added "9. General things" - a kind of a FAQ
0.414.05.2001 Adding some explanations about sensitivity, corrected payback delay etc. - thanx to Maras
0.516.05.2001 Way too much changes to list them all. Some of the fixes:

- added the end credits suggestions by rmatei
- Major revision of introduction
- ... and many things more!

0.517.05.2001 Rock Hardy suggests some better explanations for high/lowpass and the formular how luma is calced.. :o)
0.518.05.2001 Added link for Maras ' nandub versions in the end credits section
0.620.05.2001 Converted the doc into HTML, added screenshots, some cleanups
0.708.06.2001 Upgraded doc to correspond to nandub 0.22 and added yaz' clear-ups about internal / normal SCD, motion, span,... as well as major clean ups, minor corrections,... now I used anchors to better jump from setting to setting,
i hope this is a useful feature!:)
0.809.06.2001 I fixed the enable BR modulation part as it was really unprecise... well, there was no explanation at all ;)
0.918.06.2001 Updated doc to reflect nandub b0.24. Rebuilt the whole doc from scratch
1.025.06.2001 Updated to nandub b0.25. Finally not many complains left so version 1.0 is reached :-)

1. Introduction

I started this documentation of the nandub options as lecarb at doom9's forum asked about the options in that nice program (thanks vV_nn for that pretty good work!).
This question is really belonging into a FAQ or a howto, so I decided to write down what I have learned about nandub that far.A big thanks to all people trying to clear things up at doom9's forum (-> Smart Bitrate Control).
If you have suggestions or corrections to these explanations, eMail them to me and I will try to update this document.
Please, don't eMail me about "how do I rip DVDs" or anything. I won't reply on such eMails. Thanks! :-)
There is a very good "SBC/Nandub Guide" at http://www.doom9.net/ so please use that as a starting point if you don't know about the program!
This doc is supposed to explain nandub's settings. It's no guide or something in that direction, so keep that in mind before you start bitching around about that it's too complicated for your small mind :-P

This is the SBC Options Menu - it's the main difference of nandub over virtualdub. All the settings described in here are made within this menu.

2. The Video -> SBC Options -> DivX - Options:

2.1 Codec Choice

You can choose between the (illegal hack of M$ MPEG4v3 called) DivX;-) codec or the "free" (legal) MPEG4v2 codec. Currently nandub just works with DivX;-) 3.11 alpha. Newer versions of DivX ;-) (for example these builds with VKI patches etc) prevent nandub from working.
If you installed and choose the wrong codecs, nandub will crash or produce no file or too small/too big files.
As MPEG4v2 is "the older codec" it gives worse quality at the same bitrate. But every windows installation should play it without problems, if the codec isn't installed it gets loaded from M$ servers at playback time.

2.2 BitRate

The standard bitrate entry - calculated from a (or new: THE!) bitrate calculator :-). So this is the average bitrate that nandub should reach.

2.3 Keyframe interval

This is the maximum allowable interval in seconds that can have _no keyframe at all_. So setting this to 1 would mean to insert a keyframe every second, if the codec or nandub don't set one between this interval. So setting it to 10 or 12 seconds is a good value. Setting it to 1 second will degrade the quality very much as keyframes take up a lot more space and the codec/nandub has to compensate for that.

2.4 Minimum allowable bitrate

According to yaz : "First nandub calculates bitrate for the frame coming up, i.e., applies compression, motion correction, ... and then(!) applies min.kbps, i.e., if bitrate would run below it's simply set back to min.kbps."
As this happens without regarding average bitrate this can produce an oversized output video. If you watch the debug output you'll notice that this isn't shown there, it shows the value _before_ applying the min kbps.
I use 350 or 400 there, always works fine for me. Setting it below these values would degrade quality - i never experienced problems with _these_ two values but the documentation/ forum <http://forum.doom9.net/> says it would make the codec behave unpredictable. At least for me and these two values this isn't true ;-)

2.5 Internal SCD

As yaz points out, internal SCD works based on motion. If the motion level is higher than the given percentage (of max. motion 299), nandub inserts keyframes here. This will give high motion scenes plenty of keyframes, most likely degrading the quality if there are too much keyframes. I'll cite him: "it may help if luma differences are (very) small (otherwise use only oscd) motion sens gives a scale fine enough (i prefer 10 or higher) it's set not below 98% (but rather to 99%)".
For getting a complete picture take a look at the alternate SCD section.
I set it to 100% as this disables it and stops the overuse of keyframes. I encoded lethal weapon 4 with iSCD 90 and it used lots and lots of keyframes. this was supposed to give better quality in complicated scenes, but instead, i use AntiShit as it helps me with my freeze frame problem as well and works better as "quality raiser".
(Hm, btw. this iSBC means internal Scene Change Detection - it's code from nandub. I use the alternative SCD in the Options -> preferences tab with the default values in that SCD-tab. Works great!!!).

2.6 Space KFs

Default of 24 frames works pretty well for me - I don't touch it anyways. Setting it too higher values, say, 48 or 72, is giving other people good results as well as the codec inserts keyframe-like frames as well then. It prevents the overuse of keyframes but gets overriden by AntiShit (look below ;) ). It controls the SCDs from kicking in too often.

2.7 Anti-shit =)

AntiShit =) is decompressing the encoded frame and compares it with the input frame. The following settings control, when AntiShit should reencode a frame as keyframe (or as high quality deltaframe).
As he totally reworked the AntShit, I take his explanations out of the nandub readme:

2.7.1 Shit dB

When activated (set to a value different from 0), each compressed frame will get decompressed and compared to the source one. The resulting measure will be between 0 and about 95dB. If this measure gets lower than 'AntiShit', a keyframe will be forced (the resulting frame is also tested). A good value for AntiShit would be 16 I think.

2.7.2 Min quality dB

Suggested settings for 'Min quality' would be 0 (deactivated) or about 28-30. When the quality gets lower than 'Min quality', Nandub will try to recompress the frame without rekeying, but at a lower compression level. In the debug ouput, you should see 2 new values : PSNR=aa.aa(ww.ww) aa.aa is the average PSNR of the frame, ww.ww the measure of its worst block. 'AntiShit' and 'Min Quality' both use the ww.ww measure.

2.7.3 Motion Modulation

The new parameter is a %age and works like this : let's assume we entered 16 as AntiShit, 30 as Min Quality, with 50% modulation, here is what will happen :

with motion = 0 : AntiShit=16, Min Quality=30
with motion =150 : AntiShit=12, Min Quality=22
with motion = 300 : AntiShit=8, Min Quality=15

With 25% modulation, here is what will happen :

with motion = 0 : same
with motion =150 : AntiShit=14, Min Quality=26
with motion = 300 : AntiShit=12, Min Quality=22

3. The Video -> SBC-Options -> Bitrate Curve:

3.1 Motion based curve Modulation

This is an algrithm that I'm experiencing very good results with. It is modulationg the bitrate according to motion. This keeps size predictable and looks way better than directly setting DRFs or similar attempts. Disable bitrate reservoir modulation, it's not needed anymore with this algo! :-)
I got best results for mcFactor (that's it's name in other nandub-hacks) at 20%-30% (i prefer 30% though).

3.2 Curve Compression

This is the curve compression. The curve is the "bitrate-used"-stats generated in the first pass. Curve compression is flatening this curve, freeing up bits for low-bitrate scenes by taking them from high-bitrate scenes.
The symetric curve compression compresses the curve the same way below and above the targeted bitrate in the same amount (wouldn't haved guessed that by the name, don't you? ;-) )
A too high value will make the high bitrate scenes look really bad. So values between 20 and 35% (just my experience) work best. If you want to use the calc-button between the two passes, you have to set the crosspoint according to your aims (1 cd or 2 cd).
I use crosspoint of 280 at the moment and had astonishing results (but I had to lower the compression of 37% (by the calc button) to 32% at leon the killer. This shows that you have to experiment with this as a compression of 50% gave me real good results for se7en as well....)
The new thing since nandub 0.25 (ok, the maras/rock hardy hacks had that much earlier (but were just there to proove that it works) :-) ) is the asymetrical curve compression. Some people said, they'd like the ability to move the bit's for their targets more specifically - like, if they want more bits on the high motion scenes, they now simply choose Compression Low 25% and Compression high 15% - although i wouldn't recommand that, Rock Hardy doesn't get tired to repeat himself shouting "_you will loose quality on the mid bitrate frames_". My experiences are that you get pretty well results with Compression Low at 15% and Compression High at 25%.

3.3 Luma Correction

I use the default values and they are fine - I didn't experiment enough without luma correction so I recommand to switch it on. I'll cite Demi9OD, moderator of the SBC-Profiles-Forum at doom9, as he explains the lumacorrection very simple:
"Every frame is analyzed on the first pass to include a value called "Luma Noise". This value is low when there is a uniform brightness over the whole scene. It is high when there is a great deal of contrast in the brightness of the scene. Tradionally these uniformly bright areas are more difficult to encode, so any frame with a Luma Noise under the threshold, will get more bits depending on the multiplier. I do not know the exact math, but lets say threshold is 10 and your frame has a luma noise of 8, it would get 2*multiplier more bits. This is probably not the correct equation but gives you an idea of how it works."
This explanation is a little outdated as there is no multiplier anymore. It's substituted by a "max gain" control now which should be much more intuitive. (Thanks for listening to our suggestions vV_nn ! :-) )

3.4 End Credits Start Frame

Enter the frame where your end credits start here. This is used by nandub to reduce the bitrate for the end credits as these usually don't need to look that brilliant like the main movie (just scrolling names, eh? ;) ).

3.5 End Credits Rate

This is the bitrate that the end credits should be encoded with. This is should work now better as high pass and min kbps aren't applied for the end credits anymore since nandub b0.24. I didn't play around with this yet (hey, nandub b0.24 is out for just 2 hours at this point of writing the guide again!), so you're free to test that yourselfes :-)

3.6 High-pass / Low-pass

High-pass limits the lowest possible bitrate the codec can use.High-pass means to let only data pass above this level. Low-pass does the other direction - it let's only data pass below this value.Here is how it works (thanks Rock Hardy!):
"During the bitrate-curve modulation progress it looks at the calced framesize and determines if its above or below that High-Pass Value. If its below Nandub sets Bitrate for that frame=High-Pass, calcs the delta and adds this to a pool called "added". Those bits that were invested here are then taken from the other frames in a second process. For low-pass its the same, only that we get a negative pool or "added" and thus the "other frames" dont get bits taken away but receive bits by that process."
I set high-pass to 270 (default) and low-pass to 2500-3000 (for 2 CD rips) or 2000-2500 (for 1 CD rips). A too high lowpass will make the movie unplayable on weaker processor-systems, so don't set it too high!

3.7 Bitrate redistribution

Bias is the old way the bitrate curve was redistributed - it's spreading bits at fixed amount to the frames. The proportional redistribution is a little smarter here as it gives smaller frames less bits than bigger frames... so if a frame is already good compressable it doesn't waste too many bits on it. I prefer proportional redistribution.

3.8 Smoother

Leaving this untouched or changing it between 3% to 5% gave good results for me. As the people of the forum say, it's flatening the curve in a short period and not over-all, preventing the compression-levels jumping around in a nuts way. It's averaging the values within this span, so if you have a frame series consuming 95 kbps, 100 kbps, 105 kbps all three frames are encoded with 100 kbps if smoother is set to 5%.

4. The Video -> SBC-Options -> Motion-Detection - Options:

4.1 Span

Thanks Maras for clearing this up :
One frame is not enough to characterize motion, so nandub analyzes span frame before and after. The rule is the same for sensitivity, but each frame in span scope has different weigth. For Span=3 weigths goes like 1,2,3,7,6,5,4.
I use the default 8 here, and it works well. Following rmatei , setting this value too high the short-time motion may not be detected by nandub (result is a worse looking scene). As well, the encoding process takes longer then.

4.2 Sensitivity

Again, thanks Maras for the info! :
This value tells nandub, how many keyblocks in a deltaframe should be different to make the frame considered to be at motion maximum (299). Value 10 means that 10 keyblocks in the deltaframe are considered motion 299, 5 means motion 150. 10 is also limit, so 100 keyblocks has the same effect like 10. Notice that 640x272 frame has 680 blocks... (not just keyblocks though...)

4.3 Fast/Low Motion sliders

If these sliders are set to 300 then the codec-switching between high-motion DivX;-) and low-motion-DivX;-) is disabled. (in fact turning the fast-motion-slider to 300 will suffice.) Using lower values will switch the codecs at the given "motion points", e.g. fast motion at 285 and low-motion at 265 will switch to DivX;-) high motion when motion detected in the first pass goes over 285 and will fall back to DivX;-) low motion when dropping below motion of 265 again. Don't use codec switching. It degrades quality at the high-motion scenes unneccessary and introduces problems with dropped frames and/or
freeze frames - instead I use the bitrate reservoir modulation (see below) and the main DRFs. The high-motion codec is in fact nearly the same as the low-motion-codec (but has a better scene change detection core) with hardcoded DRFs from 5x to 16x. So you can emulate it by setting the DRFs according to that.

4.4 Crispness modulation

The crispness modulation is modulating the crispness (hehehe ;) ) level of the codec, this means that in high motion scenes the crispness is set from 100 dynamically down to (100- the value of this) (background: the eye doesn't notice the crispness that much in high motion scenes). For me, crispness modulation of 20-30% are working quite fine. This makes the scene better compressable while not introducing (as much as without this) "blockyness" in the final avi. This is working by "smoothing" the picture by using the codecs functions - it sets the crispness level of it per frame (and not overall as usual in the normal "out of the box" codec setup dialogue seen if you use flask for example).

4.5 Enable BR modulation

To cite Demi9OD:
"What it will do is increase DRFs (less bits) for high motion scenes. This drops the actual bitrate under the first pass curve and adds to the gauge. These bits are then distributed into scenes with less motion. If you have your gauge set from 25-70, it should make no difference if BRm is on or off, file size should end up close to target."
The disadvantage of it is, that it makes the movie look uglier. Maybe use this for 1 CD rips - but i don't recommand it as we now have the Motion based curve modulation. Never use it for 2 CD rips.

5. The SBC-Options -> Gauge Control - Options:

5.1 Payback Delay

This is the time in seconds that the codec should use to "pay back" the "over-use" of bits in some scenes. Nandub is using it for the span of time you enter here to "compensate for bits overused by the gauge min limit" (according to Maras ).
45 seconds (default) work fine for me. The max value of 120 seconds is good for movies with longer high-bitrate scenes to give it the space to compensate using many bits in these.

5.2 Corrections on low-bitrate conditions

If the minKbps value gets used on a frame and you enable this, the Bitrate Reservoir gets "frozen" at it's state because the bitrate curve isn't used in such a situation.
You should also check Modulated as this isn't freezing the bitrate reservoir but taking away the bits used on such a frame, which is more acurate.

5.3 Gauge

The gauge has the most impact on the quality/filesize - but you have a dependance on the DRF levels etc as well. You can render it useless by setting "the wrong values" there. For me (producing 1 cd rips) a start value of 35 (default), min value 30 (default) and a max value of 80 (NOT default) work fine.
The gauge is influencing the bitrate reservoir. If the codec runs out of bits, the less bits for the next frame encoded are used until the frame is dropped. Gauge min is the minimal level the bitrate reservoir gets reset to if it drops below this level, it prevents the codec from using a too high compression on a frame. A good rule to get oversized movies is to set a high min. gauge and a low max DRF.
Gauge max is limiting the upper bitrate reservoir border, if it gets too big it may introduce too low compression levels.

5.4 KF Boost

The amount of this value is added to the bitrate reservoir at insertation of a keyframe. I always use 5% here, but for most people 0% works well. A too high value may make the final filesize unpredictable, so I conform with doom9, 5% is max.
With the new "Keyframe DRF" option (see below) I prefer to set it always to 5%.

5.5 Freeze

Don't touch this one. This will make the codec think, that this amount of the bitrate reservoir is available, forcing it to always use a certain amount of compression. It's used (and useful) only in the first pass.

6. The Video -> SBC-Options - Compression Levels - Option

DRF is short for "Detail Removal Factor" and therefore a higher DRF means higher compression. I always leave the possible granulation untouched and therefore all "when motion over"-fields at 300 (this disables them as motion can't go over 299). I just use the Main DRF settings, varying from 2x (min) to 5x(max). This just works for 2 CD rips or very low motion (bitrate) movies, you have to raise the Max. value up to 9 (in "hardest cases" even 16!) to reach your desired filesize.
A lower max DRF will give you better quality, but bigger filesize - a higher max DRF will result in a worse quality but a smaller file.
New in nandub b0.24 is the "Keyframes quality" parameter. I set it to 2 or 3 as it gives an amazing quality boost, even if there a fewer bits left for the deltaframes. In former nandub versions keyframes almost always got a DRF level of 4x, no matter what the debug view was spitting out there. I tested this on some movies like gladiator and taxi taxi... it's amazing what quality you can get with these classical 2 CD rips on 1 CD with this!!!

8. The SBC Options -> Bitrate Calculator

vV_nn included the bitrate calculator of Kthulhu. It works straight forward like you expect an bitrate calculator to work %). Your calculated get's inserted as DivX bitrate automatically, that's the main advantage (as well as you don't need an external calculator anymore).

9. The Options -> Preferences - Options

9.0,5 The Main - tab

Nando reactewd on the requests of some forum members and added a Dub default Process Priority. This is useful if you run many programs / tasks at the same time on your computer and want it to work alone for 2 passes in one go.
After finishing first pass the second pass priority got set back to the default process priority ("normal"). So set this box to the value you want the priority get set to by default.

9.1 The Scene - tab

Yaz explains that alternate SCD works with
luminance differences (see internal SCD for the other possibilities...). If luminance exceeds a "kind of treshold limit" nandub inserts a keyframe (the treshhold is dynamically calculated frame by frame, so it's variable). I cite him here:
"the default value is ok for most movies. for darker ones (as most parts of "matrix", "dark city" or so) it should be lowered but not below 30%. (33% for matrix gave perfect kf setting)
add.: i don't use the orig scd (vdub heritage) as it's very sensitive. it must be tuned movie to movie & it's almost hopeless to find a perfect setting for the whole movie."
I just leave Interframe cut and fade untouched as they work fine at these values (or better: aren't used with alternative SCD). I check the new "alternative" as this is a scene detection core that gives really amazing results! The default Multiplier of 35 works pretty well for me.

9.2 The AVI - tab

Hehehe, vV_nn inserted an "I'm the stupidest man on earth :P" option
You may check this if you want to have a confirmation-dialogue before overwriting a stats-file.

9.3 The SBC - tab

The crosspoint value is used in the calculation (calc-button) at the curve-compression. Until now there is no final rule how this should be set, but using a crosspoint of 230-280 for 1 CD rips and 350-460 for 2 CD rips has been tested to work well. If you think your calced compression is too high just lower the crosspoint :)
See the nandub documention (readme.doc) for how the crosspoint works.

10. General things / FAQ

1. Question: Do I need to use all the filters (resize, deinterlace, smoothers,..) at the first pass as well?

Answer: Yes. Every filter that is changing the quality of the movie is affecting the "compressability" of it as well. For a good looking movie after second pass the first pass has to be _precise_, that's how nandub works. You will get an overcompressed movie if you don't use e.g. the smoother filters in the first pass as nandub decides about the compression of a frame by looking how big it was after the first pass. I tried it once or twice to not use the same filters in the first pass and the movies looked like shit after that as the frames were compressed too high.

2. Question: I did all you wrote above and the result is all odd - blocky and jerky. What to do?

Answer: You may have a problem with too many keyframes produced by AntiShit. Try disabling it by setting it to 0 and see if it works! Disable minQuality as well. Else, set the min gauge lower and the max DRF higher.

3. Question: Which resize filter method should I use in nandub?

Answer: If you're going to do 1 CD rips then use precise bilinear, as it smoothers the picture a little and makes it better compressable. For 2 CD rips, use precise bicubic, as it sharpens the picture a bit and thus enforces the codec to use more bits as it doesn't "like" sharp edges.

4. Question: What's with the end credits? Nandub always makes them _huge_ in bitrate/size!

Answer: Well... encode them manually. Take a pencil and a papersheet and then search your input video for the beginning of the end credits. In the statusbar of nandub you can see the actual frame number. Write it down. Now go to "select range" in the video menu, enter start: 0, end: (your frame-number you wrote down). Do all the usual main setup for the movie, except for the end credits: leave them empty.
Do "save avi as" as this starts the second pass.
If this is ready, go to the range-settings again and enter start: (your downwritten number), end: last frame of the movie... you can get the number by moving the slider all to the right side before (maybe you should write downthat number as well ;) ). If you selected the credits range now, just go to the normal settings like DivX Bitrate etc and lower them to for example 200 kbps. Min Kbps to 150, Hi-Pass 150 as well, main DRFs 2x-16x,... and so on. Well, with nandub b0.24 the end credits solution should finally be done right. (I can't confirm this yet.)

5. Question: What if the final size is too big/small?

Answer: rmatei suggests:
If filesize is too small:
lower the DRF, raise min & max gauge, use bicubic, raise resolution. NEVER raise bitrate, that makes it even less predictable.
If filesize is too big:
FIRST & FOREMOST reencode credits, then raise DRF, lower min & max gauge, use bilinear, lower resolution. Or shoot for one more CD ;)

6. Question:

Answer:

The End

This "nandub options explained"-document is (c)2001 by Koepi.
Thanks for everyone who is giving support at doom9's forum ! Without all your help i couldn't have compiled this document, so you are the real maintainers of this document!!! Treat it as public domain licensed, but if you use it for anything
please do me the favor for my ego to mention me ;-)