aviSynth, VirtualDub & filters ...

[Morphos]

Gavino, I was wondering the same thing, thought that the function would somehow sync that. Now, I know that it is thanks to the ++ (AlignedSplice) operator, so I learned something new again

[AEN007]

6June2012

That blended image seems to me to have been created by the filmmaker.
Are blended images supposed to have been created by the Telecine procedure?
Is it even possible to tell the difference?
Only if blended frames do not seem to occur with any pattern?
If the only blended frames are "native", they are irrelevant?

It seems to me that using ForceFilm even on less than 95%-Film files is better,
because it seems that DGD does the (preliminary) IVTCine WAY faster than ViDub
(which is valuing a speedy "good enough" more than absolute perfection ...)
I really cannot (so far) discern any effects on output when playing back on my laptops ...

But forced film plus fielddeinterlace() may be acceptable if you don't mind some degradation.

Well ... as far as I know except for when using DirectStreamCopy ...
there is ALWAYS some degradation when (re)dubbing a movie.
Following the right tips & tricks can sufficiently/acceptably hide/mask/minimize the degradation,
so I appreciate what I am learning in this thread.

I am reading your DeComb manual ...

Use Fast Recompress If Possible If you are serving into VirtualDub for transcoding, and you don't need to do any filtering or other processing in VirtualDub, then use VirtualDub's Fast Recompress mode.

... and again wondering about FullProcessing versus FastRecompress.

Everything you do in AviSynth is the equivalent of full processing mode in VirtualDub.
So, if you're doing all the filtering in AviSynth, and just using VirtualDub as a front end to the Divx codec,
it doesn't matter if you select full processing mode or fast recompress mode.

The default post Telecide setting is 2.
If I am using Telecide, then %Film was too low for ForceFilm;
so this is equivalent to using ForceFilm & FieldDeinterlace(Full=False)?

I am not sure how to know if/when to use Decimate(cycle=5) as opposed to some other cycle value ...
Using FF+FD means DGD already picked/applied a Decimate cycle value & FD() cleans up leftovers?

These questions / points of interest remain.

If I (will from now on) always set/select FastRecompress,
ViDub will independently run in either FR or FullP based on its own assessment?

[Guest34343]

That blended image seems to me to have been created by the filmmaker.
Are blended images supposed to have been created by the Telecine procedure?

They are usually produced by standards conversion processes, e.g., a PAL original was converted to NTSC. They are not a result of telecine, unless someone incorrectly deinterlaced telecined content.

Is it even possible to tell the difference?
Only if blended frames do not seem to occur with any pattern?

From the pattern of blends, experienced people can often deduce the standards conversion method that was used.

If the only blended frames are "native", they are irrelevant?

Often the blending can be undone, using filters such as Srestore(). Your term "native" here is not clear.

It seems to me that using ForceFilm even on less than 95%-Film files is better,
because it seems that DGD does the (preliminary) IVTCine WAY faster than ViDub
(which is valuing a speedy "good enough" more than absolute perfection ...)
I really cannot (so far) discern any effects on output when playing back on my laptops ...

Forced Film is fast because it doesn't really do anything but ignore flags. The following FieldDeinterlace() will slow things down significantly.

There are many instances of streams whose *content* is clean 3:2 pulldown throughout but it is implemented with a mixture of hard and soft pulldown. In such cases, doing Forced Film will degrade the video while doing IVTC in your script can return fully clean original progressive frames.

Forced Film + FieldDeinterlace() is sometimes valuable when there is irregular pulldown, i.e., not clean 3:2 throughout. If you treat such a stream as pure 3:2, you will get audio sync drifting around a lot. Fortunately such streams are rare. This is a complex area to analyze, and points up again the value of providing a sample so we can teach you how to recognize it.

I am not sure how to know if/when to use Decimate(cycle=5) as opposed to some other cycle value ...

If it is clean 3:2 pulldown, then after field matching (Telecide or TFM alone) you will have 4 frames followed by a duplicate of the 4th one. So Decimate(5) is correct for clean 3:2 pulldown.

Using FF+FD means DGD already picked/applied a Decimate cycle value & FD() cleans up leftovers?

Essentially correct.

[jagabo]

That blended image seems to me to have been created by the filmmaker.

If it's in the middle of a crossfade, yes.

All your scenarios are two vague. There are many different ways that video can get to be a digital file. You should provide some concrete examples -- sample videos. Then people can give you specific advice. Otherwise we would have to write a book to address your issues.

