An all-purpose DVD script

[jstelly]

If you had to write an all-purpose script to read the video ripped from DVD Decrypter and extracted with DGIndex, what would it look like? My goal is to have one script that lets me convert any DVD source to progressive output for XviD with as little loss of quality as possible.

I'd rather not have multiple scripts and have to spend time detecting what kind of content it is (I'm trying to automate my whole process from ripping a DVD to writing an AVI). So I've got the following which seems to work well for the handful of DVDs I've run through it so far, but it gives me 29.97 FPS video.

Is there a clean way to drop everything to 24 FPS? I'm completely new to all of this, but was able to cobble together the following from a few very good guides I found here. The video output is a little softer than I'd like, so any suggestions?


loadplugin("DGDecode.dll")
loadplugin("RemoveGrain.dll")
loadplugin("Repair.dll")

function RGDeinterlace(clip input)
{
rg = RemoveGrain(input, mode=12)
rg2 = TemporalRepair(rg, input, smooth=1)
return TemporalRepair(rg, rg2, smooth=1)
}

RGDeinterlace(mpeg2source("video.d2v"))

[chilledinsanity]

ha ha
No, you're not going to find anything like that. Since you want high quality AND one script AND not having to look at what the content is.

Most major movies are film content (23.976fps) and progressive, but it really depends on what you watch.

On the softness thing though, some things you can try:

-up the resolution
-use Lanczos's filter
-use QPEL when encoding in Xvid
-If all that isn't enough, there are sharpness filters you can use built into virtualdub. I did that for The Relic since the content itself was so soft.

[scharfis_brain]

@jstelly:
it is like asking for ONE ladder that lets you reach
- the top of your cupboard
- the roof of your house
- the ISS
- the Moon
- The Saturn
and even
- alpha Centauri

if you've found such a script, please notice me.
It will save me LOTs of time!

[buzzqw]

i would simply have an automatic script for resize that could respect (or better find if source is an already cropped video) aspect ratio (by resinzing and addborders)

both for d2v input and for directshow (or avisource).

i know grip.dll (crop/resize/addborders) but not ever is perfect.

BHH

[jstelly]

Yeah, from reading these forums over the last couple weeks it's clear to me now that the problem is more complicated than I figured it would be. I guess my next question would be, how does AutoGK produce acceptable results, I guess they detect what kind of content it is and use a different script for each different type of content?

[kassandro]

Originally posted by jstelly
Yeah, from reading these forums over the last couple weeks it's clear to me now that the problem is more complicated than I figured it would be. I guess my next question would be, how does AutoGK produce acceptable results, I guess they detect what kind of content it is and use a different script for each different type of content?
While there are certainly some scripts, to detect the kind of video, visual inspection is by far the best and the safest method. To this end you need a Bob filters which converts fields into frames. In particular, the number of frames is doubled. You may use the builtin bob filter named Bob, but there are better choices. I use my own

function RGBob(clip input, bool _grey)
{
top = RemoveGrain(input, mode=14, modeU=_grey ? -1 : 14)
bottom = RemoveGrain(input, mode=13, modeU=_grey ? -1 : 13)
return Interleave(top, bottom)
}

for this purpose. A visual test script then looks as follows:

MPEG2Source("input.d2v", cpu=4, ipp=true)
RGBob(false)

After loading the script into VdubMod, you move to a motion scene and watch what happens, if you move from one frame to the next. If you see the following pattern:

nomotion, motion, nomotion, motion, nomotion, motion,....

Then you are in the best of all worlds. You have a progressive video. You should not deinterlace or inverse telecine such videos. However, there are two kinds of progressive videos: correctly mastered and incorrectly mastered progressive video. If it is correctly mastered, then there is only motion from odd to even frames (I mean the frame numbers displayed by Vdub). If there is sometimes motion from even to odd frames, then you have an incorrectly mastered progressive video.
If you have only motion from even to odd fields (the majority of incorrectly mastered videos is of this type), then the following simple script function "repairs" the video:

function ShiftFields(clip input)
{
input = AssumeTFF(input)
sep = SeparateFields(input)
sep = trim(sep, 1,0)
return weave(sep)
}

If the motion pattern changes from "odd to even" to "even to odd" and conversely you need more sophisticated filters, so called field matchers, Telecide is only one example.
If the bobbed video shows always motion in motion scenes, then the video is interlaced and you should deinterlace it. My RGDeinterlace is a good choice, if you want the best compression. If you want the sharpest motion you should choose a sharp deinterlacer. However, if you want the same quality in static areas as with RGDeinterlace, a sharpely deinterlaced video is 30-50% larger than eith RGDeinterlace. Actually I personally use:

function RGDeinterlace(clip input, bool _grey)
{
rg = RemoveGrain(input, mode=12, modeU=_grey ? -1 : 12)
rg2 = TemporalRepair(rg, input, smooth=1, grey=_grey)
return RemoveGrain(rg2, mode=2, modeU=_grey ? -1 : 2)
}

If in the bobbed video, there are only a few frames with no motion (in motion scenes of course) then you have a telecined video. You can read the telecine pattern from the bobbed video, but as I live in the PAL world, I have very little experience with telecined video.
Finally, if in the bobbed video you see sharp and blurred frames, then you are in the worst of all worlds. You then have a video with blended fields or frames. There are good avisynth scripts at least for some kinds of blended videos.
If you have done this bobbed video analysis several times, you get quickly aquainted with this kind of visual analysis and your interest in an automatic solution will fade.

