good bob to resize interlaced video

[mathmax]

Hello

I just wanted to know what is a good filter to use for resizing an interlaced video.


bestbob()
LanczosResize(720, 480)
SeparateFields()
Selectevery(4,0,3)
weave()


after searching, I listed the following:
-bob()
-yadif(mode=1)
-SmoothDeinterlace(doublerate=true)
-KernelBob(1)
-LeakKernelBob(1)
-TDeint(1)
-QTGMC (although I heard it was not advised for that purpose..)
-others.. ?

thank you in advance for your suggestions :)

[librarian]

Hello

I just wanted to know what is the ... bob filter to use for resizing an interlaced video.

Don't ask for the ....:).

In addition to your list:

DGBob,
SBDeint,
Alignfields(fps2=true)
Ibob
MyBob (a function proposed by Gavino).

Sometimes even the simplest (and fastest) Ibob may give acceptable results. All in all Tdeint(mode=1) is a good performer.

[mathmax]

Thank you

I could add: YadifMod(mode=1,edeint=NNedi3(field=-2))
I think it's not bad... :)

what does field=-2 mean btw?

[Guest]

From the documentation:

field -

Controls the mode of operation (double vs same rate) and which field is kept.
Possible settings:

-2 = double rate (alternates each frame), uses avisynth's internal parity value to start
-1 = same rate, uses avisynth's internal parity value
0 = same rate, keep bottom field
1 = same rate, keep top field
2 = double rate (alternates each frame), starts with bottom
3 = double rate (alternates each frame), starts with top

Default: -1 (int)

[librarian]

Thank you

I could add: YadifMod(mode=1,edeint=NNedi3(field=-2))
I think it's not bad... :)

what does field=-2 mean btw?
From the readme:

Controls the mode of operation (double vs same rate) and which field is kept.
Possible settings:

-2 = double rate (alternates each frame), uses avisynth's internal parity value to start
-1 = same rate, uses avisynth's internal parity value
0 = same rate, keep bottom field
1 = same rate, keep top field
2 = double rate (alternates each frame), starts with bottom
3 = double rate (alternates each frame), starts with top

As to yadifmod(edeint....) you may be interested in this post (http://forum.doom9.org/showthread.php?p=1374359#post1374359)

I see neuron2 has been faster than me.

[mathmax]

thank you.. and what is the difference between bob() and bob(0.0, 1.0). I looked in the documentation, but I can't understand these parameters.

[librarian]

thank you.. and what is the difference between bob() and bob(0.0, 1.0). I looked in the documentation, but I can't understand these parameters.

There is an old post of MugFunky (I think).

These parameters have the same use in Bicubicresize (blur/sharp).

Edit: it was sh0dan here (http://forum.doom9.org/showthread.php?p=367056#post367056).

[mathmax]

Thank you librarian :)


As to yadifmod(edeint....) you may be interested in
Should I understand Didée rather advises to use TGMC or tempgaussmc because it has motion compensation and is not so slower compared to nnedi?

Someone told me before that QTGMC shouldn't be use for such purpose because it messes with both fields where with normal bobbers one field of the resulting frame is untouched and the other is interpolated..

[librarian]

Every bobber transforms a field in a frame...., each field is always altered.

[Guest]

Every bobber transforms a field in a frame...., each field is always altered. That is false.

[mathmax]

by untouched, I meant that:


AssumeTFF()
yadif(mode=1)
SeparateFields()
SelectEvery(4,0,3)

is equivalent to SeparateFields()
but that is not the case with QTGMC.. so I was no advised to use it for that reason. Was it a good advice?


Else, I wonder if I could use nnedi to resize my field at the same time I deinterlace to double framerate. In other words, is there a more clever way that doing:


YadifMod(mode=1,edeint=NNedi3(field=-2))
LanczosResize(720, 480)


something like

YadifMod(mode=1,edeint=NNedi3(field=-2, rfactor=2, cshift="spline64resize", fwidth=720, fheight=480)))

although the last parameters are for nnedi3_rpow2().

[librarian]