[AEN007]

8June2012

Greetings.

I am also wondering about the relationship/interaction of/between cpu & cpu2 settings.

You use one or the other. cpu is presets for the postprocessing. cpu2 gives full control

Is there any effective difference between using cpu=6 & cpu2="xxxxxx"?
Seems to me that cpu2="xxxxxx" is around/about 25% faster than cpu=6 ...
& using cpu2="xxxxoo" (alone or with RemoveGrain) is another 25% faster than cpu2="xxxxxx"...
The "moderate_" settings are for deblocking but not for deringing?
I have read about 2 different types of deringing: "mosquito noise" & "halos from edge enhancement"
Is the DGD deringing specifically for 1 or the other?

That blended image seems to me to have been created by the filmmaker.

If the only blended frames are "native", they are irrelevant?

Often the blending can be undone, using filters such as Srestore(). Your term "native" here is not clear.

I really cannot (so far) discern any effects on output when playing back on my laptops ...

The following FieldDeinterlace() will slow things down significantly.

With "native" I mean blended images created by the filmmaker.
I don't see why they should be of any concern or undone ...

Yes, I had already noticed the hit to fps FD() makes and so have been considering skipping it ...

I am also wondering about Telecine & Interlacing. They are separate & distinct.
Telecining a film to video does not make the video interlaced, ja?
TVs use interlaced displays but non-CRT computers do not, ja?
When I watch the fully Telecined source video on my laptop,
I do not notice any degradation from the extra frames.
Of course removing them would be good to do, but I do not see/notice
any difference whether the Telecined source has had a full/proper IVTC or not ...
Doing ForceFilm makes the d2v source a 23.976 file with no a/v sync problems ...
Just wondering "aloud" in case anyone is inclined to expound in response ...

[jagabo]

Telecining a film to video does not make the video interlaced, ja?

Hard telecine will create interalced frames. Soft telecine will not, but if you perform the pulldown (honor pulldown flags in DgIndex) you will get interlaced frames.

TVs use interlaced displays but non-CRT computers do not, ja?

CRT TVs had interlaced displays. Modern LCD/Plasma TVs have progressive displays. The electronics in the TVs deinterlace on the fly.

When I watch the fully Telecined source video on my laptop,
I do not notice any degradation from the extra frames.

Because you are not looking closely enough. Find a smooth, medium speed panning shot. The repeat frames will cause an obvious jerkiness. Six little jerks per second.

[AEN007]

18June2012

... but if you perform the pulldown (honor pulldown flags in DgIndex) you will get interlaced frames.

huh?
Using the AssumeTFF/BFF method, I could see (it seems to me)
motion, motion, (what looks like no motion - therefore a repeated frame),
motion, motion, (what looks like no motion - therefore a repeated frame),
motion, motion, (what looks like no motion - therefore a repeated frame) ...
so the conclusion is supposed to be there is some kind of IVTC needed
and/but that the frames are not interlaced ... , ja?
but using DGD "honor pulldown flags" would make the d2v file of a vob "TC'd" input interlaced?

If I have to look REALLY hard/closely to see these degradations,
then I will probably never really notice them.
Like I said, I only playback these files on my laptops - maybe sometimes on an external monitor.
Usually I play MultiMedia files on PII XP "MultiMedia machine"
while I am do other work on my P4 XP laptops,
so I hear them more than I look at / see them ...

I started using DGD years ago only because
I could not ever dub mpeg1/2 files that would have proper A/V sync.
Until this thread I never knew anything that DGD could do / does.
I always used DGD to create a d2v file for mpeg1/2 input files, and
DGD was set to "honor pulldown flags".
Did that make the d2v file interlaced?
(even if the file was purely progressive with no pulldown flags?)
or not because there were no pulldown flags?

I've only recently started dubbing TC'd vob files.
I used DGD on TC'd vob files the same way I used DGD on mpeg1/2 files;
so those d2v files required deinterlacing?
so having the DivX codec set to deinterlace source was proper?
(as opposed to having the codec set to Progressive source ...)

At this point in time I don't know if I will get beyond using ForceFilm &
probably skipping the (rather slow) FD() cleanup ...

Is there any effective difference between using cpu=6 & cpu2="xxxxxx"?
Seems to me that cpu2="xxxxxx" is around/about 25% faster than cpu=6 ...
& using cpu2="xxxxoo" (alone or with RemoveGrain) is another 25% faster than cpu2="xxxxxx"...
The "moderate_" settings are for deblocking but not for deringing?
I have read about 2 different types of deringing: "mosquito noise" & "halos from edge enhancement"
Is the DGD deringing specifically for 1 or the other?

