VirtualDub - Beginner's Guides / Tutorials?

[terrypin]

Are there any step-by-step guides to VirtualDup anyone can recommend please? I've so far not found any that achived a balance between being
- too basic (essentially just rephrasing the accessible feature help)
- too complex (essentially assuming you know it all already)

Ideally, I'd love to read as many worked examples as I can, with explanations why the various setting choices were made, and how optimum bitrate and fps figures etc were estimated (if the program itself can't do it!).

I'm still searching, but if anyone can point me in the right direction I'd appreciate it please.

--
Terry, West Sussex, UK

[guns1inger]

I don't know of any beginners guides to vdub. You can find a good list here https://www.videohelp.com/tools?tool=Virtualdub

and some more here https://www.videohelp.com/tools?tool=VirtualdubMOD

Most are focussed on specific tasks, but that may not be a bd thing, given the wide range of abilities Vdub has. A single guide would not be able to do it justice.

[kschang]

Are there any step-by-step guides to VirtualDup anyone can recommend please? Ideally, I'd love to read as many worked examples as I can, with explanations why the various setting choices were made, and how optimum bitrate and fps figures etc were estimated (if the program itself can't do it!)

Uh... Not sure if you actualy understand what VDub DOES. Optimum Bitrate would be calculated by external calcuator usually and is a part of encoder's option, not really related to VDub at all. As for FPS, that's up to your local display standards, like 29.97 for NTSC TV, right? Same for resolution. So I guess I'm a bit fuzzy on which part do you actually need to make "judgement calls" on.

[kr236rk]

hi terrypin,

well, how did you get on? i'm at exactly the place you were - several years down the line - what i need is a basic blow-by-blow tutorial (on filters, for example) to give me a practical result i can see (and save)

the best guide i have been directed to is

http://nickyguides.digital-digest.com/vdub-filters.htm

it is good, it is clear - but it presumes a working knowledge of the program which in my case simply does not exist, there are no benchmarks, at individual stages, for success or failure: a list of commonly encountered difficulties - their causes and solutions - would be a big help

at the moment i am filtering, compressing, saving - and ending up with a masked or black screen - i have absolutely no idea what i am doing wrong or omitting to do, to cause this?

thanks,

[jagabo]

it is good, it is clear - but it presumes a working knowledge of the program which in my case simply does not exist, there are no benchmarks, at individual stages, for success or failure

After adding each filter and setting it up you can go back to the main window and see the results in the output pane (usually the one on the right but you can swap the position of the panes with Options -> Swap input/output pane).

After adding all your filters does image in the output pane look the way you want? Then select the codec for compressing the file, set up its parameters (each codec has a different setup dialog because the dialog is a part of the codec itself, not VirtualDub), and Save as AVI.