That is false.
IMHO that is the definition of bobber, are we speaking of this (http://forum.doom9.org/showthread.php?p=1160630#post1160630)?

[Didée]

Someone told me before that QTGMC shouldn't be use for such purpose because it messes with both fields where with normal bobbers one field of the resulting frame is untouched and the other is interpolated..
That's basically true, but practically irrelevant. You are doing an interlaced resize, which means that you change everything, anyway.

For most cases of interlaced resizing, ye old bob/resize/separate/weave does a sufficient job, IMO. Using smarter bobbing will introduce a benefit at the intermediate progressive stage, sure, but most of that benefit is thrown away again at the very moment that the reinterlacing is done.

Just try it out! Try out the different ways, and look close if you can see the 0.5% improvement that a 500% slower method eventually might produce. :)

[Guest]

IMHO that is the definition of bobber, are we speaking of this (http://forum.doom9.org/showthread.php?p=1160630#post1160630)? It's false that each field's information is always altered.

[Mini-Me]

Someone told me before that QTGMC shouldn't be use for such purpose because it messes with both fields where with normal bobbers one field of the resulting frame is untouched and the other is interpolated..

Aside from Didee's response (it doesn't really matter if you're resizing afterward), you can always use lossless = 1 to ensure the original lines are completely untouched (there are a couple noise control settings in QTGMC that can undermine this, but as long as you aren't using them...).

[2Bdecided]

For most cases of interlaced resizing, ye old bob/resize/separate/weave does a sufficient job, IMO.That rather depends on whether you're resizing to a larger, similar or smaller frame size!

For smaller, just use bob(). For larger, use qtgmc. With sources I've tried, it looks worse if you try to use the true "lossless" mode to keep the original fields intact.

For similar size, it depends on exactly what you're doing.

What are you trying to do?

Cheers,
David.

[mathmax]

What are you trying to do?
I'm trying to resize to a larger frame size a documentary that is made with several video sources. Some scenes are interlaced source and some are 24fps telecined.
I don't want to select each scene individually to either apply inverse telecining or deinterlace... that is just too much work. If there are some tools to detect 3:2 pulldown, that would be perfect.. I could thus resize in a very clean way. Since I'm not aware of the existence of such filter, I'll just consider the whole documentary is simply interlaced and apply my bob() + separatefields() to resize it.

I made tests with several different bobber in order to see which is the best. I compared with a progressive frame of a telecined part that I simply resized. Here it is:

http://img40.imageshack.us/img40/9333/original0000.png

Now lets compare the different bob filters I used.. (see the script in the first post. I know it seems senseless to bob a progressive frame in order to resize it.. but as I said, I just apply the same process on all the frames of the documentary)
http://img607.imageshack.us/img607/2356/bob0000.png
http://img407.imageshack.us/img407/7062/yadif0000.png
http://img705.imageshack.us/img705/4302/yadifmod0000.png
http://img140.imageshack.us/img140/1553/tdint0000.png
http://img853.imageshack.us/img853/9608/qtgmc0000.png

As you can see, the best ones seem to be TDint & QTGMC (at least on a progressive frame).. TDint leaves the video with slightly less comb artifacts wheareas QTGMC is a bit sharper.
I think I would go with TDint because QTGMC is so much slower..

I also tried leakkernelbob() but it produces horizontal lines... which is quite strange:
http://img684.imageshack.us/img684/2254/leakkernelbob20000.png

You can have a try on this very short sample I uploaded:

http://www.mediafire.com/?c1v3xib4mo1ggh2

Of course the best would be to detect 3:2 pulldown (is it possible?)
I was then searching for filters that would detect progressive frames. If that would exist, I would just resize and use the bob filter only for interlaced frames.
I finally opted for the simple solution to apply the same process on the whole video.. but if any of the preceding filter would exist, I would be very interested to use them.

[Guest]

Your clip is too short and does not have enough movement for proper analysis. Please post a longer source sample with a lot of movement.

It is easily possible to detect 3:2 pulldown. You use the flags in the source stream, if applicable, or you inspect the fields by eye after separating them with separatefields().

http://neuron2.net/faq.html#analysis

[mathmax]

Your clip is too short and does not have enough movement for proper analysis. Please post a longer source sample with a lot of movement.

It is easily possible to detect 3:2 pulldown. You use the flags in the source stream, if applicable, or you inspect the fields by eye after separating them with separatefields().

http://neuron2.net/faq.html#analysis
There is no flag, it's hard telecined. And I don't want to inspect and select each scene manually.. it's too much work.

Here is a longer sample :
http://www.mediafire.com/?3qk351mr691mvxm

[Guest]