That blended image seems to me to have been created by the filmmaker.

If the only blended frames are "native", they are irrelevant?

Often the blending can be undone, using filters such as Srestore(). Your term "native" here is not clear.

With "native" I mean blended images created by the filmmaker.
I don't see why they should be of any concern or undone ...

[manono]

... but if you perform the pulldown (honor pulldown flags in DgIndex) you will get interlaced frames.

huh?

'huh?' what? Using Honor Pulldown Flags on an NTSC DVD you always get interlaced frames (always for film sources anyway). If it is sourced from film and either soft telecined (telecine added with the TFF/RFF flags) or hard telecined (the telecine encoded into the video), by using Honor Pulldown Flags, you get interlaced frames - 3 progressive and 2 interlaced in every 5 frame cycle.

What you described is completely wrong. You described abb cdd eff, which you'll never see, except possible for a 20fps silent film with frame dupes for NTSC DVD.

Now maybe you meant to separate the fields as neuron2 described. In that case you'll get aabbb ccddd eefff, still very different from what you described.

DGD was set to "honor pulldown flags".
Did that make the d2v file interlaced?

Yes, although it may have been interlaced to begin with.

so having the DivX codec set to deinterlace source was proper?

No, never for film sources. You don't deinterlace films. You might IVTC them, but never deinterlace. And if you deinterlace anything ever, I certainly wouldn't do it with the DivX deinterlacer, but a better AviSynth deinterlacer.

[jagabo]

Here's what you're not understanding:

Analog NTSC video is transmitted and stored as 59.94 fields per second. When you watch it on an interlaced display that's what you see, 59.94 fields per second. You never see an entire frame. By the time a field is being drawn on the TV the previous field has faded away. The broadcast always alternates between even (top) and odd (bottom) fields. From a video camera every field may be unique. 59.94 half pictures taken an 1/59.94 second intervals. 59.94 fields per second is the only thing standard definition TVs knew how to display.

When analog video is captured and digitized it is stored as frames, two fields per frame, because they are complimentary -- one field is all the even scanlines, one all the odd scanlines. If nothing is moving in a frame the two fields comprise a full picture. If anything moved you will see comb artifacts. The result is 29.97 frames per second interlaced digital frames. When this is broadcast, the two fields are peeled apart and sent one field at a time -- once again you have 59.94 fields per second analog video.

When film is broadcast on TV it must be converted from 24 frames per second to 59.94 fields per second. This is done by slowing the film down to 23.976 frames per second then "pulling down" fields. One frame is displayed for the duration of 3 fields, the next for 2 fields, the next for 3, the next for 2, etc. So this is called 3:2 (or 2:3) pulldown. So, on average, film frames are displayed for 2.5 fields, 23.976 * 2.5 = 59.94.

Video can be stored on DVDs in two basic ways: 29.97 interlaced frames per second, or 23.976 progressive frames per second along with instructions (called pulldown flags) that tell the DVD player how to output 59.94 fields per second. (Actually, pulldown flags are flexible enough that the progressive frame rate can be anywhere from 19.98 fps to 29.97 fps, but the final output will always be 59.94 fields per second. For example, 25 fps PAL sources can be stored as 25 fps progressive frames with 3:2:3:2:2 pulldown flags).

In DgIndex, when you use "ignore pulldown flags" you are telling the program to ignore the pulldown flags on the DVD and just output frames as they are stored. If they are stored as 23.976 progressive fps you get nice 23.976 progressive frames ready for filtering/encoding. Unfortunately, many DVDs have a mix of progressive with pulldown (sometimes even different frame rates with pulldown), and interlaced frames. So this will often result in loss of sync between the audio and video.

When you select "honor pulldown flags" you're telling the program to perform the pulldown and weave pairs of fields together into interlaced frames. The benefit of this is the output is always 29.97 interlaced frame per second (59.94 fields per second) so you don't get audio/video de-sync, even if the DVD is a mix of frame rates and progress and interlaced frames. But then you either need to filter/encode as interlaced video or perform an inverse telecine back to 23.976 progressive frames per second.

[AEN007]

30October2013

I haven't done any VideoDubbing at all since summer 2012 ...
at that time I was totally exasperated with the never-ending MORASS this is ...

