aviSynth, VirtualDub & filters ...

[AEN007]

25May2012

I have numerous questions about using
aviSynth (avs), VirtualDub (ViDub) & filters to convert/redub movies.

Using ViDub with filters & without avs requires Full Processing Mode (FPM).
Using ViDub without filters & with avs allows using Fast Recompress (FR).
It recently came to my attention that one can use filters with avs.
Some filters (like from MSU) are ready made for use with avs.
Other filters require special avs function scripting.

In any case ..
Should/Must I use FPM when I use filters via avs?
or can I still use FR even when I use filters via avs?

I also use the DivX codec and its multipass functionality.
Is it necessary/recommended to use the filters on both passes
or is it enough to use the filters on only the 2nd/final pass?

What about setting ViDub to use FR on the 1st pass
and then setting ViDub to use FPM on the 2nd/final pass?

Any helpful replies/insights appreciated.
Thank you.
Regards,
AEN
Æ

[jagabo]

Everything you do in AviSynth is the equivalent of full processing mode in VirtualDub. The difference between using AviSynth filtering and VirtualDub filtering is colorspace conversion. VirtualDub filters work in RGB (slower, loss of accuracy, loss of extreme darks and brights), AviSynth can work in video's native YUY2 or YV12. If you want to use VirtualDub filters in AviSynth, LoadVirtualDubPlugin(), you have to convert the video to RGB for the plugin.

VirtualDub is pretty smart now. If you don't add any filters to its filter chain it doesn't perform the conversion to RGB, even in you're in full processing mode. 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.

You want to use the same filters in both passes of a 2-pass conversion. During the first pass the codec is examining each frame to see how compressible it is. During the second pass it uses that information to decide how much bitrate to allow each frame/scene. If the video is different between the two passes you won't get accurate results.

[AEN007]

30May2012

Greetings.
Thanks for the reply.
I've spent some more time on the internet on these issues.

It seems (to me) that some filters (deblocking/denoise)
work in RGB but that some filters (deblocking/denoise) work in YU or YV ...

The MSU filter documentation, for example, says use ConvertToRGB32;
however, the DeBlock documentation requires YV12 or YUY2.

The SmartSmoothHiQ documentation says use ConvertToRGB32,
but the MipSmooth documentation says,

requirements: YV12 & YUY2 & RGB Colorspace

So ... using DeBlock & MipSmooth instead of MSUDeB & SmSmHiQ
means it is NOT necessary to use ConvertToRGB32 in avs?

What happens if the source video colorspace is YUV and I use»

LoadPlugin("DGDecode.dll")
LoadPlugin("MipSmooth.dll")
clip=mpeg2Source("VoBfile.d2v")
clip.MipSmooth().DeBlock().Crop(8,0,-8,0).BilinearResize(320,240)

?

What colorspace does ViDub use?
What is the best/proper order of the filter chain?
Should Crop.Resize be last?
Should DeBlock be last?

The DivX codec can be set to Progressive, Preserve Interlace or DeInterlace.
If I set the DivX codec to DeInterlace when the source is Interlaced,
then ConvertToRGB32(interlaced=true) is NOT necessary?
The "(interlaced=true)" would only be necessary if I used Preserve Intelace?

[manono]

Your colorspace is VY12.
With that script and those filters deblock first (DeBlock_QED is a better filter for that). Unless a deinterlace or IVTC is called for. Then I'll do that first.
Deinterlace (or IVTC) in AviSynth and not in the DivX codec.
In that script I'd crop and resize last.
You don't want to encode DivX as interlaced. And if you do, you can't simply resize it to 320x240 without wrecking it.
You can lose that 'clip' stuff:

LoadPlugin("DGDecode.dll") 
LoadPlugin("MipSmooth.dll")
mpeg2Source("VoBfile.d2v")
MipSmooth()
DeBlock()
Crop(8,0,-8,0)
BilinearResize(320,240)

[jagabo]

Deblock() should probably come before MipSmooth(). Note that Mpeg2Source() has deblocking (and deringing) features but it tends to be too strong. Deblocking works by examining 8x8 blocks, relative to the top left corner, so you don't want to crop or resize (or otherwise disturb the video) before deblocking. For speed you might try putting MipSmooth() after cropping and resizing. Sometimes you just have to experiment with filter order and find what works.

[manono]