If you are getting a black video after compression, even though the output pane looked fine, you may have been using a 2-pass compression. VirtualDub does not perform both passes automatically. Set everything up as you want in VirtualDub, then set the codec to "2-pass first pass" and then Save as AVI. (During the first pass the codec is only examining the video to see how complex each frame is. The codec may or may not actually put anything in the AVI file that's created. This may be why you get a black video) Go back to the codec settings dialog, and change to "2-pass second pass" (or n'th pass, or whatever it's called) and compress again. This time the codec will use the information it gleened from the first pass and compress the video as requested.

[kr236rk]

hi jagabo,

your suggestions are most gratefully received -

i don't know what i did [lol] but the the two windows started behaving themselves - the one showing footage before and the other footage after the filter (deflick msu) - yes,'n' it worked (!)

but when i saved the filtered version as AVI, the footage played back in mega pixels forming almost a contour effect of graded tone-pixels on the screen

am i skipping some final compression stage, please?

i will consciously check for the codec setting in future, thanks again!

[manono]

Well, like jagabo said, you have to then choose a codec after you get the filters set up the way you like. So, go Video->Compression, choose one (XviD, maybe), and then Configure it. You can set up the passes separately (run the first pass and then come back and run the second pass), or both at the same time (save the first pass to be run later, set up the second one also to be run later, and then go into Job Control to get it going. You can even run it for a single pass with a target quantizer (3, maybe) for faster results. You'll lose control over the file size, though. There are guides for this, although probably not too many any more for the way you're doing it. Most people have switched by now, or should have switched, to frameserving via AviSynth.

You didn't say what the source is. You might also have to do cropping and resizing, unless you're just reencoding an AVI.

Anyway, until you get the hang of it, I'd recommend using AutoGK for the job. It's pretty foolproof. Study carefully how it does it, and pretty soon you'll be able to do it yourself. It comes with a pretty good tutorial.

[jagabo]

when i saved the filtered version as AVI, the footage played back in mega pixels forming almost a contour effect of graded tone-pixels on the screen :(

What codec where you using? What bitrate? What frame size? It sounds like you had too low a bitrate for the frame size.

[kr236rk]

jagabo wrote:

What codec where you using? What bitrate? What frame size? It sounds like you had too low a bitrate for the frame size.

i'll give you everything cos i'm not sure what is doin what?

compression

PICVideo MJPEG Codec
compression/quality 15/20
(a second file was compressed at 10 - no apparent difference in pixel effect)

Filter

MSU Deflicker v1.3 with period definition [best]

safety: 33
change ground: 10
blend threshold: 6

'use blend' box selected

anything here which looks suspicious, please - i have a feeling a skipped a final compression somewhere down the line?

where in Vdub do i check for bitrate : framesize - are there recommended ratios for these two?

many thanks,

[jagabo]

jagabo wrote:

What codec where you using? What bitrate? What frame size? It sounds like you had too low a bitrate for the frame size.

i'll give you everything cos i'm not sure what is doin what?

compression

PICVideo MJPEG Codec
compression/quality 15/20
(a second file was compressed at 10 - no apparent difference in pixel effect)

Filter

MSU Deflicker v1.3 with period definition [best]

safety: 33
change ground: 10
blend threshold: 6

'use blend' box selected

anything here which looks suspicious, please - i have a feeling a skipped a final compression somewhere down the line?

where in Vdub do i check for bitrate : framesize - are there recommended ratios for these two?

many thanks,

PicVideo Motion JPEG doesn't have a bitrate setting. It only has a quality setting. At 15 the video should look fair. At 10 it will look rather bad but what you described sounds worse.

Some things to try with a short test video:

1) Set PicVideo MJPEG to 19. That will give you a large file but the picture should be nearly indistinguishable from the source. If you continue to see problems the cause is elsewhere.

2) Encode your source without any filtering. Encode with PicVIdeo MJPEG at 19. Is the video still corrupt? You may have a dueling codec problem. Maybe another codec is trying to decompress the PicVideo encoded video and failing.

[kr236rk]

hi jagabo,

you wrote:-

PicVideo Motion JPEG doesn't have a bitrate setting. It only has a quality setting. At 15 the video should look fair. At 10 it will look rather bad but what you described sounds worse.

Some things to try with a short test video:

1) Set PicVideo MJPEG to 19. That will give you a large file but the picture should be nearly indistinguishable from the source. If you continue to see problems the cause is elsewhere.

at 19 the pixels were much improved but then the strobe/flicker effect was very noticeable again

2) Encode your source without any filtering. Encode with PicVIdeo MJPEG at 19. Is the video still corrupt? You may have a dueling codec problem. Maybe another codec is trying to decompress the PicVideo encoded video and failing.

well since the quality setting obviously had an effect, i haven't gone on to the second test - shall i persevere with test two?

alternatively, what can i do to filter out the flicker but maintain more of the movie quality - choose a different file type, where i can manually set the bitrate?

regards,

[jagabo]

Since you seem to be happy with the picture quality of the first test I don't think you need to run the second. You were just using too low a quality setting.

Motion JPEG is not a good codec for making very small files. It compresses each frame of video as a JPEG image. Video codecs like MPEG use a mix of techniques where a small number of frames are encoded in their entirety (in a fashion very similar to JPEG) but most frames only encode the differences between successive frames.

So, with a talking head shot with a static background, a MJPEG file encodes the background and the person talking in every single frame. An MPEG file will encode the whole scene in the first frame, but several successive frames will only encode the movements of the talker.

What exactly is wrong with your source video? Is it from film that was badly telecined and the brightness of each frame varies? Or mabye a light was flashing off and on while you were shooting with a camcorder? That's the type of problem the MSU Deflicker filter fixes. I've only played with that filter a little bit -- with mixed results.

[kr236rk]

thanks jagabo,

you wrote:

What exactly is wrong with your source video? Is it from film that was badly telecined and the brightness of each frame varies? Or mabye a light was flashing off and on while you were shooting with a camcorder? That's the type of problem the MSU Deflicker filter fixes. I've only played with that filter a little bit -- with mixed results.

the source video is a 2.5 minute test, originally Super 8mm ciné footage, captured onto dv (directly filmed with a dv camera at asa 1/50). the effect i am trying to lose is a strobe due to the miss-match of 24fps ciné with dv fps (frames per second) rates ... the captured footage was slowed down in Pinnacle, hence the strobe which at realtime speed would be a flicker

the msu delicker filter worked wonders with the strobe effect (flicker) which creeps in throughout the film, especially in concert with a 'hot spot', which it also quietened down - it is a landscape movie so the hot spot appears whenever the sky comes into shot

i watched the wondrous transformation in the processed pane of the Vdub dual window, and was extremely impressed by what i saw; however, when i saved this processed imagery as an AVI file (suggested save format) and played it, the picture quality - giant pixels - had deteriorated beyong anything practicable; reducing the compression from 15 to 19/20 improved the image quality but restored the strobe.

would using a different compression medium - instead of MJPEG - help, or could i save the MJPEG to a different format, instead of AVI, to lose the mega pixel effect, please?

thanks for your advice which is greatly appreciated - i am a newbie on a helter-skelter learning curve!

[jagabo]

When saving with MJPEG at a quality setting of 19 the frames that come out will look almost exactly like the frames that went it. So something must have gone wrong with the deflickering process.

Switching to another codec won't help. The codecs' job is to compress and decompress a video such that it looks as close to the original as possible. Different codecs may give different size files or different image quality but its not their job to reduce flickering.

I'd concentrate on the deflickering options now that you know MJPEG at 19 will deliver acceptable picture quality. Once you get the deflickering settled you can consider other codecs which may give smaller file sizes (assuming that's what you want).

[kr236rk]

hi jagabo,

When saving with MJPEG at a quality setting of 19 the frames that come out will look almost exactly like the frames that went it.

yep, which is exactly what happened - more or less got the flicker out that went in ...

So something must have gone wrong with the deflickering process.

i've only tried the msu deflicker - i'll try the initial one; there are other ("3rd party?") deflicker filters out there somewhere, i think?

I'd concentrate on the deflickering options now that you know MJPEG at 19 will deliver acceptable picture quality. Once you get the deflickering settled you can consider other codecs which may give smaller file sizes (assuming that's what you want).

might it be the codec which is responsible for the jumbo pixel effect, please?

bests,

[terrypin]

Thanks for the helpful follow-ups, much appreciate the advice offered.

I've filed the side-topic on filtering raised by kr236rk for study later up my learning curve.

Yes, kschang, I now realise from further study this morning that bitrate/file size/quality factors are outside VirtualDub's remit, and down to the individual codec - DivX in my case. I see that DivX apparently uses a default of 780 kbits/s, whatever file is opened. So how should I set about deciding whether I should change that, and if so, to what?

Take a specific example. Following recommendations I saw elsewhere some days ago, I made a source file in FRAPS, from screen action in Google Earth Plus. The aim is to reduce its size dramatically. Roughly 75% of those I've processed have been successful, but the rest failed to run in WMP9 or load into Movie Maker 2. (FWIW, most of those 'failures', did play in Nero ShowTime, and of course in VirtualDub itself.) All compressed file sizes are about 20 times smaller than the original, and, when they are OK, are of adequate quality given their origin. So that reinforces the appropriateness of DivX for this application.

Information on Test.avi from GSpot:
-----------------------------------
336 MB (or 344,257 KB or 352,519,288 bytes)
Runtime 00:01:03 (1,896 fr)
x:y 840x598 (1.40:1) [~38:27]
Bitrate 44575 kb/s
FPS 29.971
Qf 2.961 bits/pixel

Now, when I use VirtualDub|DivX|Configure, I see the codec always uses a default of 780 kbits/s, whatever file is opened. Up until now I've been accepting that, and getting the results I mentioned. But now I'm wondering whether the choice of a different bitrate would avoid that 25% failure rate? I'm not too hopeful, but it's just one thing to eliminate. And anyway, I hate accepting deafults without knowing what the implications are. So... how should I set about deciding whether I should change that 780, and if so, to what? What would experienced users enter please?

--
Terry, West Sussex, UK

[kr236rk]

Thanks for the helpful follow-ups, much appreciate the advice offered.