Every time I leave & come back to "VDing", I have to relearn what I used to know ...
Eventually "it will all come back to me ..."
Anyway, I'm starting by VDing avi/flv/mp4 files with aviSynth & VirtualDub.
(I don't remember off the top of my head how to use DGDecode ...
and so am not doing VOB/mPEG files ... yet ...)

My avs file is like the following>

DirectShowSource("¿¶1o2.mp4", fps=25.0)
DeBlock_QED(quant1=60, quant2=60, aOff1=60, bOff1=60, aOff2=60, bOff2=60, uv=-1)
Crop(6,34,-6,-34).BilinearResize(320,240)

My VirtualDub video settings are ...
Full Processing Mode (Does it ever/really matter whether I set this to Fast Recompres)
Convert to FPS 23.976 (fewer frames means smaller output file size, va?)
Video Color Depth: Decompression~Autoselect Output~4:2:2YCbCr(YUY2) (because I once read somewhere
that someone found that this yielded the smallest file output size without degradation ...
I have no idea what I should choose here nor why ...)

Any helpful replies/insights appreciated ...

[sanlyn]

I pass.

[manono]

Full Processing Mode (Does it ever/really matter whether I set this to Fast Recompres)

Yes, it matters. Whenever possible do all your filtering in AviSynth and use Fast Recompress.

Convert to FPS 23.976 (fewer frames means smaller output file size, va?)

Doesn't that drop a frame every second? Is that what you want - a jerky playing video? No, leave the framerate alone.

[AEN007]

30October2013

Changing the fps does not make my output results jerky ... that should go without saying ...

What does result in jerky results is posting a forum question answered by flaming faggots.

1)If I do filtering only via mpeg2Source & use some DeComb feature, could/should I use FR?

It doesn't matter if you use Fast Recompress or Full Processing mode.

When VirtualDub sees you're not filtering it will use Fast Recompress mode
even if you have Full Processing mode selected. As long as you don't force a colorspace via Video -> Color Depth.

According to this post, it doesn't matter if I set ViDub to FastR or FullP.
Thanks anyway.

[AEN007]

30October2013
For some (unknown) reason using the following»

DeBlock_QED(quant1=60, quant2=60, aOff1=60, bOff1=60, aOff2=60, bOff2=60, uv=-1)
Crop(6,34,-6,-34).BilinearResize(320,240)

on an avi file gives me a decent output processing rate of around 15fps; however,
using that (or ANY deblocking @ all) on an mp4 file is (so far) ALWAYS resulting in around 5fps ...
Should deblocking on mp4 rather than on avi do that?

Any helpful replies/insights appreciated ...

[manono]

When VirtualDub sees you're not filtering it will use Fast Recompress mode

Correct me if I'm wrong, but aren't you filtering in VDub? Yes, maybe this 'Convert To FPS' doesn't require a colorspace change. Anyway, I read jagabo's response you quoted very differently, since you're also forcing a colorspace change. Maybe he'll see this and correct me.

Changing the fps does not make my output results jerky

But it does. You're removing one unique frame every second. Check the framecount before and after. It can't help but play jerky - one slight stutter every second.

[jagabo]

If you aren't filtering in VirtualDub, and Video -> Color Depth -> Decompression Format is set to Autoselect, and Video -> Color Depth -> Ouput Format is set to Same As Decompression Format, then Full Processing mode is the same as Fast Recompress mode when importing AviSynth scripts Some filters work in YUV formats (Brightness/Contrast for example). If you only use those filters, and the source is YUV, there will be no colorspace conversion when AviSynth scripts are used as inputs.

VirtualDub's frame rate conversions can be performed without colorspace conversions when importing AviSynth scripts (and not filtering otherwise in VirtualDub). But you might as well do the conversion in AviSynth in that case.

[AEN007]

31October2013

So ... if I use RemoveGrain instead of DeBlock or SmoothD2 on mp4 files,
ViDub has a decent/acceptable output processing FPS ...

I would like to try the Kassandro "Repair" plugin, however, cannot find nor figure out
what the avs Repair syntax is ... Someone posted a similar question in a Doom9 forum»



however the replies were all scientific mumbo jumbo
instead of just giving an example of proper avs Repair syntax.

I've previously commented on my VideoDubbing. I've been ViDubbing since around 2006.
I'm still "not doing it properly"; however, my outputs are (of course)
acceptable to the naked eye on my laptops. My outputs are not jerky.
The output difference between 29.97/25/23.967 is imperceptible to the naked eye ... whatever ...