[scharfis_brain]

@kassandro:
- rgbob() looks interestening. but it only works with TFF video.

- shiftfields() is IMO a little too much to just do a simple phase shift.
I prefer doubleweave().selectodd()

- rgdeinterlace() looks equal to blur(0,1) to me.
Did I miss something?

[kassandro]

Originally posted by scharfis_brain

- rgbob() looks interestening. but it only works with TFF video.

Yes, it is for TFF video only. Changes for BFF are obvious. On the other hand DVD and DVB are always TFF.


- shiftfields() is IMO a little too much to just do a simple phase shift.
I prefer doubleweave().selectodd()

Yes, I agree. Theoretically doubleweave may weave twice as many frames as my weave in shiftfields, but Avisynth is smart enough to weave only the odd frames with doubleweave().selectodd(). Speed should be the same (trim and SeparateFields do not cost anything), but doubleweave().selectodd() should be more memory efficient.


- rgdeinterlace() looks equal to blur(0,1) to me.
Did I miss something?
Yes, you missed a lot. Firstly, RemoveGrain(mode=12) should be identical to blur(1) not blur(0,1). Secondly, because of TemporalRepair, the blurring is only done, when there is motion in the 3^3 st cube around a pixel. Also the amount of blurring depends on the amount of motion. Thus there are no threshold artifacts. If a 3^3 cube is too small, you may iterate TemporalRepair as done by jstelly.

[scharfis_brain]

Originally posted by kassandro
Yes, you missed a lot. Firstly, RemoveGrain(mode=12) should be identical to blur(1) not blur(0,1). Secondly, because of TemporalRepair, the blurring is only done, when there is motion in the 3^3 st cube around a pixel. Also the amount of blurring depends on the amount of motion. Thus there are no threshold artifacts. If a 3^3 cube is too small, you may iterate TemporalRepair as done by jstelly. [/B]

then, rgdeinterlace, is a superblurrer :)

but it deosn't behave like you wished. It doesn't care about static image areas.
everything is blurred.
so I do not see the difference between blur(1) and rgdeinterlace().

a real motion adaptvi deinterlacer produces much better deinterlacing.

look at these images:

(sorted by speed)
blur (0,1):
http://home.arcor.de/scharfis_brain/samples/rg01.jpg

soft kerneldeint:
http://home.arcor.de/scharfis_brain/samples/rg02.jpg

rgdeinterlace:
http://home.arcor.de/scharfis_brain/samples/rg00.jpg

please don't misunderstand me. I just want to know, what you are intending with this method, and why. Because other solutions seem to be much faster while retaining more quality.

[kassandro]

Originally posted by scharfis_brain
then, rgdeinterlace, is a superblurrer :)

If it would be identical to blur(1), it would indeed be a superblurrer. But that is not true at all. It only behaves like blur(1) near a pixel, if there is enough motion near that pixel. If there is no motion it behaves like RemoveGrain(mode=2), which cannot cause any visable damage. I apply RemoveGrain(mode=2) only to remove some hardly visable artifacts (you need 400% magnification in Vdub), which are negative for compression. These tiny artifacts happen, because RGDeinterlace doesn't blur enough without the final cleanup!

How can you prove my statement? Take the script:

input=ImageReader("my.jpg", 0, 1000, 25).ConvertToYV12()
rgd=RGDeinterlace(input)
rg=RemoveGrain(input, mode=2)
difference(rg, rgd)

my.jpg is a picture of your choice and difference is a filter of my SSETools plugin. It reports the SAD difference of the two clips for each frame to debugview. In this case difference will report zero differences. Clearly the input clip is absolutely static. If you would remove RemoveGrain(mode=2) from RGDeinterlace as in jstelly's version, then even the following script will report zero differences:

input=ImageReader("my.jpg", 0, 1000, 25).ConvertToYV12()
rgd=RGDeinterlace(input)
difference(input, rgd)

Thus without the nearly invisable RemoveGrain(mode=2), it would be a truely "no motion no change" deinterlacer, more motion adaptive than other smart deinterlacer.

Now to your pictures. It is clear from the blurred background (containing deinterlacing ghosts in all three pictures), that the original frame doesn't contain any static details. The camera is simply moving and it is moving quickly. Due to the massive global motion the original frame is already quite blurry, because the shutter speed is too slow for such massive motion. Thus in this case RGDeinterlace should behave like blur(1) and blur(1) doesn't cause much damage here. All three pictures show slight ghosts and if these picture are shown with 25 fps no human eye will see any difference.


Originally posted by scharfis_brain

but it deosn't behave like you wished. It doesn't care about static image areas.
everything is blurred.
so I do not see the difference between blur(1) and rgdeinterlace().

The above scripts easily disprove these absolutely false claims. I would very much appreciate, if you would carry out these tests and withdraw these claims here.

For future tests of these kind, I would recommend to use sharp frames, which contain areas with motion and areas without motion. That definitely excludes global motion as in your example.

EDIT: Actual the only static details are the korean characters and these are blurred more by RGDeinterlace, because the edges of these characters are completely within motion areas and then the purely vertical deinterlacers look better. If I would replace RemoveGrain(mode=12) by blur(0,1), then these characters would look equal. However, there are very good reasons for using the spatially homogeneous blur(1) instead of blur(0,1).

[scharfis_brain]

take a look at the subtitles!

they are completely static.

EDIT:
even with a stillframe repeated 1000 times, rgdeinterlace blurs the image like blur(1).

[kassandro]