ditto x 1000

[jagabo]

Now, when I use VirtualDub|DivX|Configure, I see the codec always uses a default of 780 kbits/s, whatever file is opened. Up until now I've been accepting that, and getting the results I mentioned. But now I'm wondering whether the choice of a different bitrate would avoid that 25% failure rate?

The appropriate bitrate for any particular video will depend on many factors. The frame size (larger frames need higher bitrates), the frame rate (more frames per second requires more bitrate), the brightness of the video (dark stuff compresses more easily than bright stuff), the complexity of each frame (a flat grey image will compress more easily than one with lots of detail), now much motion there is between frame (and the nature of the motion), and finally, how much picture degradation you are willing to accept.

There are three basic methods of allocating bitrate to a video:

1) Constant Bitrate (CBR). This uses the same bitrate for every frame. Simple frames (totally black frames for instance) may end up using much more bitrate than they need. Highly complex frames may end with lots of artifacts because they don't get enough bitrate. But this mode is fast (requires only one pass) and if you don't need lots of compression (high bitrates) works fine.

2) Multi pass variable bitrates (VBR). This is generally used to get the maximum picture quality for a fixed file size. During the first pass the video is examined to determine the relative bitrate needed for each frame. (The codec may or may not actually produce any output during this pass.) During the second pass, the encoder allocates bitrate to each frame depending on the information gleaned in the first pass and attempts to meet your file size (or average bitrate) requirement. More passes may be made to further refine the quality. But you get diminished returns with subsequent passes.

3) Constant Quality (CQ), AKA Target Quantizer. This is a single pass mode where you specify the picture quality you want. The encoder encodes each frame with that level of quality. You can't exactly predict how big the final file will be. The encoder will use whatever bitrate is needed for each frame.

In short, CBR is usually a waste of space. VBR should be used when you want to cram a lot of video in a fixed amount of space with maximum quality (Using Divx to put a 2 hour movie on a 700MB CD for example). use CQ when you want guaranteed picture quality and don't care about the exact file size.

There is one potential problem with CQ: sometimes the bitrate required to achieve the requested quality for a frame or scene will exceed that which some playback devices can sustain. For example, many set-top Divx/DVD players can't decode Divx at more than about 3000 kbps for more than a few frames. Some codecs have further constraints to allow for this.

[terrypin]

Excellent, just what I needed, thank you!

I'll study those 3 types and try implementing each in VirtualDub.

I'm still vexed about why some (maybe 20-25%) of my compressions so far crash WMP 9, or give corrupted purple and green results/ So if anyone has any ideas on how I might isolate the cause I'd be grateful please.

--
Terry, West Sussex, UK

[kr236rk]

hi,

it seems that the 1st version of the deflick filter doesn't work on my pc, but the MSU version does (to a degree)

when i choose the 1st version only one Vdub window ever comes on; in MSU both windows come on showing source and processed imagery, correctly

this obviously means something, but i do not know what it is?

i also prefer MSU cos the other filter has two bullet points called 'prepare video' and 'process video'; the latter is obvious, but what exactly does 'prepare video' do - must you run your movie through this setting before you process or filter it? anyhow, the MSU doesn't ask you to make this choice.

if only i could save what i can see in the processed window - if only!



thanks,

[jagabo]

it seems that the 1st version of the deflick filter doesn't work on my pc, but the MSU version does (to a degree)

You mean Donald Graft's Deflick filter? That one doesn't work with newer releases of VirtualDub. You can look for an old release of VirtualDub, or you can try VirtualDubMod which hasn't been updated for a few years.

i also prefer MSU cos the other filter has two bullet points called 'prepare video' and 'process video'; the latter is obvious, but what exactly does 'prepare video' do - must you run your movie through this setting before you process or filter it?

If you read the instructions for Donald Graft's filter you'll see there is a very specific procedure for using it. If you don't follow that procedure exactly you will get a black frame. I didn't try real hard but I was unable to get it to work with VirtualDub 1.6.9 or VirtualDubMPEG2 1.6.11 (the versions I currently have installed). It does work with VirtualDubMod 1.5.10.

if only i could save what i can see in the processed window - if only!

Well, that's what you should get if everything is working properly.

The little bit I've played with MSU's deflicker filter it seemed to get confused by many things. I don't now of any other deflicker filters for VirtualDub.

[kr236rk]