My goal has been / remains visually acceptable output on my laptop(s) at the smallest total mB possible.
I of course am interested in doing the proper way as many things as possible ...

I find that de-blocking/graining improves the output quality @ any bitrate,
so I can lower my video output bitrate even lower than 507 & have even better quality
than before when I didn't know about / didn't use deblocking ...

What is the avs Repair syntax?

DirectShowSource("¿.mp4", fps=25.0)
RemoveGrain(mode=18).RemoveGrain(mode=18)
Repair?
Crop(6,34,-6,-34).BilinearResize(320,240)

Any helpful replies/insights appreciated ...

[jagabo]

What is the avs Repair syntax?

source=DirectShowSource("¿.mp4", fps=25.0)
filtered=source.RemoveGrain(mode=18).RemoveGrain(mode=18)
Repair(filtered, source, mode=16)
Crop(6,34,-6,-34).BilinearResize(320,240)

[AEN007]

31October2013

Thanks!

[AEN007]

Here's an example of my output ... from 2009 ... when I 1st joined VidHelp ...
(and knew even less aboud ViDubbing than I do today)
http://youtu.be/WhjSJs1XVpg
This vid has of course been through the YT conversion degradation ...

btw ... When I 1st joined VidHelp I started the following thread ...
It is amazing what I have been able to make that PII laptop of mine from 1998 do!
... and today it is still playing mp3s/avis/screensavers 24 hours a day for me ...
often running on autopilot through AutoHotKey scripts of mine ...

[AEN007]

5November2013

I have some (more) questions (of course) ...

1st Question ...
Regarding Fast Recompress vs Full Processing ...
If I set ViDub to FastRe, will ViDub actually use FastRe (or FullP) ...
... If I use an avs script with ...
a. RemoveGrain/Repair?
b. DeBlock_QED?
c. SmoothD2?

sub-question: Regarding the "ColorSpace requirement/restriction" of a. & b.
(as far as I can tell c. has NO "Co/Sp r/r") ...

Since/If c. has NO "Co/Sp r/r", does this mean that c. ...
... can (always) be used without setting the ColorSpace &
therefore can be (always) used with FastRe?

What should/would ViDub do if an avs script calls a. or b. and
no Co/Sp has been set?
i.e., ViDub was set to use FastRe? Would/Will ViDub auto-set the required Co/Sp & use FullP?

2nd Question ...
As I previously posted, I have to use a. NOT b. or c. when I "do" mp4 files;
however, I can use any 1 of those 3 when I do avi files ...
Which should/would be better?
a. RemoveGrain(mode=18).RemoveGrain(mode=18) & Repair(filtered, source, mode=16)
b. DeBlock_QED(quant1=60, quant2=60, aOff1=60, bOff1=60, aOff2=60, bOff2=60, uv=-1)
c. SmoothD2(quant=13, num_shift=1)
The ViDub output FPS on avi files is about exactly the same for all 3 three of those.

sub-question ... Why is there no difference in ViDub's output FPS
whether I use the above or
DeBlock_QED(quant1=20, quant2=24, aOff1=2, bOff1=4, aOff2=4, bOff2=8)?
There is extreme variation in ViDub's output FPS when I varying SmoothD2 settings.

[jagabo]

AviSynth delivers fully processed, uncompressed frames to VirtualDub. VirtualDub has no idea what happened in the AviSynth script.

[AEN007]

5November2013
Hallo ... & thanks (again) ...
Does the preceding post mean that it is IMPOSSIBLE to use FastRe
when using an avs script? i.e.,
using FastRe on fully processed, uncompressed frames is pointless?

What about any of my other questions in my preceding post?

[sanlyn]

5November2013
Hallo ... & thanks (again) ...
Does the preceding post mean that it is IMPOSSIBLE to use FastRe
when using an avs script? i.e.,
using FastRe on fully processed, uncompressed frames is pointless?

What about any of my other questions in my preceding post?

Avisynth and VirtualDub are two different programs. If you like you can stream Avisynth output to another app entirely. For instance, you can run Avisynth scripts in Adobe Premiere Pro or After Effects. Whatever Adobe does to Avisynth's output depends on what you tell Adobe to do with it. They are two different processes. Avisynth does one thing, while the app that takes in Avisynth's output does whatever you tell that app to do with it.

Direct Stream Copy - This will take the input video and copy it exactly, as-is, to an output file and location. It's often used for extracting (cutting) sections of avi files while making no change to the incoming video stream.