Sorry, I should have carried out my own tests first. The problem is with smooth=1. If I take smooth=0, then my statements are correct. On the other hand smooth=0 creates too many artifacts. I have added smooth=1 in the last version of RemoveGrain and obviously - as my own tests now show - something has gone wrong.

[kassandro]

I have to withdraw from my apology - at least partially. Yes, there is a bug in TemporalRepair(smooth=1), but only if the color space is not yv12. Scharfi, you must have used yuy2 input, to make these false observations (they are false for yv12). I have now modified the above ImageReader scripts and now they prove my claims.
As TemporalRepair is used also in RemoveDust, this may explain also some of your recent statements in the RemoveGrain thread.

[scharfis_brain]

even, when I use smooth=0 and/or YV12 chroma, rdeinterlace still behaves like blur(1)

[kassandro]

Originally posted by scharfis_brain
even, when I use smooth=0 and/or YV12 chroma, rdeinterlace still behaves like blur(1)
You probably are doing something wrong. Running the script

function RGDeinterlace(clip input, bool _grey)
{
rg = RemoveGrain(input, mode=12, modeU=_grey ? -1 : 12)
rg2 = TemporalRepair(rg, input, smooth=1, grey=_grey)
return RemoveGrain(rg2, mode=2, modeU=_grey ? -1 : 2)
}
input=ImageReader("snap.png", 0, 1000, 25).converttoyv12()
rgd=RGDeinterlace(input, false)
rg=RemoveGrain(input, mode=2)
difference(rgd, rg)

I get the following dbgview output

[336] [0] total difference = 918174, different pixels = 440296
[336] [1] total difference = 634563, different pixels = 315605
[336] [2] total difference = 0, different pixels = 0
[336] [3] total difference = 0, different pixels = 0
[336] [4] total difference = 0, different pixels = 0
[336] [5] total difference = 0, different pixels = 0
[336] [6] total difference = 0, different pixels = 0
[336] [7] total difference = 0, different pixels = 0
[336] [8] total difference = 0, different pixels = 0
[336] [9] total difference = 0, different pixels = 0
[336] [10] total difference = 0, different pixels = 0
[336] [11] total difference = 0, different pixels = 0
[336] [12] total difference = 0, different pixels = 0
[336] [13] total difference = 0, different pixels = 0
[336] [14] total difference = 0, different pixels = 0
[336] [15] total difference = 0, different pixels = 0
[336] [16] total difference = 0, different pixels = 0
[336] [17] total difference = 0, different pixels = 0
[336] [18] total difference = 0, different pixels = 0
[336] [19] total difference = 0, different pixels = 0
[336] [20] total difference = 0, different pixels = 0
[336] [21] total difference = 0, different pixels = 0
[336] [22] total difference = 0, different pixels = 0
[336] [23] total difference = 0, different pixels = 0
[336] [24] total difference = 0, different pixels = 0
[336] [25] total difference = 0, different pixels = 0
[336] [26] total difference = 0, different pixels = 0
[336] [27] total difference = 0, different pixels = 0


Running the script

function RGDeinterlace2(clip input)
{
rg = RemoveGrain(input, mode=12)
rg2 = TemporalRepair(rg, input, smooth=1)
return TemporalRepair(rg, rg2, smooth=1)
}
input=ImageReader("snap.png", 0, 1000, 25).converttoyv12()
rgd=RGDeinterlace2(input)
#rg=RemoveGrain(input, mode=2)
difference(rgd, input)

I get the following dbgview output

[2324] [0] total difference = 1269986, different pixels = 475969
[2324] [1] total difference = 1231607, different pixels = 473497
[2324] [2] total difference = 856008, different pixels = 339494
[2324] [3] total difference = 0, different pixels = 0
[2324] [4] total difference = 0, different pixels = 0
[2324] [5] total difference = 0, different pixels = 0
[2324] [6] total difference = 0, different pixels = 0
[2324] [7] total difference = 0, different pixels = 0
[2324] [8] total difference = 0, different pixels = 0
[2324] [9] total difference = 0, different pixels = 0
[2324] [10] total difference = 0, different pixels = 0
[2324] [11] total difference = 0, different pixels = 0
[2324] [12] total difference = 0, different pixels = 0
[2324] [13] total difference = 0, different pixels = 0
[2324] [14] total difference = 0, different pixels = 0
[2324] [15] total difference = 0, different pixels = 0
[2324] [16] total difference = 0, different pixels = 0
[2324] [17] total difference = 0, different pixels = 0
[2324] [18] total difference = 0, different pixels = 0
[2324] [19] total difference = 0, different pixels = 0
[2324] [20] total difference = 0, different pixels = 0
[2324] [21] total difference = 0, different pixels = 0
[2324] [22] total difference = 0, different pixels = 0
[2324] [23] total difference = 0, different pixels = 0
[2324] [24] total difference = 0, different pixels = 0
[2324] [25] total difference = 0, different pixels = 0
[2324] [26] total difference = 0, different pixels = 0
[2324] [27] total difference = 0, different pixels = 0
[2324] [28] total difference = 0, different pixels = 0
[2324] [29] total difference = 0, different pixels = 0
[2324] [30] total difference = 0, different pixels = 0
[2324] [31] total difference = 0, different pixels = 0
[2324] [32] total difference = 0, different pixels = 0