I don't want to inspect and select each scene manually.. it's too much work. OK. You're looking for a tool that will figure everything out and set up the encode and away you go. You might get better answers in the GUI and one-click forums. Or just be happy with your generalized process. It's not a terrible solution.

[Didée]

vid.TFM(clip2=vid.SomeDeinterlacer())

[mathmax]

vid.TFM(clip2=vid.SomeDeinterlacer())
if I apply TFM() on the whole footage, the parts that are not telecined will be messed up :(

[Didée]

If a section is interlaced, TFM should find no matching field, and ressort to the fallback solution "deinterlace this frame". Via clip2, an external deinterlacing solution is used instead of the built-in's of TFM.

How you need to set up TFM's parameters exactly, that's another story. You might have noted there are quite a few parameters to tweak TFM's decisions (RTFM!). The approach in itself, however, is both logical and valid.

OTOH, your examples of deinterlace+resize (on telecined sections) are not exactly shining examples of gorgeous success... (<--Short of saying the result looks pretty poor.) (<--short of saying "awful".)

[mathmax]

This video is a mess. There are sections with :
1. 3:2 pulldown
2. progressive 29.97fps
3. true interlaced 29.97fps
4. 29fps with fields shifted : AtBb BtCb CtDb DtEb...

The documentary is 2 hours long with many scenes changing..

vid.TFM(clip2=vid.SomeDeinterlacer()) can deal with 1/, 2/ and 4/ but it detects 3. has a 3:2 pulldown, whereas it should bob it to 59.94 fps. Clip2 must have the same framerate as vid... so I don't see how it could deinterlace to double framerate.

Moreover, I wonder how I could recover a constant framerate after that. I will have some sections with 29fps, some sections with dupes that can be decimated to 24fps and some sections with 59fps... :-/

[hydra3333]

Other source issues aside, I asked about interlaced down-resizing too, some time ago. In the result I saw a lot of shimmering after re-interlacing and eventually got advice to blur. See below, OK for some sharpening too, but slowish.

QTGMC(Preset="Slower",EdiThreads=2,Sharpness=1.2,SLMode=1) # result is double framerate progressive, so re-interlate it later
Lanczos4resize(NewWidth,NewHeight)
# Re-Interlace and halve framerate
AssumeTFF()
#Blur(0,0.5).SeparateFields().SelectEvery(4,0,3).Weave() #reinterlace - ASSUMED TFF HERE # BLUR(0,1) per http://forum.doom9.org/showthread.php?p=1488308#post1488308
Blur(0,1).SeparateFields().SelectEvery(4,0,3).Weave() #reinterlace - ASSUMED TFF HERE # BLUR(0,1) per http://forum.doom9.org/showthread.php?p=1488308#post1488308

Of course, you could try direct down-resizing :)
#PURE VERSION PER http://forum.doom9.org/showthread.php?p=1185790#post1185790
SeparateFields()
Shift = (GetParity() ? -0.25 : 0.25) * (Height()/Float(NewHeight/2)-1.0)
N = Spline36resize(NewWidth, Height())
E = N.SelectEven().Spline36resize(NewWidth, NewHeight/2, 0, Shift)
O = N.SelectOdd( ).Spline36resize(NewWidth, NewHeight/2, 0, -Shift)
Ec = N.SelectEven().Spline36Resize(NewWidth, NewHeight/2, 0, 2*Shift)
Oc = N.SelectOdd( ).Spline36Resize(NewWidth, NewHeight/2, 0, -2*shift)
Interleave(E, O)
IsYV12() ? MergeChroma(Interleave(Ec, Oc)) : Last
Weave()
AssumeTFF()
# NOW IT IS RE-SIZED AND STILL INTERLACED

edit: Oops just noticed you are up-resizing, disregard this.

[2Bdecided]

I'd just QTGMC the lot and keep it at 60p - but then, I've never noticed progressive content coming through QTGMC looking as bad as in your example. It's often visually benign (though not lossless).

Cheers,
David.

[mathmax]

I've never noticed progressive content coming through QTGMC looking as bad as in your example. It's often visually benign (though not lossless).

Did I make something wrong?


crop(0, 102, -0, -110)
AssumeTFF()
QTGMC()
LanczosResize(720, 480)
SeparateFields()
Selectevery(4,0,3)
weave()


If you'd let it at 60p, that won't be a DVD standard... to which format would you release it?

[Didée]