Oh yeah, I wrote to use deblock first, and then in the sample script I left it the way it was. Sorry. And thanks for pointing it out.

[AEN007]

31May2012

Greetings.

Is it "better" to use plugins that do not require ConvertToRGB32?

Deinterlace (or IVTC) in AviSynth and not in the DivX codec.

How? With what? I've always used the DivX codec "DeInterlace" setting. What about»

LoadPlugin("SmoothDeinterlacer.dll")
AVISource("Test.avi")
SmoothDeInterlace()

?If I would use SmoothDeInterlace, then I would set the DivX codec to "Preserve Interlace"?
I would do deinterlacing before anything else? even deblocking?
I'll also have to compare the effect on dubbing speed ...

I have read (here & elsewhere) that deblocking (& denoising) should come before cropping -
but ... it seems to that if I am just cropping off "letterbox" black edges,
then it is OK/better to do cropping first.
Why do filters need to work on black borders that won't even be in the final video?
I don't care if the denoiser doesn't properly denoise the borders as a result ...

For speed you might try putting MipSmooth() after cropping and resizing.

There are many "denoisers". Many/Most of them are TOO slow - relatively & absolutely speaking.
Using them (on my PIV XP laptops) made ViDub need 4-5 times the length of the video to do 1 pass;
however, I tried RemoveGrain() - which seems to be both fast & effective.
RemoveGrain requires different parameters for interlaced & progressive sources.
If I do SmoothDeIntelace() first / before RemoveGrain,
then I could/should set RemoveGrain for a progressive source?

Note that Mpeg2Source() has deblocking (and deringing) features
but it tends to be too strong.

I am glad to see that explicitly stated!
I wasn't sure what I was reading elsewhere about mpeg2dec & DGDecode ...
So I can skip deblocking all together & just do RemoveGrain() when doing d2v input ...

(DeBlock_QED is a better filter for that).

QED seems (to me) a bit "involved" to setup/use.
I found/tried UnBlock.
I then tried the generic DeBlock instead of UnBlock.
DeBlock was significantly faster & seemingly sufficiently effective.
Right now (without having yet tried some other DeInterlacing)
ViDub needs around twice the length of the video to do one pass.

So either resizing or denoising should come last?

MediaInfo (seemingly always) says the source video color space is YUV and
the output video color space is YUV ...

[manono]

How? With what? I've always used the DivX codec "DeInterlace" setting.

There are a zillion AviSynth deinterlacers. Yadif is about the fastest decent one. But the better the deinterlacer, the slower the encoding. Once deinterlaced the video is then progressive. Set it to that when setting up the DivX Codec.

...then it is OK/better to do cropping first.

I'd deblock before cropping. And before about anything else, except for an IVTC.

Why do filters need to work on black borders that won't even be in the final video?

Deblocking doesn't need to work on the black borders, but it does work on 8x8 blocks which will get disturbed if you crop first.

Using them (on my PIV XP laptops) made ViDub need 4-5 times the length of the video to do 1 pass;

Just as deinterlacers come in all speeds and qualities, so do denoisers come slow and fast, good and not so good.

If I do SmoothDeIntelace() first / before RemoveGrain,
then I could/should set RemoveGrain for a progressive source?

In general, if the source is made progressive first one way or another, then you don't have to worry about figuring out how to set up your filters for an interlaced mode. Just remember, if it's a movie, by definition it's not interlaced. If you see interlacing, something else is at work (and it should be IVTC'd, or unblended, or the fields realigned, or something). If PAL, it may have been encoded as interlaced, but the content is progressive. If you don't see any interlacing, it's not interlaced. Deinterlacing a progressive source is very bad.

QED seems (to me) a bit "involved" to setup/use.

It's worth it. Deblock_QED only deblocks when the picture is blocky. The others deblock everything. Deblocking of necessity softens the picture somewhat, so if a frame or part of the video doesn't need deblocking, the resulting quality is better.

[jagabo]

Deblocking works by looking at the edges and corners of 8x8 blocks, starting at the top left corner. If you crop before deblocking you have to crop the top and left edges by integer multiples of 8. Otherwise the deblocker will be looking in the wrong places. The blocks in the image will no longer be aligned with where the deblocker is looking.

[AEN007]

31May2012

Greetings.

Is it "better" to use plugins that do not require ConvertToRGB32?