Both tests confirm my claim. You may ask, why in the first test the first two and in the second test the first three frames are incorrect.
Answer: Strangely ImageReader displays the first frame correctly and all the others upside down. Secondly the first script operates on a 3^3 st cube and the second on a 4^4 st cube. Consequently, the first (and also the last) frames cannot be "repaired". Please try these tests on your own. I definitely want my deinterlacer to be vindicated from being a superblurrer. Currently this is true for the non-yuy2 version, which contrary to the yv12 version is also quite slow.

[scharfis_brain]

I'll continue this discussion here.


I wanted you to make some reasonable YV12 tests, in order to get rid of this "superblurrer" branding, which was justified then only for non-YV12. The YV12 code didn't change at all - at least as far as RGDeinterlace is concerned.

hmm. but then, why did my tests show that it behaved like blur(1) even with yv12 input?!?
two post above I said this!

As you didn't answer my latest contribution in this thread for quite a while, I did launch this little attack. The sole purpose was to make it clear, that your reputation in this forum will be reduced, if you are not able to withdraw from statements, which have turned out to be false. Unfortunately, I had to withdraw many times from some of my statements, because they were wrong. But it is better to withdraw from a statement rather than to hope that it will be forgotten.

As I said in the other thread, I was bored to discuss this further, because all what I did resulted in a superblur.

I also tried this pseudocode:

avisource("video.avi").assumetff().converttoyv12(interlaced=true)
changefps(5000) # to create pure static images
last(rgdeinterlace(),last)

it produced superblurring with the older version
and with the actual version it does some kind of weak median filtering

As far as residual combs are concerned you are probably right. I would rather prefer to say that there are deinterlacing artifacts. Most smart deinterlacers exhibit some kind of artifacts under 400% magnification in Vdub.

I never do 400% mag. when testing video.
I also never rub my nose on the screen.

rgdeinterlace
http://home.arcor.de/scharfis_brain/samples/rgdeint01.jpg

soft kerneldeinterlace
http://home.arcor.de/scharfis_brain/samples/rgdeint02.jpg

the artifacts of rgdeint are clearly visible, while the ones of kerneldeint are very weak.

these kind of artifacts occur always, if patterned textures are moving linaer. But with rgdeinterlace it occurs even earlier.

On the other hand, The compression results speak for themselves. If the residual combs or artifacts would be significant, these results would be impossible. I claim that except my earlier Deinterlacer AlignFields no other Deinterlacer, which doesn't blur static areas, comes even close to RGDeinterlace (I mean the iterated version of jstelly in the above thread) as far as compression is concerned.

It compresses this well, because it also blurs in horizontal direction, which is NOT the task of a deinterlacer.
Also it tends to be much to sensitive to whatever motion/luma-change so it also seems to deinterlace too early.

Look at the images.
rgdeint is much more blurred than the soft kerneldeinterlace

[kassandro]

Originally posted by scharfis_brain

hmm. but then, why did my tests show that it behaved like blur(1) even with yv12 input?!?
two post above I said this!

I have no explanation. I did post my test results above.



I also tried this pseudocode:

avisource("video.avi").assumetff().converttoyv12(interlaced=true)
changefps(5000) # to create pure static images

If you choose frames in the middle of static periods and not near the beginning or end of a period this is fine with me.


and with the actual version it does some kind of weak median filtering

If you use my version with postcleaning, this is correct. If you use
jstelly's version, then there should be absolutely no change.



rgdeinterlace
http://home.arcor.de/scharfis_brain/samples/rgdeint01.jpg

soft kerneldeinterlace
http://home.arcor.de/scharfis_brain/samples/rgdeint02.jpg

the artifacts of rgdeint are clearly visible, while the ones of kerneldeint are very weak.

these kind of artifacts occur always, if patterned textures are moving linaer. But with rgdeinterlace it occurs even earlier.

I have inspected both pictures and they prove your point. The pencil on the white table (or whatever it is) shows massive combs. The problem is the homogeneous white background, which makes it difficult to recognize motion near the stick. Nevertheless it shouldn't happen. I would like explore it. For this purpose, I need three frames, the original frame and its both original neighbours.


It compresses this well, because it also blurs in horizontal direction, which is NOT the task of a deinterlacer.
Also it tends to be much to sensitive to whatever motion/luma-change so it also seems to deinterlace too early.