In any case, it should be wrong to crop 102 pixels from the top. When dealing with interlaced YV12 video, the bare minimum is to crop in mod4 steps from the top border. (Here: either 100 pixels, or 104 pixels. 102 is not divisible by 4.) When cropping is not mod4, you effectively get a phase-swap of chroma channels in interlaced sections.

However, that doesn't quite explain why the screenshots (thread page#1) look so poor for ALL the different variants. When bobbing a progressive source, then doing re-interlacing via separatefields.selectevery.weave, the results should not show combing all over the place. Instead, the result should look pretty progressive-ish again, even for the "simple" bob filters.

Maybe there is some fieldorder swapping going on during the process, though ATM I cannot see where or why that should happen.

[mathmax]

In any case, it should be wrong to crop 102 pixels from the top. When dealing with interlaced YV12 video, the bare minimum is to crop in mod4 steps from the top border. (Here: either 100 pixels, or 104 pixels. 102 is not divisible by 4.) When cropping is not mod4, you effectively get a phase-swap of chroma channels in interlaced sections.

However, that doesn't quite explain why the screenshots (thread page#1) look so poor for ALL the different variants. When bobbing a progressive source, then doing re-interlacing via separatefields.selectevery.weave, the results should not show combing all over the place. Instead, the result should look pretty progressive-ish again, even for the "simple" bob filters.

Maybe there is some fieldorder swapping going on during the process, though ATM I cannot see where or why that should happen.
Yes, now I understand why I should crop it in mod4 since I'm dealing with an YV12 interlaced source. Thank you for the explanations on the other thread. ;)

I tried everything with the code I posted in the preceding post.. but I couldn't figure out what's wrong on progressive frames... :(

I would be very nice if you could have a quick look on one of the samples I posted above:

very short one encoded with lagarith:
http://www.mediafire.com/?c1v3xib4mo1ggh2

longer demuxed sample:
http://www.mediafire.com/?3qk351mr691mvxm

Thank you again for your advices :)

[2Bdecided]

If you'd let it at 60p, that won't be a DVD standard... to which format would you release it?Oh, you're converting a letterboxed release to an anamorphic one, and putting it back onto DVD?

Most "professionals" would do the lot 60i, including some hard telecine in there for the 24p parts.

Some AVIsynth perfectionists might ensure the 24p parts are soft telecined instead.

Some clever modern encoders might spot the hard telecine and convert it to soft telecine automatically. Or did I dream this?

Cheers,
David.

[mathmax]

Oh, you're converting a letterboxed release to an anamorphic one, and putting it back onto DVD?
yes

Some clever modern encoders might spot the hard telecine and convert it to soft telecine automatically. Or did I dream this?
yes, but that requires to select the scenes manually.. right?

and do you have an idea why the screens I posted earlier were so bad? Do you see something wrong in the script I posted (except the crop by 102 px pointed out by Didée)?

[2Bdecided]

I don't know what happened with your earlier screen caps. Maybe you're showing us the re-interlaced result without deinterlacing again - rather than the intermediate progressive frames? A re-interlaced result will look strange on a PC without deinterlacing.

I couldn't get your second mediafire link to work, but from the first, a simple...
avisource("sample.avi")
assumetff()
qtgmc()was fine.

A basic...
avisource("sample.avi")
assumetff()
qtgmc()
nnedi2(field=0,dh=true)
spline36resize(720,356)
addborders(0,60,0,64)
assumetff().separatefields().selectevery(4,0,3).weave()should do what you want. It could be improved though.

Doing it this way, it's not easy to get back to any kind of proper telecine - the 3-2 pattern is broken, not in terms of field counts (it's still 3-2) but because the repeated field in the "3" isn't a perfect repeat - it's a very similar looking but not quite identical field, due to how QTGMC works in the first place. So I suspect that nothing in the world will recognise this as film (no DVD player, upscaler, TV etc).

Using TFM to keep the 3-2 parts perfect, while letting it automatically drop back to qtgmc for the rest, is a good solution for this if the 3-2 detection works OK. It won't be too obvious if it fails occasionally either.


The problem with quick and dirty is that, in this case, combined with a mere 33% increase in resolution (4x3 > 16x9), it might not look any better than the original. It might even look worse. Check the effect on the pure interlaced sections too.

Cheers,
David.

[mathmax]

Thank you for your answer David :)