I am trying to achieve acceptable output quality
at an acceptable dub speed at the minimum possible file size.
This seems doable with high bitrate sources (vob files & etc), but
"cleaning up" (relatively) low bitrate, blocky/quilty YouTube mp4/flv downloads is still the challenge ...

MediaInfo says every .vob file I have encountered has been interlaced.
I have no idea what an IVTC is. I'll have to deal with this later.

OK ... I'll crop after DeBlocking ...

I can find no DeBlock_QED "setup" guidance.
I need DeBlock, MaskTools2 & DCTFilter.
I presume I have downloaded these.

I presume I should put DeBlock.dll & DctFilter.dll in a "PATH" location with other avs plugins.
What MaskTools2 stuff goes where?

Am I supposd to copy the QED function into every avs script?
and then use

DeBlock_QED()

?
Do I need to specify any LoadPlugin commands?

[poisondeathray]

3


MediaInfo says every .vob file I have encountered has been interlaced.
I have no idea what an IVTC is. I'll have to deal with this later.

OK ... I'll crop after DeBlocking ...

Mediainfo doesn't report what the actual contents are, only how the file has been encoded. "Content" and "method of encoding" can be entirely different. It doesn't scan the file, only reads the file header , so it can be mistaken as well

IVTC = inverse telecine . 24p content is stored in 59.94i format for NTSC DVD using pulldown. You have to remove pulldown (also called inverse telecine) to recover the original 24p content

I can find no DeBlock_QED "setup" guidance.
I need DeBlock, MaskTools2 & DCTFilter.
I presume I have downloaded these.

I presume I should put DeBlock.dll & DctFilter.dll in a "PATH" location with other avs plugins.
What MaskTools2 stuff goes where?

Am I supposd to copy the QED function into every avs script?
and then use

DeBlock_QED()

?
Do I need to specify any LoadPlugin commands?

You can find the avs here, with short description of the parameters.
http://avisynth.org/mediawiki/Deblock_QED

Either copy the .avs contents to each script, or use Import("PATH\DeBlock_QED.avs") , or rename it to .avsi and place in the plugins folder to autoload

Most .dll's placed in the plugins folder will autoload, but a few need Load_Stdcall_Plugin . most .avs function scripts renamed to .avsi extenions will autoload when placed into plugins folder

[manono]

MediaInfo says every .vob file I have encountered has been interlaced.
I have no idea what an IVTC is. I'll have to deal with this later.

That's what I figured. You're in PAL land and are assuming your source is interlaced and needs deinterlacing just because MediaInfo says it was encoded as interlaced. Use your eyes. Open a script without a deinterlacer applied in VDub or some such. Scroll to a place with movement and advance a frame at a time. If you don't see interlacing, don't deinterlace. Movies on PAL DVD don't need deinterlacing and doing so greatly damages the video (besides slowing the encoding). If there is interlacing visible, most of the time it needs unblending or the fields realigned. If you ever see a PAL DVD movie with interlacing, post a small 10 second sample here so we can have a look and advise how best to treat it.

Unless you work sometimes with NTSC DVDs, you won't have to worry about IVTC.

[jagabo]

Is it "better" to use plugins that do not require ConvertToRGB32?

It's best to avoid unnecessary colorspace conversions. But if you have to use a filter that only works in RGB you can't avoid the conversion. Except in the case of super blacks and super brights the losses from a few YUV<-> RGB conversions aren't large. So it's not catastrophic if you have to convert once or twice. Try it for yourself, convert from YUV to RGB then back several times in a row and see what effect it has on the image quality. Mostly what you'll see is a slight blurring of colors. And some posterization in smooth gradients.

[AEN007]

31May2012
Greetings.
These questions/issues remain ...

Is it "better" to use plugins that do not require ConvertToRGB32?

"cleaning up" (relatively) low bitrate, blocky/quilty YouTube mp4/flv downloads is still the challenge ...

What MaskTools2 stuff goes where?

Please reply/advise.

I've always considered "eyeballing" a video for interlacing a dismal proposition
and have never wanted to do it. I've always preferred to have MI or TMPEGenc tell me this info.
Concert videos usually have a very black/dark environment & not much pronounced movement ...
I am "from" the Western Hemisphere & so encounter both NTSC & PAL.
I'll have to deal with this somehow ...
What if I just skip deinterlacing AND skip IVTC?