No. Of course, blurring also horizontally has a substantial impact compression. The golden rule of blurring is to blur the same way in both directions, because all reasonable codecs use the same kind of quantising in both direction. Now, if the video is more blurry vertically than horizontally this kind of quantising is not optimal. Of course, if you deinterlace, the video will always be more blurry vertically than horizontally at least in motion areas. Even with blur(1). Now, Leakkerneldeint, is purely vertical, but it uses also pixels, which are further away (outside the 3x3 square), though with a small weight only (I really don't understand why). Also Tomsmocomp uses pixels outside the 3x3 square. Thus I am in good society. The main reason why Leakkerneldeint performs so poorly in compression tests is that it is threshold based. It generates a yes or no mask and according to this motion mask a pixel remains unchanged or it is interpolated. This is always bad. In AlignFields I also used motion mask, but to avoid the threshold desaster, I always made a smooth transition between yes or no. Now all versions of RGDeinterlace contain no thresholds at all, because the building blocks are threshold free. That is its fundamental advantage. It is not perfect (as already mentioned in the RemoveGrain documentation), but it won't be my last word on deinterlacing either. You can help me with critisism, if you underpin this critisism with critical three frame clips.

[Guest]

Originally posted by kassandro
It generates a yes or no mask and according to this motion mask a pixel remains unchanged or it is interpolated. This is always bad. Please support this provocative statement with objective analysis. You can begin with a formal definition of "bad", relating it to the successful uses of this filter by a lot of people. Thank you.

There is a plethora of all kinds of video processing algrithms that utilize thresholds. Are you saying that they are all "bad"?

You've already stated that your blending approach ruins the edges of static logos. Is that not "bad"? Are we not dealing with tradeoffs, such that different values may make certain features of a tool better for specific applications?

[kassandro]

Originally posted by neuron2
Please support this provocative statement with objective analysis. You can begin with a formal definition of "bad", relating it to the successful uses of this filter by a lot of people. Thank you.

I hope that I didn't violate one these outstanding forum rules. The last time you intervened, you locked out mf, a strong contributer to this forum, because he wanted to know what is best. He never returned. Congratulations for this great achievement. I didn't say that Leakkerneldeint is bad. I only said that compression performance is poor.


There is a plethora of all kinds of video processing algrithms that utilize thresholds. Are you saying that they are all "bad"?

Thresholds are not necessarily bad and sometimes they simply cannot be avoided. However, there is a simple criterion, when thresholds have a negative impact on compression and this is certainly not a good feature. To this end, say you have two pixels which are close to each other. The first is slightly above the threshold and the secoond slightly below the threshold. If the processing based on this threshold is very different for both pixels, it is a bad threshold otherwise it is a good threshold. Unfortunately in virtually all thershold based deinterlacers including your ones most thresholds are bad. Soemtimes, you can change bad thresholds into good ones. For instance, In his Degrainmedian filter Fizick replaced the bad thresholds in trbarry's st median filter by a good one.


You've already stated that your blending approach ruins the edges of static logos. Is that not "bad"?

This is not quite correct. This only happens, if these logos are surrounded by motion. If the area around the motion is not moving, I will not touch it. On the other hand, you should keep in mind, that if a logo is surrounded by motion, then the DCT will also ruin the edges of the logo, if it is has to take a reasonable quantiser. If we really want to be precise, we should compare compressed rather than uncompressed frames. If you use a deinterlacer with bad compression the codec has to choose a higher quantiser to achieve the same size and this can be much more negative.


Are we not dealing with tradeoffs, such that different values may make certain features of a tool better for specific applications?
Of course, but this shouldn't prohibit lively discussions.

[scharfis_brain]

I never bothered about compressibility!
But one thing for sure:
blur(1)
comresses well :p

Deinterlacers are not built to give a good compression.
They are made to achieve the best possible image quality.

If one needs better compressibility, the result should be postprocessed AFTER deinterlacing.

But a deinterlacer that unnecessary blurs the image just to give a good gompression isn't a good deinterlacer.

A good deinterlacer doesn't alter the image a much as needed, but also alters it in a way to reach as close as possible the quality of a progressive frame.

But with a blur-deinterlacer this idea is completely ruined.


EDIT: I'll do the 3 images tomorrow.
(would a 3 frames AVI be sufficient, too?)

[kassandro]

Originally posted by scharfis_brain

Deinterlacers are not built to give a good compression.

For Deinterlacers in 100 MHZ TVs or DVD players this is correct. But for Avisynth deinterlacers this is false. In the end, all serious Avisynth scripts are served to a compressor, whence compression is a crucial issue for all AVS filters.


If one needs better compressibility, the result should be postprocessed AFTER deinterlacing.

Unfortunately this approach is not feasible, because I only want to blur, where I want to deinterlace.


But a deinterlacer that unnecessary blurs the image just to give a good gompression isn't a good deinterlacer.

Before compression, you are certainly right. Good compression cannot be combined with optimal image quality. After things may look very differently, if you want to achieve a fixed output size.


A good deinterlacer doesn't alter the image a much as needed, but also alters it in a way to reach as close as possible the quality of a progressive frame.

I don't agree with this definition of image quality, which underlies your statements. Video processing and Image processing in general is all about deceiving the human eye. If I would compete in the objective test, which you have mind, I would certainly not come up with RGDeinterlace. I could come up with a very competitive filter in this test, but I would never use it for real deinterlacing. Convert a truely progressive 50 fps video (no filtering should have been applied to it before), then convert this video down to an 25 fps interlaced video and finally apply the deinterlacers to this video and measure the SAD distance between the deinterlaced and the original progressive frames. This is the only valid objective test for your kind of image quality.


But with a blur-deinterlacer this idea is completely ruined.

All builtin deinterlacers in standard encoders like Dr. DivX use blur(0,1) for deinterlacing.


EDIT: I'll do the 3 images tomorrow.
(would a 3 frames AVI be sufficient, too?)

Thanks, in advance.

[Guest]

Originally posted by kassandro
I hope that I didn't violate one these outstanding forum rules. The last time you intervened, you locked out mf, a strong contributer to this forum, because he wanted to know what is best. He never returned. Congratulations for this great achievement. Your revisionist history is incorrect and your insulting implications are getting very close to the strike zone.

[scharfis_brain]

For Deinterlacers in 100 MHZ TVs or DVD players this is correct. But for Avisynth deinterlacers this is false. In the end, all serious Avisynth scripts are served to a compressor, whence compression is a crucial issue for all AVS filters.

so you say that your blurry deinterlacer looks better than the crisp kerneldeint on my 4 mbps VBR DVD encodes?

Unfortunately this approach is not feasible, because I only want to blur, where I want to deinterlace.
Easily to achieve with Motionmasks AFTER deinterlacing.

Before compression, you are certainly right. Good compression cannot be combined with optimal image quality. After things may look very differently, if you want to achieve a fixed output size.
If you are talking about less than 1 mbps encodes,
you are probably right. But uhm, 1mbps....

All builtin deinterlacers in standard encoders like Dr. DivX use blur(0,1) for deinterlacing.
Nice. :rolleyes:
I don't use DivX. I also never use builtin deinterlacers.

Convert a truely progressive 50 fps video (no filtering should have been applied to it before), then convert this video down to an 25 fps interlaced video and finally apply the deinterlacers to this video and measure the SAD distance between the deinterlaced and the original progressive frames. This is the only valid objective test for your kind of image quality.
Exactly! :)