I don't know what happened with your earlier screen caps. Maybe you're showing us the re-interlaced result without deinterlacing again - rather than the intermediate progressive frames? A re-interlaced result will look strange on a PC without deinterlacing.
Even if I deinterlace again the result will not be as good as the original progressive frame.. it sill doesn't look so neat.


I couldn't get your second mediafire link to work

Sorry.. I don't know why the link is dead. I reuploaded a package containing samples of the four cases I mentioned earlier:
1. 3:2 pulldown
2. progressive 29.97fps
3. true interlaced 29.97fps
4. 29fps with fields shifted : AtBb BtCb CtDb DtEb...

link: http://www.mediafire.com/?efeonkek9jds7jg


A basic...
avisource("sample.avi")
assumetff()
qtgmc()
nnedi2(field=0,dh=true)
spline36resize(720,356)
addborders(0,60,0,64)
assumetff().separatefields().selectevery(4,0,3).weave()should do what you want. It could be improved though.

I gives the almost the same result at I posted in the preceding page (see QTGMC screenshot). The quality is still far from the original progressive frame. What is nnedi2(field=0,dh=true) used for?
Why such method is so lossy? :(


Doing it this way, it's not easy to get back to any kind of proper telecine - the 3-2 pattern is broken, not in terms of field counts (it's still 3-2) but because the repeated field in the "3" isn't a perfect repeat - it's a very similar looking but not quite identical field, due to how QTGMC works in the first place. So I suspect that nothing in the world will recognise this as film (no DVD player, upscaler, TV etc).

yes but anyway, no player will recognize a 3-2 pattern without flags. Hard pulldown are always bobed and not inverted, right?


Using TFM to keep the 3-2 parts perfect, while letting it automatically drop back to qtgmc for the rest, is a good solution for this if the 3-2 detection works OK. It won't be too obvious if it fails occasionally either.

that means, I would let everything 29.97p. The deinterlaced section where qtgmc() will be applied won't be 59,95fps and the 3-2 pulldown now inverted won't be 24fps (they will contains dupes). Should I let this in such a state.. and then burn it into DVD even though that doesn't match any standard?


The problem with quick and dirty is that, in this case, combined with a mere 33% increase in resolution (4x3 > 16x9), it might not look any better than the original.

yes.. I wonder why it's so lossy to resize the separated aligned fields, even with the best bob filters :-/

[2Bdecided]

Thank you for your answer David :)


Even if I deinterlace again the result will not be as good as the original progressive frame.. it sill doesn't look so neat.


Sorry.. I don't know why the link is dead. I reuploaded a package containing samples of the four cases I mentioned earlier:
1. 3:2 pulldown
2. progressive 29.97fps
3. true interlaced 29.97fps
4. 29fps with fields shifted : AtBb BtCb CtDb DtEb...

link: http://www.mediafire.com/?efeonkek9jds7jgThey're far better samples, but my PC is wrecked at the moment. Still...

I gives the almost the same result at I posted in the preceding page (see QTGMC screenshot).The progressive-ish frames don't look nearly that bad here. Of course the interlaced ones look strange.

Though I see from your new samples that the middle 720x268 pixels really do represent the full 16x9, so your resizing is correct. The source aspect ratio of this video is completely wrong. If you capped it from a STB, cap it again with the output set for 16x9 TV or something. Very strange - it's letterboxed something that was already letterboxed.

What is nnedi2(field=0,dh=true) used for?To double the height nicely. It's an intelligent resize.

Why such method is so lossy? :(Upscaling never looks great, and upscaling a progressive source without checking it's progressive is worse.

yes but anyway, no player will recognize a 3-2 pattern without flags. Hard pulldown are always bobed and not inverted, right?No, some TVs happily recognise and reverse hard pulldown, and some DVD players do too (I believe - I live in a PAL country - I don't have to deal with this ****!).

that means, I would let everything 29.97p. The deinterlaced section where qtgmc() will be applied won't be 59,95fps and the 3-2 pulldown now inverted won't be 24fps (they will contains dupes). Should I let this in such a state.. and then burn it into DVD even though that doesn't match any standard?You could do that - but I meant create a 59.94p intermediate, and then interlace it. I'm not 100% sure how to do that though. Maybe someone else knows?

Even better, does anyone else know how to drop in sections of soft pulldown automatically only when needed into a mixed encode?

Cheers,
David.

[LocalH]

Those first screencaps look like the field parity was wrong on resizing, I've seen that error on TV before all over the place, especially in commercials.