... place in the plugins folder to autoload
Most .dll's placed in the plugins folder will autoload

I read somewhere that these avisynth plugin.dlls should go in sys32 or some "PATH" location.
DGDecode.dll would never autoload no matter where I put it.
I finally put it in a PATH location, so I could call it without specifying a path ...
Does "plugins folder" refer to the avisynth plugins folder?
Any dlls that do not autoload from the "plugins folder" will generate an error, ja?

What MaskTools2 stuff goes where?

[jagabo]

AviSynth plugins can go anywhere you want. If you put them in AviSynth's plugins folder they will automatically be loaded anytime AviSynth is used. If you put them elsewhere you have to import them with commands like:

LoadPlugin("C:\folder\aWarpSharp2.dll")
import("C:\folder\TempGaussMC_beta1.avs")

There are a few filters that require a special format no matter where they're located:

 Load_Stdcall_plugin("C:\Program Files (x86)\AviSynth 2.5\plugins\yadif.dll")

Then a few filters require some general dll libraries that are usually put in C:\Windows\System32 (or SysWoW64). For example fftw3.dll.

[jagabo]

I've always considered "eyeballing" a video for interlacing a dismal proposition
and have never wanted to do it.

It's the only reliable method. Just open your video in VirtualDub and find a section where there is some movement. Use a screen magnifier (or VirtualDub's zoom function) if necessary.

[Guest34343]

DGDecode.dll will indeed properly autoload if you place it in the Avisynth plugins directory.

[Gavino]

most .avs function scripts renamed to .avsi extenions will autoload when placed into plugins folder

They all should - are you aware of any that don't?

What MaskTools2 stuff goes where?

Put mt_masktools-25.dll in your plugins folder (unless you are using Avisynth 2.60, in which case use mt_masktools-26.dll instead).

The other files are source files, etc, and aren't needed as such, though you might find it useful to read the documentation (mt_masktools.html) once you gain more experience.

[AEN007]

1June2012

Greetings.

DGDecode.dll will indeed properly autoload if you place it in the Avisynth plugins directory.

I started using DGDecode 3 years ago. The following DGD guidance is INCORRECT»

AviSynth's LoadPlugin() must be called before any DGDecode functions can be used.
To accomplish this, add the following line to the beginning of your AviSynth (*.avs) script:
LoadPlugin("[PATH\]DGDecode.dll")
Note: PATH can be ignored if DGDecode.dll is in the default AviSynth plug-in directory,
otherwise PATH must be specified.

1)PATH can only be ignored IF the avs plugin DIR is a PATH DIR.
I put DGD.dll in the avs pin DIR & tried LoadPlugin("DGD.dll") - which yields an error message.
2) Anyway, it turns out that if DGD.dll is in the avs pin DIR, LoadPlugin does not need to called ...

Note that Mpeg2Source() has deblocking (and deringing) features but it tends to be too strong.

It seems (after looking at DGD this morning) that the deblocking is OFF by default,
so it seems I (would) have to specify some cpu & cpu2 parameters ...
but I should just go ahead and (now that I have QED set up ... THANKS!) use DeBlock_QED, ja?

This video dubbing is a never-ending morass ...

[Guest34343]

I've corrected the documentation and updated it on my website. I have also asked Hank to update the binary package available at his site. Thank you for pointing out the error.

It's preferable to use the built-in deblocking as it has access to quant values in the encoded stream.

[AEN007]

It's preferable to use the built-in deblocking
as it has access to quant values in the encoded stream.

OK ...

what kind of cpu / cpu2 parameters should I specify?
Source files seemingly have either sporadic/light or omnipresent/heavy blocky/quilting ...

It seems to me there are 2 types of blocky/quilting to address»
1) that which is already in the source video &
2) that which is (would be) generated by the dubbing.
The Deblocking filters I have tried so far seem effective against #2 only ...
I have been trying out denoisers/smoothers against #1 ...
It would be great to find something effective against both 1 & 2 ...

Is(Will) there (ever be) something like a d2v file for non mpeg2source files?
Does BlindPP use DGDecode deblocking on non mpeg2source files?

[Guest34343]

I won't advise you on practical matters for deblocking as I do not make rips and never even attempted to solve any blocking problems. The people here can help you much better.

Is(Will) there (ever be) something like a d2v file for non mpeg2source files?