So, what's the task of a deinterlacer?
Yes: Restoring progressive frames as good as possible.
So there is NO sense for unnecessary blurring.
I want to keep as much as possible image detail and crispness and sometimes do some Limitedsharpening afterwards too!

I am NOT a fan of
>Compress_everything_until_it_fits_on_3.5"FD>

The Frames you requested:
http://home.arcor.de/scharfis_brain/samples/d9-short.avi

[tritical]

Unfortunately this approach is not feasible, because I only want to blur, where I want to deinterlace. And this applies to everyone and every source?

(I seem to remember this compressibility argument taking place before)... Anyways, if compression truely mattered that much to everyone, all the time, no one would ever use lanczos instead of bilinear, no one would use a sharpening filter, no one would purposefully add noise into an encode, etc... The fact of the matter is, it depends on your goals and your preferences. If your aiming for a low bitrate encode on a hard to compress source then the compressibility of the deinterlacer you use could matter, but if your doing high-bitrate encodes with a low average quant value then it is moot. I personally never use a blur deinterlacer, but then again I'm usually more concerned about the subjective picture quality (how it looks to me, not what someone else says should look better) and impression then compression which is a distance second (this is the reason there is more then one deinterlacing filter for avisynth, why there is more then one denoising filter, why there is more then one sharpening filter, etc...). However, I also will tend to increase the size of the final encode if it doesn't compress well.

In the end, it comes down to personal preference. If everyone was truely after a very compressible deinterlacer, but not concerned with image quality then everyone would simply have used blur() from the beginning of time. This is obviously not the case... so if one is to admit that image quality must be taken into account then one has to admit that it comes down to personal preference and which you value more, compressibility or subjective image quality, and that varies not only from person to person but from source to source.

Saying that comparisons of deinterlacers should be done after compression is valid, but that reasoning applies to denoisers, sharpeners, and every other filter your using. For example, why do some people use denoisers that barely touch the image but leave most details as opposed to a heavy duty blur the crap out of it denoiser? Obviously the heavy duty filter will compress better. Its because they care more about the picture quality then compression and are not making an encode at such a low-bitrate/high-quant that the extra compression gain makes the super blurry video better then the other after compression. Thus, exactly how much your trying to compress the source has to be taken into account when arguing how much the compressiblity of the output of a filter should weigh in comparing a filter to other such filters.

[kassandro]

Originally posted by scharfis_brain
so you say that your blurry deinterlacer looks better than the crisp kerneldeint on my 4 mbps VBR DVD encodes?

4 mbps? Come on, even interlaced DVB streams are often below 4 Mbps. You need an expander and not a compressor. My progressive encodes are in the average 900 kbps (90% of my material) and for interlaced material (10%) I have an average bitrate of 700 kbps. to achieve this I use quantiser 5 for I and P frames and a somewhat higher quantiser for B-frames. This is certainly not DVD quality but way above VHS and my DVD player loves it.


Easily to achieve with Motionmasks AFTER deinterlacing.

You can do a lot, if you have time. But does it make sense? Any deinterlacer already uses internally something like a motion mask for interpolation. Why should I do this twice? You suggest that the deinterlacer should blur only vertically and then I should do the same thing again to blur horizontally. Even the quality of blurring is declining this way. RemoveGrain(mode=12) handily beats blur(1) in a compression contest, because blur(1) unlike RemoveGrain(mode=12) applies the (1/4,1/2,1/4) kernel in each direction separately and commits various inaccuracies.


If you are talking about less than 1 mbps encodes,
you are probably right. But uhm, 1mbps....

Yes, for deinterlaced material I virtually never want to exceed 1 Mbps.


So, what's the task of a deinterlacer?
Yes: Restoring progressive frames as good as possible.

No, that would be only the aim in the above objective test and, as I said, I then would use a very different filter to compete in such test. Unfortunately we have no truely 50 fps progressive material.
But we have a lot of 25 fps progressive material, which can be nicely used for any objective test for bob filters: throw away the bottom field and interpolate it using only the top field and finally measure the SAD difference between the interpolated and the original bottom field.
My RemoveGrain(mode=16) would perform quite well in such a contest, although it has a speed probably over 1000 fps on my 3 GHZ Celeron. Thus I could sharp interpolation as well, if I really wanted it.


I want to keep as much as possible image detail and crispness and sometimes do some Limitedsharpening afterwards too!

I would also like to use LimitedSharpen but during play back and not before encoding. Unfortunately the sharpener in my DVD player is terrible and therefore unusable.



Originally posted by tritical
And this applies to everyone and every source?

If I would blur after deinterlacing, I would need a mask something like that to remember, where I deinterlace, because I want to blur only there. Such a procedure simple doesn't make sense. Blurring must be integrated into deinterlacing. I am usually doing some spatial denoising after deinterlacing, now with RemoveGrain(mode=17), but this has nothing to do with blurring. In fact, RemoveGrain(mode=17) sharpens edges slightly and preserves thin lines.