"if only i could save what i can see in the processed window - if only! "

jagabo wrote:

Well, that's what you should get if everything is working properly.

The little bit I've played with MSU's deflicker filter it seemed to get confused by many things. I don't now of any other deflicker filters for VirtualDub.

i am so near to getting the result i want it is driving me sideways - there is the filtered footage in the process window, but can i save it? surely i can save it?

think i am making a pig's ear out of deflick#1 but i prefer MSU anyway, i think i will persevere with it; someone said it would work better on 'MSU normal' (i use the third setting) - will update

ps. if it comes to it i am moved to dv the filtered version straight off the screen! - i know it's cheating, but . . .



[lol]

anyway - many thanks,

[manono]

Hi-

terrypin-

I'm still vexed about why some (maybe 20-25%) of my compressions so far crash WMP 9, or give corrupted purple and green results/

I would point to this:

x:y 840x598 (1.40:1) [~38:27]

The width is Mod8 (divisible by 8) and the height is only Mod2. I'm surprised that any players can play it. For best results (compression and compatability), both width and height should be Mod16. In the example you gave, perhaps change it to 832x592. I'd bet dollars to donuts that the ones that don't play, or play with corruption, have widths and/or heights not even divisible by 8.

[terrypin]

Thanks, but does that mean the DivX specs are wrong?
Format restrictions:
Width must be a multiple of 4
Height must be a multiple of 2

Or are you saying they're just very optimistic, and should really be much tighter, i.e. both dimensions divisible by 16?

--
Terry, West Sussex, UK

[jagabo]

Thanks, but does that mean the DivX specs are wrong?
Format restrictions:
Width must be a multiple of 4
Height must be a multiple of 2

I beleive the specs are right as far as Divx is concerned. But some other software may be running into limitations along the way.

This may help you understand:

Codecs like Divx/Xvid/MPEG4 and MPEG 1 and 2 break the image into 16x16 pixel blocks. If the frame width and height aren't multiples of 16 then the codec has to use special handling for the partial blocks at the edges. This leads to greater CPU usage and can lead to problems where codecs don't agree on how to handle those edges. For example, you may be encoding with Divx, but decoding with Xvid. If Xvid's restrictions are different than Divx you might run into problems. Further, after the image is decoded it might be passed to a colorspace converter or the disply driver. Sometimes those modules also have restrictions.

[terrypin]

OK, thanks. When the next 'bad' output occurs, I'll repeat the capture with everything identical except the size. I'll try to get the source's W and H a multiple of 16 (which win't be easy!), and see if that makes the difference.

--
Terry, West Sussex, UK

[jagabo]

OK, thanks. When the next 'bad' output occurs, I'll repeat the capture with everything identical except the size. I'll try to get the source's W and H a multiple of 16 (which win't be easy!), and see if that makes the difference.

--
Terry, West Sussex, UK

I doubt that's really your problem though. I think you were just using way to low a bitrate.

Since you were arbitrarily using 780 kbps before why don't you just switch to "Quality based" encoding with Divx. Try Target Quantizers around 2 to 4. The lower the value, the higher the quality.

[manono]

I'll try to get the source's W and H a multiple of 16 (which win't be easy!), and see if that makes the difference.

The source doesn't much matter. You can always crop and resize. As jagabo said, just because DivX lets you encode at Mod2 (which it shouldn't, in my opinion), doesn't mean your player can decode Mod2.

[terrypin]

I'll try to get the source's W and H a multiple of 16 (which win't be easy!), and see if that makes the difference.

The source doesn't much matter. You can always crop and resize. As jagabo said, just because DivX lets you encode at Mod2 (which it shouldn't, in my opinion), doesn't mean your player can decode Mod2.

Thanks, but bear with me as I'm now a bit confused. jagabo said "For best results (compression and compatability), both width and height should be Mod16." I took that to mean I should ensure the source file met that requirement before opening it in VirtualDub?

--
Terry, West Sussex, UK

[manono]

I do my cropping and resizing in AviSynth, so it has been done before I open it in VDub(Mod). However, I'm pretty sure that you can do it in VDub and it'll then be correct when it's being encoded, which is the main thing.

By the way, you were quoting me. What jagabo said was, "I doubt that's really your problem though. I think you were just using way to low a bitrate. With which I disagree, as low bitrate wouldn't account for either corrupted looking video or not being able to play it at all.