Fast recompress - Takes the input video and sends it to the Compressor without doing any conversions or running any VirtualDub filters. Sends AVisynth's output straight to the compressor.

Normal recompress - This converts the incoming stream to RGB and then sends it to the compressor. If you want to avoid colorspace changes, don't use this.

Full processing mode - This converts the footage to RGB, applies any internal VirtualDub-style filters, and sends the video to the compressor as RGB. What your compressor does with it depends on what you tell your compressor to do. If you use this mode and you do not load any VirtualDub filters, the video stream still gets converted to RGB. In any case, if you don't tell your compressor to do anything with VirtualDub's output, you'll get uncompressed RGB.

http://www.animemusicvideos.org/guides/avtech/amvappvdubmod.html

[AEN007]

6November2013
Greetings ... and thanks ... and thanks for indulging my ignorance ...
(Believe it or not ... I did know that aviSynth is its own program.
I have served aviSynth scripts into various other programs.)

Anwyay ...
It is "preferable" to use FastRe rather than FullP when possible?

Having to specify a ColorSpace (for example to use RemoveGrain or DeBlock_QED)
means that using FastRe is not possible with such filters?

Because SmoothD2 (seemingly?) does not require specifying a ColorSpace,
it is possible (and thus maybe preferable) to use FastRe with SmoothD2 ?

btw ... regarding previous posts on this page ...
I never said (or meant to imply anyway) that I thought ViDub required
specifying a ColorSpace to do FPS conversions!

[jagabo]

(VirtualDub)Full processing mode - This converts the footage to RGB, applies any internal VirtualDub-style filters, and sends the video to the compressor as RGB. What your compressor does with it depends on what you tell your compressor to do. If you use this mode and you do not load any VirtualDub filters, the video stream still gets converted to RGB.

That last part is outdated. For the last few years VirtualDub will not convert incoming YUV to RGB if you don't add filters that require RGB. Or if you specify an RGB colorspace in Video -> Color Depth. For example, open an AviSynth script that outputs YV12 and save it while in Full Processing Mode without applying any filters. You will get an uncompressed YV12 AVI, not RGB. The same thing that happens in Fast Recompress mode. There will be no loss of super black and super brights.

[jagabo]

It is "preferable" to use FastRe rather than FullP when possible?

If you're not using any filters in VirtualDub it doesn't matter which you use. But it certainly doesn't hurt to use Fast Recompress.

Having to specify a ColorSpace (for example to use RemoveGrain or DeBlock_QED)
means that using FastRe is not possible with such filters?

What happens in AviSynth has no bearing on VirtualDub's handling as regards Fast Recompress or Full Processing mode, when not filtering in VirtualDub.

Within AviSynth itself it is best to perform as few colorspace changes as possible. As most colorspace changes will cause some blurring of the colors. But often the benefits of using a filter that requires a colorspace change outweigh the losses.

[sanlyn]

(VirtualDub)Full processing mode - This converts the footage to RGB, applies any internal VirtualDub-style filters, and sends the video to the compressor as RGB. What your compressor does with it depends on what you tell your compressor to do. If you use this mode and you do not load any VirtualDub filters, the video stream still gets converted to RGB.

That last part is outdated. For the last few years VirtualDub will not convert incoming YUV to RGB if you don't add filters that require RGB. Or if you specify an RGB colorspace in Video -> Color Depth. For example, open an AviSynth script that outputs YV12 and save it while in Full Processing Mode without applying any filters. You will get an uncompressed YV12 AVI, not RGB. The same thing that happens in Fast Recompress mode. There will be no loss of super black and super brights.

I have 5 copies of VirtualDub 1.9.11 Build 32842 that default to RGB24 color depth output and uncompressed RGB. I often change those settings, but I never saved the changes as the defaults, which you said you had done some time ago. I would advise checking those defaults in full processing mode. We have a lot of newbies who post YV12/YUY2 sample captures that were cut in VirtualDub and posted as RGB videos -- and the users didn't even know that the color depth and compression menus exist until it was explained to them.

[jagabo]

I just checked (ran VirtualDub on a fresh XP install) and you are right. I thought the default Color Depth settings were this:



But it turns out the defaults are:



So indeed, if you've never set the Color Depth settings, Full Processing Mode will result in conversion to RGB.

[sanlyn]

That's what I thought. I just change them as I need to, but never clicked "Save as default". I suppose it depends on what's most convenient, but even then I have a habit of checking those settings anyway. Pain in the neck.