(I seem to remember this compressibility argument taking place before)...

Yes, I am stressing this argument all the time, because nobody else does it.


Anyways, if compression truely mattered that much to everyone, all the time, no one would ever use lanczos instead of bilinear, no one would use a sharpening filter, no one would purposefully add noise into an encode, etc... The fact of the matter is, it depends on your goals and your preferences. If your aiming for a low bitrate encode on a hard to compress source then the compressibility of the deinterlacer you use could matter, but if your doing high-bitrate encodes with a low average quant value then it is moot. I personally never use a blur deinterlacer, but then again I'm usually more concerned about the subjective picture quality (how it looks to me, not what someone else says should look better) and impression then compression which is a distance second (this is the reason there is more then one deinterlacing filter for avisynth, why there is more then one denoising filter, why there is more then one sharpening filter, etc...). However, I also will tend to increase the size of the final encode if it doesn't compress well.

Many people think like that, but in practice, what are they doing? They take 100 minute movie and use two pass encoding such that it fits exactly on a 700 MB CD and are wondering why they are getting poor quality. With all that talk about compression, I want to convey the following: rather than asking for the best image quality, look for the best compromise between image quality and compression.


In the end, it comes down to personal preference. If everyone was truely after a very compressible deinterlacer, but not concerned with image quality then everyone would simply have used blur() from the beginning of time. This is obviously not the case... so if one is to admit that image quality must be taken into account then one has to admit that it comes down to personal preference and which you value more, compressibility or subjective image quality, and that varies not only from person to person but from source to source.

It is all about compromise. No reasonable deinterlacer can compete with blur(1) as far as compression is concerned. I definitely do not want to beat blur(1), but I want to beat blur(0,1), because blurring only vertically is suboptimal for compression. If I blur only the motion areas with blur(1) and keep the static areas sharp, then I usually beat blur(0,1) and it looks quite good, since viewers can see the fine details only in static areas, anyway, because they usually watch movies on TV and not with Virtualdub.


Saying that comparisons of deinterlacers should be done after compression is valid, but that reasoning applies to denoisers, sharpeners, and every other filter your using.

I couldn't agree more. In fact, compression is always on my mind, when I evaluate an Avisynth filter.


For example, why do some people use denoisers that barely touch the image but leave most details as opposed to a heavy duty blur the crap out of it denoiser? Obviously the heavy duty filter will compress better.

Again, it is not about compression alone and it is not about image quality alone. It is all about the best compromise between both. Because you are not willing compromise - your only preference is image quality - you shouldn't iterate all the time that my only preference is compression. This is absolutely wrong, but of course I have to argue all the time only with the image quality purists and therefore have to stress compression all the time.


Its because they care more about the picture quality then compression and are not making an encode at such a low-bitrate/high-quant that the extra compression gain makes the super blurry video better then the other after compression. Thus, exactly how much your trying to compress the source has to be taken into account when arguing how much the compressiblity of the output of a filter should weigh in comparing a filter to other such filters.
Everybody should find his own compromise between image quality and compression, but he should know that he has to make a compromise. I know that it is uphill battle to say "Don't go for the best image quality", even if these best image quality two pass encoders are getting most of the time their well deserved punishment.

[scharfis_brain]

I'll only answer 1 quote now.
the rest tomorrow.

4 mbps? Come on, even interlaced DVB streams are often below 4 Mbps. You need an expander and not a compressor. My progressive encodes are in the average 900 kbps (90% of my material) and for interlaced material (10%) I have an average bitrate of 700 kbps. to achieve this I use quantiser 5 for I and P frames and a somewhat higher quantiser for B-frames. This is certainly not DVD quality but way above VHS and my DVD player loves it.

900kbps? Uh how ugly. Every fine detail will be smoothed out for sure.
700kbps for laced contents? A L O W E R bitrate for lacing?
Yeah, looks like you've understood the concept :rolleyes:

I do not like heavily compressed stuff.

Further:
I do NOT have television here!
I do not pay my Cable Fee and also don't have south side for sattelite view.

But come on!
There are a lot of other sources, which are NON MPEG.
Some to mention: DV-Cams
High Quality DVDs of eg. Concerts.
Analogue reception!

[Si]

@scharfi

Deinterlacers deinterlace interlaced video. :p

Something that attempts to extract/restore progressive frames from a mixed up source should be called something else. (I call mine PFR):)

IMHO, you seem to have got almost everything else right :)

regards
Simon

[kassandro]

Originally posted by scharfis_brain

900kbps? Uh how ugly. Every fine detail will be smoothed out for sure.

No, not at all. In fact, I usually burn the original DVB stream on DVD, but prefer to watch the 900 kbps XviD versions, because noise makes me feel uncomfortable. I never blur progressive Video, but I am doing intensive compressor friendly denoising. Even with the lowest reasonable quantiser 2, I would probably achieve bitrates around 2 Mbps.


700kbps for laced contents? A L O W E R bitrate for lacing?
Yeah, looks like you've understood the concept :rolleyes:

No, I mean deinterlaced content. In fact, I never use interlaced encoding. Approriately deinterlaced video simply contains less information than progressive video. Hence it is only natural that with the same quantiser the bitrates are lower. I have to add that for audio I usually use Ogg Vorbis mono vbr audio with a bitrate of about 37 kbps, which is more than enough for old movies. For the DVD player I convert this kind of audio to 48 kbps mp3 mono cbr audio.