Yes, there is DGDecNV that supports MPEG2, AVC, and VC1. The forum gives you an incorrect link for that tool (links to DGAVCDec, which is withdrawn and should not be hosted here as it is done without my permission and requests for its removal have been ignored by the forum staff), so I give the correct one:

http://neuron2.net/dgdecnv/dgdecnv.html

DoesBlindPP use DGDecode deblocking on non mpeg2source files?

No. It is a standalone filter that uses its own algorithms. That is why it is called "blind"; it has no access to any data in the encoded stream, such as quants.

[jagabo]

It seems to me there are 2 types of blocky/quilting to address»
1) that which is already in the source video &
2) that which is (would be) generated by the dubbing.
The Deblocking filters I have tried so far seem effective against #2 only ...

No, it's the other way around. Deblocking filters can only remove blocks from the source video. If you then save that deblocked video with too little bitrate you will create new block artifacts. In that case use more bitrate.

Even though Mpeg2Source() has access to the quantizers used in the source video (so it theoretically has more information to work with) it performs too much smoothing. In my opinion, Deblock_QED() does a better job. Compare for yourself.

[AEN007]

The following just occurred to me ...
The DGD log file specifies

Frame Type: Interlaced

Is this determination correct?
Does the video file need deinterlacing?

Does DGDecNV make such a determination?

[AEN007]

No, it's the other way around...

OK ... well my experience recently has been»
1) using a deblocker has allowed me to use a lower bitrate than without using a deblocker;
2) No deblocker has been effective against low bitrate blocky/quilty mp4/flv YouTube downloads
but denoisers/smoothers (SmSmHiQ/RemoveGrain ...) have been (somewhat) ...

[themaster1]

Deblock_qed is the best for me and if it's not enough use a denoiser fft3d or nlmeans the gpu versions works great for me

To check if the filter(s) does a good job or not add this at the and of your script to analyse yuv

Y = GreyScale()
U = UtoY()
V = VtoY()
StackHorizontal(Y, StackVertical(U,V))

Also (remove the previous code ):
Histogram(mode="luma")

[jagabo]

1) using a deblocker has allowed me to use a lower bitrate than without using a deblocker;

Deblocking replaces blocks (easily compressed) with smooth gradients (difficult to compress) so deblocked video requires more bitrate, not less.

Actually, the real world situation is more complicated. It depends on how much noise is in the video, whether you're cropping or resizing, any other filtering you may be doing, what codec and bitrate you're using, etc.

[Guest34343]

The following just occurred to me ...
The DGD log file specifies

Frame Type: Interlaced

Is this determination correct?
Does the video file need deinterlacing?

Does DGDecNV make such a determination?

DGDecNV reports what is specified in the stream. It is not reliable for determining if the stream content is actually interlaced, because one can encode progressive content as interlaced (and vice versa). It's pretty common to see it in practice. You have to use your eyes for a reliable determination.

The first two questions here tell you how to use your eyes:

http://neuron2.net/faq.html

[AEN007]

2June2012

Greetings.

I am using an mp4 YT download with 480x360 dims for testing how to cleanup YT downloads.
It seems I cannot use BlindPP()»

Need mod16 height

Is there any work around? other than resizing to 320x240 before deblocking?
Maybe letterbox it somehow? I've not yet ever tried that ...

Also ... is it better to use the Groucho2004 SSE optimized DGD build on my PIV XP laptops?

[AEN007]

The first two questions here tell you how to use your eyes:http://neuron2.net/faq.html

Applying the steps in FAQ#2 to a vob file seems to indicate TFF.
(This procedure is sure BETTER than just eyeballing it!)
So this vob file is NOT progressive, ja?
It might be purely interlaced or (probably) 3:2 pulled-down progressive?
What exactly does "see any blended pictures" mean?

I'm not sure I can correctly distinguish between abcdef & aaabbcccdd.
I'm guessing that I am seeing a 3:2 video.
If the video is not interlaced & not purely progressive, what else might it be?
3:2 or ?

I have (so far) no (proper) IVTC/deinterlace experience.
If this is a 3:2 video, what if I do not deinterlace & just ignore the IVTC?
What would be the difference in output between applying/ignoring the IVTC?
I could/would set the DivX codec to progressive source in either case?
(I wonder what the DivX codec actually does
when deinterlace is selected and there is no true interlacing in the video ...?)

How would/should I approach applying an IVTC?