There are a lot of other sources, which are NON MPEG.
Some to mention: DV-Cams
High Quality DVDs of eg. Concerts.
Analogue reception!
More than 95% of my sources are from digital satellite. Occassionaly I have some short digicam clips and I am also exploring to convert some of my old VHS tapes to XviD.

[scharfis_brain]

I hope, it is okay for you, if I don't discuss every point you mentioned.

Altogether we do have completely different opinions and areas of interest.

You like to prepare your video for some kind of extreme compression at the cost of some blurryness.

I like to get out as much as possible quality (meaning image detail and crispness) out of any source.
(mvbobbing, mvdenoising, mved framerate conversions, Limitedsharpen, BDH etc.
the brute force stuff, if you know what I mean :D )
So I don't care much about filesizes which means I am mostly free regarding image contents.

So I try to (sorry I cannot guarantee) avoid further discussion about your compression enhancer plugins.

Maybe you should clearly note, which function/plugin/mode heavyly blurs to achieve better compression.

As far as I remember you didn't mention this in past when you compared kerneldeint to rgdeint.

[kassandro]

Originally posted by scharfis_brain

You like to prepare your video for some kind of extreme compression at the cost of some blurryness.

I like to get out as much as possible quality (meaning image detail and crispness) out of any source.
(mvbobbing, mvdenoising, mved framerate conversions, Limitedsharpen, BDH etc.

I do not attempt extreme compression. The compression rates I spoke about are fairly standard. Microsoft claims even much lower bitrates (VHS quality at 250 kbps) for their WM9 enocder. Certainly this is only a claim without any substance, but it shows the bandwidth of opinions. I think there are three aspects of video processing: image quality, compression and speed. You rank the first far above the other two and I don't. This is our fundamental difference.


As far as I remember you didn't mention this in past when you compared kerneldeint to rgdeint.
Actually I only compared compression, speed and features (no motion no change, sharp or blur, one field preserved, etc.) of deinterlacer. I never said that one deinterlacer is better than another. If we would have good 50 fps progressive videos, I would also make image quality tests.

Your short mjpeg video (it certainly does not support your dedication to utmost image quality) was very helpful to resolve the basic problem of RGDeinterlace. Actually, this black pencil on a white table exposed the problem so purely, that I finally could come up with a good theory to explain this phenomenon, which I already observed in much smaller form (400% magnification) long before. My desperate attempts can be seen from many unsuccesfull versions of TemporalRepair in the RemoveGrain source). As Kant said, there is nothing more practical than a good theory and in RemoveGrain version 0.9 this theory will be made concrete with TemporalRepair(smooth=2). Needless to say, that new compression are inevitable and I will invite you for critisism.

[scharfis_brain]

Originally posted by kassandro
I do not attempt extreme compression. The compression rates I spoke about are fairly standard.
Fairly standard regarding high compression, yes.

Microsoft claims even much lower bitrates (VHS quality at 250 kbps) for their WM9 enocder. Certainly this is only a claim without any substance, but it shows the bandwidth of opinions.
I think the comparision to VHS-quality is nonsense.


Also I do NOT like such high compressed stuff, as I said before.
The compression artifacts that occur (maybe only from time to time) are annoying.
And 1 mbps is definitely too low for fullPAL,
unless you have a very clean source.



I think there are three aspects of video processing: image quality, compression and speed. You rank the first far above the other two and I don't. This is our fundamental difference.

Yeah.
My common ranking:
Quality -> Speed -> Compression

But sometimes I also try to merge compression & quality.



Actually I only compared compression, speed and features (no motion no change, sharp or blur, one field preserved, etc.) of deinterlacer. I never said that one deinterlacer is better than another. If we would have good 50 fps progressive videos, I would also make image quality tests.

But isn't a compression test without a image quality test worthless?

Your short mjpeg video (it certainly does not support your dedication to utmost image quality)

It is not the best quality. For sure.
But this makes it becoming a stress test for differrent technologies:
Deinterlacers (crisp lines, patterned background movement that irritates comb masks)
Deinoisers (weak contrasted background features)
Sharpeners (horizontal blurryness)

I use it very often for testing new functions plugins and programs.

was very helpful to resolve the basic problem of RGDeinterlace. Actually, this black pencil on a white table exposed the problem so purely, that I finally could come up with a good theory to explain this phenomenon, which I already observed in much smaller form (400% magnification) long before. My desperate attempts can be seen from many unsuccesfull versions of TemporalRepair in the RemoveGrain source). As Kant said, there is nothing more practical than a good theory and in RemoveGrain version 0.9 this theory will be made concrete with TemporalRepair(smooth=2). Needless to say, that new compression are inevitable and I will invite you for critisism.

Cannot state much here, since I not do know much about the internals & usage of your plugins.

[kassandro]

Originally posted by scharfis_brain

But isn't a compression test without a image quality test worthless?

Yes, it is only one aspect, which can be measured. Image quality, on the other hand cannot really be measured. The above test of restoring a 50 fps progressive video, can only measure the objective image quality and this is not the image quality, which matters. Manufacturers of Digicams know this very well. With their small 5-8 Megapixel CCDs they have do a lot of denoising and that hurts the objective image quality a lot. You can see this if you use Digicam in video mode. Then the image processor has not enough time to denoise the picture and you even get quite noisy frames at a resolution of 640x480.

We may continue the discussion, when I have finished RemoveGrain 0.9.