QTGMC Deinterlacing Script (v3.32)

[Boulder]

Thanks, I'll test the file as soon as my next crash occurs. I've been trying to bob Queen Live at the Wembley for at least fifteen times this evening, and having a long video with lots of motion doesn't help at all..It seems that the dll has a positive effect on stability. At least I was able to finish one encode in one go and the second one (the Queen b*****d) crashed once quite early on and after lowering the number of threads by one, has now been going on for over 3.5 hrs. Let's see if it finishes OK, it has 8 hours to go.

[-Vit-]

-Vit-, I ask you to distribute plugins archives "as is", with source codes and documentation (it is useful for end user and contains copyright).
Yes certainly, you only needed to ask.

sadie: I don't know how YUY has crept into your workflow, but your error is strange. You should have only got that Interleaved2Planar error if your source is YUY2 (or at least Avisynth thinks it is). And once you got the missing plugin, your clip should have been converted to the special planar YUY2 format that masktools has accepted since Alpha 34. Which begs the question: do you have an up to date masktools2? If you do then something odd is afoot and I'd like to see a sample of that clip...

[Gavino]

hydra3333: "QTGMC jaggies", grrrr... The problem was with your original reinterlacing script. The second script you're using does a better job of downscaled reinterlacing. However, it assumes an interlaced source. If you want to start from a progressive source (e.g. including one that you've bobbed) just replace the "SeparateFields()" line with "SeparateFields().SelectEvery(4,0,3)"

I.e. If you want to deinterlace first (for some temporal processing perhaps?) then your second script starts thus:

QTGMC(...settings...) #Or whatever bobber
SeparateFields().SelectEvery(4,0,3)
# rest of that second script

Isn't QTGMC(...).SeparateFields().SelectEvery(4,0,3) the same as (but much slower than) a simple SeparateFields()? (and with some quality loss, given the latter is lossless.)

Or are you saying it only makes sense to do this if you had some temporal processing between QTGMC and SeparateFields()?

What are your thoughts on my earlier question:
is there in fact any point in using (Q)TGMC for deinterlacing just in order to do an re-interlaced downsize? Would an 'inferior' but faster deinterlacer give equally good results, or do you still gain something from the temporal processing of (Q)TGMC?

[-Vit-]

Isn't QTGMC(...).SeparateFields().SelectEvery(4,0,3) the same as (but much slower than) a simple SeparateFields()? (and with some quality loss, given the latter is lossless.)
Er... yes... scratch that thought. Well, not quite, you do get temporal effects in the original fields as well as deliberate adjustments to help fit the interpolated fields (it's not quite "quality loss"). But that's only very marginally helpful.

I don't have time (nor, it would seem, the ability) to think about this deeply right now, but I had the gut feeling that something like that sub-pixel shifted rescale in the script above could be done on a progressive source. Then separate fields/weave on the reduced size image to give a more usable result. Kinda what I was hinting at at the end of that other post.

And I completely agree that there doesn't seem to be too much point doing elaborate bobbing. Maybe you might avoid certain aliasing in the result if you interpolate properly at the higher resolution?

[sadie]

Vit, your indulgence as always is appreciated. My problem was indeed linked to an update of ffdshow. Quite simply their internal DV decoder had become unchecked causing Windows to default to an unidentifiable (MS?) 3rd party codec (with its config menu in Chinese no less, always a good sign).Also, I've got Pinnacle, Canopus and DVCPro dv decoding filters in MPlayerC, but oddly can get none of them to kick in. Curious to know what decoder/encoder combo you show in MPlayer when opening the clip I posted a few weeks back. Anyway, now it's back to trying to get a Makeavis dummy file to open in Premiere/Pinnacle.

[yup]

Hi all!

I am from YUY2 world.
SeT 2.6 build + mt_masktools_26.dll do not work with YUY2 colorspace, error from masktools function mt_makedif, mt_masktools_25.dll and Vit modded dll work without problem.
SSE3Tools more unstable comparing to SSE2tools (VirtualDub crash when push Start button at job list, SSE2Tools work before 1.5 hour SD material), using save AVI work but for small clip.


yup.

[hydra3333]

hydra3333: "QTGMC jaggies", grrrr... The problem was with your original reinterlacing script. The second script you're using does a better job of downscaled reinterlacing. However, it assumes an interlaced source. If you want to start from a progressive source (e.g. including one that you've bobbed) just replace the "SeparateFields()" line with "SeparateFields().SelectEvery(4,0,3)"

I.e. If you want to deinterlace first (for some temporal processing perhaps?) then your second script starts thus:

QTGMC(...settings...) #Or whatever bobber
SeparateFields().SelectEvery(4,0,3)
# rest of that second script

Probably there's a simplification to be made to the remainder of the script in the progressive case, but it will do...

Huh ? It is an interlaced source. What was wrong with the 1st script to make you go grrrr ? This thread http://forum.doom9.org/showthread.php?p=1110741#post1110741 talks about re-interlacing from a double-framerate deinterlaced clip and I gathered SeparateFields().SelectEvery(4,0,3).Weave() was the way to reinterlace the double-framerate progressive clip which QTGMC produced. I also recall reading recommendations that resizing an interlaced clip is best done by deinterlacing it first and then reinterlacing after the resize.... which I did with QTGMC /resize/reinterlace.

[Didée]

@hydra - did you see my comment about colorizing a B/W picture, then printing it to a B/W printer? That was not a mere joke. That was an analogy.

For purposes of downscaling,
xdest = 720
ydest = 576 # or 480
Spline36resize(xdest,last.height)
Bob(newheight=ydest).SelectEvery(4,0,3).Weave()
does a pretty fair job. Anything more exhaustive will yield only marginal improvement.

For the (very rare) case of interlaced upscaling, like 576i -> 1080i, it's a completely different story.

Main point#1 is that an interlaced source has 50% of data missing (not considering lowpassing). QTGMC is a sophisticated method to interpolate those missing 50% as good as possible.
At the moment you do re-interlacing, you are throwing away 50% of the data again. Poof!

Main point #2 is the kind of de-interlacing used during playback of an interlaced stream. Most realtime deinterlacers are using rather "simple" methods, and therefore can't cope well with "sharp" interlaced sources. That's why lowpassing usually is done before re-interlacing. This makes the job for the deinterlacer much more easy, so even the most simple ones can deliver an acceptable result.

[kolak]

I still can't use QTGMC for HD sources. Got my new 12 core machine, but can't use it with QTGMC, because it's crashing all the time. Tried to move to 64bit, but couldn't make it working at all- Vdub could not understand incoming video.

Last thing which I did not try is avisynth 2.6- is it much more likely to work or not?

Thanks

[-Vit-]

yup: Thanks for that detail, that might partly explain sadie's problem. I'll investigate to see if there is anything I can do in the YUY2/avisynth 2.6 domain. The SSE2Tools info is useful, I didn't experience any issues but I haven't tested much YUY2. It makes sense since RemoveGrainSSE3 had problems around that time too.

kolak: Yes, you should try every Avisynth version. For HD input, if can be a good idea to start at 4 threads, 1 EdiThread and work up. Try my modded MaskTools above, see if it helps. I have a whole set of those modded plugins if people are finding them useful.

hydra3333: Just meaning to say that QTGMC doesn't create the jaggies in your original script, the subsequent statements do. If you started with a sharp progressive source instead of QTGMC you would get the same effect. Didee's script can work with any bobber but it doesn't work out of the box, this is the intent
[EDIT: This isn't correct - see later posts for correct script]:

xdest = 720
ydest = 576 # or 480
Spline36resize(xdest,last.height)
Bob(height=ydest/2).AssumeFieldBased().Weave()

and with QTGMC:

xdest = 720
ydest = 576 # or 480
Spline36resize(xdest,last.height)
QTGMC(...settings...).Spline36Resize(xdest,ydest/2).AssumeFieldBased().Weave()

Little difference if ydest is much smaller than the original height, and almost the same as any other working variant.

[Gavino]

Didee's script can work with any bobber but it doesn't work out of the box, this is the intent:
...
Bob(height=ydest/2).AssumeFieldBased().Weave()

That's not right, as it will produce incorrect field alignment.
The problem with Didee's script (apart from the incorrect parameter name newheight) is that it was missing a SeparateFields() - it should be:
Bob(height=ydest).SeparateFields().SelectEvery(4,0,3).Weave()

For the same reason, your edited code with QTGMC will also produce incorrect field alignment. Ironically, I was about to post to say that I agreed with the more complex code you first posted, until I found you had edited your post and deleted it.

[-Vit-]

Ah, yes I see what you mean. I was fooled by single stepping through the output of my "correction" (breaking) of Didee's script - the result had no aliasing and appeared to be the same as my complex version. So figured this solution was overkill. Didn't notice the field misalignment. Your correct correction of Didee's script leaves aliasing.

So this more complex script performs cleaner interlacing for progressive (or bobbed) input:

# Progressive input here

NewWidth=720
NewHeight=576

Shift = -0.5 * Height() / Float(NewHeight) # Change to +0.5 if you want BFF output
Spline36Resize( NewWidth,Height() )
E = Spline36Resize( NewWidth,NewHeight/2, 0, Shift )
O = Spline36Resize( NewWidth,NewHeight/2, 0,-Shift )
Ec = IsYV12() ? Spline36Resize( NewWidth,NewHeight/2, 0, 2*Shift ) : NOP()
Oc = IsYV12() ? Spline36Resize( NewWidth,NewHeight/2, 0,-2*shift ) : NOP()

Interleave( E, O )
IsYV12() ? MergeChroma(Interleave( Ec, Oc )) : last

AssumeFieldBased().AssumeTFF() # Or BFF
SelectEvery( 4, 0,3 ).Weave()

[Edited to include Gavino's tweak and my fix from the posts below]

You're still at the mercy of your playback deinterlacer on the final result though. QTGMC will happily deinterlace the output of this script and produce a clean result, but a hardware deinterlacer might not.

[Gavino]

So this more complex script performs a cleaner downscaled reinterlace for progressive or bobbed input
That looks right.
A minor speed improvement would be to factor out the horizontal resizing to be done once only, by adding Spline36Resize(NewWidth, Height()) before doing the others.

It's interesting that if you set NewHeight=Height(), the process reduces to pure interlacing without a resize.
In this case, your script replaces the conventional SeparateFields().SelectEvery(4,0,3).Weave().
At first sight, this seems to be wrong, or at best a terrible waste of time, but arguably it is more theoretically correct since by using a downsizer to construct the fields, you automatically include the necessary lowpass filtering.

[hydra3333]

@hydra - did you see my comment about colorizing a B/W picture, then printing it to a B/W printer? That was not a mere joke. That was an analogy. ...

Main point#1 is that an interlaced source has 50% of data missing (not considering lowpassing). QTGMC is a sophisticated method to interpolate those missing 50% as good as possible.
At the moment you do re-interlacing, you are throwing away 50% of the data again. Poof!

Main point #2 is the kind of de-interlacing used during playback of an interlaced stream. Most realtime deinterlacers are using rather "simple" methods, and therefore can't cope well with "sharp" interlaced sources. That's why lowpassing usually is done before re-interlacing. This makes the job for the deinterlacer much more easy, so even the most simple ones can deliver an acceptable result.

Thanks. and to -Vit- and Gavino. I think I'll move to the script here http://forum.doom9.org/showthread.php?p=1488542#post1488542 with Gavino's width adjustment.

I see there's generally no benefit to a fancy deinterlacer when downsizing to a re-interlaced result.

[-Vit-]

I believe the "Shift" calculation in the above is incorrect, it should simply be:
Shift = -0.5 * Height() / Float(NewHeight)
I took the original formula from the script posted earlier, but it is inappropriate for this case .

In fact the script above is really just a rewrite of SeparateFields() so it is better presented that way. This is a new function SeparateFieldsMod():

# Separates frame-based material into fields using a resizer rather than simply dropping alternate lines.
# The resize effectively performs a vertical low-pass to produce result that will interpolate more easily
# May output with different dimensions. Note that NewHeight refers to the frame height, not the field height
# E.g. given progressive HD input, interlace to SD like so: SeparateFieldsMod(720,480).SelectEvery(4,0,3).Weave()

function SeparateFieldsMod( clip c, int "NewWidth", int "NewHeight" )
{
Assert( c.IsFrameBased(), \
"SeparateFieldsMod: SeparateFieldsMod should be applied on frame-based material: use AssumeFrameBased() beforehand" )
Assert( !c.IsYV12() || c.Height()%4 == 0, "SeparateFieldsMod: YV12 height must be multiple of 4" )
Assert( c.Height()%2 == 0, "SeparateFieldsMod: height must be even" )

NewWidth = default( NewWidth, c.Width() )
NewHeight = default( NewHeight, c.Height() )

shift = (c.GetParity() ? -0.5 : 0.5) * c.Height() / Float(NewHeight)
c.Spline36Resize( NewWidth,c.Height() )
e = Spline36Resize( NewWidth,NewHeight/2, 0, shift )
o = Spline36Resize( NewWidth,NewHeight/2, 0,-shift )
ec = c.IsYV12() ? Spline36Resize( NewWidth,NewHeight/2, 0, 2*shift ) : NOP()
oc = c.IsYV12() ? Spline36Resize( NewWidth,NewHeight/2, 0,-2*shift ) : NOP()

Interleave( e, o )
c.IsYV12() ? MergeChroma(Interleave( ec, oc )) : last

AssumeFieldBased()
return c.GetParity() ? AssumeTFF() : AssumeBFF()
}


SeparateFieldsMod() does the same as SeparateFields(), but with a low-pass to allow easier interpolation when deinterlacing.
Can resize the output fields by passing new frame size: SeparateFieldsMod( 720, 480 )
Rescaling progressive to interlaced takes the expected form: SeparateFieldsMod( 720,480 ).SelectEvery(4,0,3).Weave()

[Gavino]

I believe the "Shift" calculation in the above is incorrect, it should simply be:
Shift = -0.5 * Height() / Float(NewHeight)
I took the original formula from the script posted earlier, but it is inappropriate for this case.
Yes, well spotted. Here you are starting from progressive and resizing a framebased clip with different offsets to extract top and bottom fields. The earlier script (in whose origins I had a hand) starts from an interlaced clip, separates it and resizes as fieldbased, which requires a different pair of offsets.

I didn't think of that when I looked at your earlier version. I used the case of NewHeight=Height as a sanity check, which worked. For that case, both the wrong formula and the right one produce the same result, so I didn't notice the error.

[SubJunk]

Just out of curiosity, have you tried the version here (http://xhmikosr.1f0.de/index.php) ?I finally got around to comparing that version with SET's 2.6.

XhmikosR's AviSynth_258_MT_MSVC2010 (27 March 2011 build): 41.414fps
SET's 2.6: 41.878fps

Those are averages from 5 tests per build.
In other words there seems to be no advantage in using XhmikosR's builds, and over 1% speed increase from using SET's.
This is in keeping with my previous tests of XhmikosR's builds of things, generally they perform slower than any other builds for me. But I am on a modern system so maybe his are more optimised for old computers, I'm not sure.

[hydra3333]

Um, wasn't there a discussion over a few pages, in 2008, on this stuff here http://forum.doom9.org/showthread.php?p=1185790#post1185790 ?

[-Vit-]

That was regarding resizing fields. The above is about resizing progressive frames into fields. Same principle, but require different sampling offsets.

[Gavino]

Um, wasn't there a discussion over a few pages, in 2008, on this stuff here http://forum.doom9.org/showthread.php?p=1185790#post1185790 ?
Ah, that thread brings back memories. :)
I was a fairly naive newbie then and learned a hell of a lot about both interlacing and resampling, which has served as the basis of my understanding ever since (still learning, of course).

[egrimisu]

should i use qtgmc for ivtc or it will not work?

[henryho_hk]

Use a proper ivtc function for telecine materials.

[2Bdecided]

There really is no point using anything beyond bob() for interlaced HD > interlaced SD resizing. As Didée said, you need more blur, not more sharp! ;)

e.g...

blur(0.0,1.0)
sharpen(0.0,0.5)

...before re-interlacing.

Cheers,
David.

[-Vit-]

This script (http://forum.doom9.org/showthread.php?p=1185790#post1185790) (the basis for the related discussion above) is better than bob/blur for interlaced HD > interlaced SD resizing

[2Bdecided]

This script (http://forum.doom9.org/showthread.php?p=1185790#post1185790) (the basis for the related discussion above) is better than bob/blur for interlaced HD > interlaced SD resizingHi Vit,

I'm well aware of that script (http://forum.doom9.org/showthread.php?p=1161524#post1161524) ;) (an even earlier version).

I'm not about to discuss what's best ;) but it seem to me that wiping away all the detail above half-height (and some below that, since no resizer is perfect) makes interlacing utterly pointless. You might as well just have 240p60 or 288p50; these options would have been trivial in 1936 (first interlaced broadcasts), 1941 (NTSC) and later (PAL), but interlacing was used instead.

What looks nicest to you is entirely subjective, but I've tried most possible solutions for putting my HDV footage onto PAL DVD and watching via a CRT, and...
http://forum.doom9.org/showthread.php?p=1171877#post1171877
...YMMV!

My current experience is that it matters even less than I thought at that time because the final interlaced SD MPEG-2 encoding of typical home movies (i.e. lots of movemen) trashes the quality so much.

Cheers,
David.

[-Vit-]

I'm well aware of that script (http://forum.doom9.org/showthread.php?p=1161524#post1161524) ;) (an even earlier version).
It's tough being a novice here (yes, I am that). So many old threads discussing almost everything, hard to know/find it all...

I'm not about to discuss what's best ;)
Point taken. So more correctly put, that script is less likely to produce aliasing but will give a softer result. I much prefer it for the sample posted in this thread earlier, but I otherwise rarely deliberately interlace (yuk!) so I don't really have a strong preference...

___

On a totally different point, has anyone an opinion on whether that masktools variant (http://forum.doom9.org/showpost.php?p=1488378&postcount=543) I posted earlier gave better MT stability? Boulder made some encouraging noises, but has not come back yet...

[Boulder]

Based on around 10 encodes of variable length and variable filters (all scripts utilizing MaskTools in some way), the stability is somewhat better on my system. I get occasional crashes but not as often as I used to, and MaskTools is rarely pointed out as the one which has been doing something when the crash occurs. Though it's more like the buggy caching/memory handling causing the actual crash.

[johnmeyer]

I spent quite a bit of time yesterday with the script that -Vit- linked to, and compared resizing 1440x1080 interlaced footage from my FX1 camcorder down to NTSC 720x480 interlaced. I agree with what -Vit- says in the post immediately above, namely that it produces less aliasing. However, in all other respects it fails to preserve detail that it should be able to hang onto. I spent several hours tweaking, and creating other scripts on my own. In the end, I got much better results using the resizing built into my editing program, Sony Vegas. Using this tool, I created (and have been doing so for almost five years) NTSC interlaced DVDs that look great on both my old Sony WEGA CRT monitor and on my new Samsung LED LCD 55" display.

As someone who has written a lot of software that deals with interlaced material, I understand very well all the issues involved. If handled properly, interlaced material looks great on all my equipment and, compared to anything except for 60p, provides the best temporal/spatial combination of anything I can create. I have the option, via ESPN3, to watch sports in 24p via my Xbox 360, but I'd much rather watch on my SD satellite connection which broadcasts 480i. This is personal preference, obviously, but the point is that I have never seen any artifacts in a properly handled interlaced video, whereas I see all sorts of artifacts with temporally degraded video, especially when watching sports, which is non-stop movement (unless you watch a lot of golf ...).

As to whether halving the vertical resolution and providing a progressive display would have been a better move when TV was first invented, I'm afraid that would not have produced a better result. First, it is based on the incorrect assumption that you don't get any benefit from the odd (or even) scan lines when the signal is interlaced. Maybe that is not what is being said, so I apologize if I didn't understand correctly. When you look at the analog video signal (which is the only correct way to look at it, since digital video didn't happen for another half century), the 468 lines that make up the picture each contribute to the details.

Finally, people who are a lot smarter than me -- and smarter than anyone in this forum -- worked together during the late 1980s to invent HD television, and then again in the early 1990s when they re-defined it to make it digital (the original HD spec was analog). These very smart people not only included interlaced video in the spec, but made it the pinnacle of the quality ladder (1080p was added later). They did this partly because TVs in the early 1990s were still based on scanning CRT technology, but also because interlaced TV looks darned good. Yes, I know that some of you are going to disagree with that (my assertion that interlaced video looks good), but I'll bet that if you took 100 people who never edited one second of video in their life, and put them in front of a TV that could display interlaced video natively, not one of them would complain about video quality.

Yes, I know that most modern sets no longer display interlaced video natively (although there is no reason that cannot change), but all of them have the ability to handle interlaced video and if you've got a decent set, the results look great.

[Gavino]

In the end, I got much better results using the resizing built into my editing program, Sony Vegas.
Interesting - do you know what resizing algorithm it uses?
Does it have a specific interlaced resize operation, or do you have to deinterlace first and re-interlace after resizing?

[-Vit-]

Based on around 10 encodes of variable length and variable filters (all scripts utilizing MaskTools in some way), the stability is somewhat better on my system. I get occasional crashes but not as often as I used to, and MaskTools is rarely pointed out as the one which has been doing something when the crash occurs. Though it's more like the buggy caching/memory handling causing the actual crash.
Thanks Boulder. Each plugin you use needs that treatment, so you may get further benefit from other tweaked versions. I'll provide a set later.

[johnmeyer]

Interesting - do you know what resizing algorithm it uses?
Does it have a specific interlaced resize operation, or do you have to deinterlace first and re-interlace after resizing?Vegas Pro has two re-sizing options: bilinear and bicubic. I used bicubic for my tests.

The deinterlacing/re-interlacing required for proper re-sizing of interlaced material is not explicitly exposed to the user in Vegas Pro, but it obviously is being done "under the covers."

BTW, I have three versions of Vegas Pro installed (7.0d, 8.0c, and 10.0a). I used 8.0c for my tests.

Some posters in the Sony Creative Software forum have complained about the quality of Vegas' SD (for DVD) MPEG-2 interlaced video created from HD interlaced sources. As usual, some of those posters are just using the wrong settings. However, the two legitimate complaints are too much staircasing on diagonal lines, and video that looks soft compared to video shot natively in SD (480i) format. In my extensive tests the last few days, I did resizing using various deinterlace -> resize -> reinterlace scripts (including one that deinterlaced and frame doubled) and then looked at the result one field at a time. The Vegas fields definitely had more jaggies than the AVISynth scripts produced. However, these jaggies were on field lines, and therefore when viewed on moving video rather than still frames (and I always have to remind myself that looking at still images of interlaced material is always an invitation to draw incorrect conclusions), they are going to look OK.

The complaint about softness has more to do, I think, with expectations set by years of watching over-sharpened SD video.

What was much more interesting was the amount of detail lost by the AVISynth approaches. I posted pics over in the Sony forum. Here they are. The first is a very small portion of one field from the 720x480 video that resulted from scaling a 1440x1080 interlaced video from my Sony FX1:

http://i177.photobucket.com/albums/w208/johnmeyer/VegasHDtoSD.png

Here is the same frame, scaled using the AVISynth script, shown below (your code I believe :)). This is a ballerina in the middle of a fast pirouette:

http://i177.photobucket.com/albums/w208/johnmeyer/AVISynthHDtoSD.png

As you can see (by the blue arrows), there is a lot more detail preserved by the Sony resize. These images are small on my browser, so you may have to right-click and save them to your computer so you can blow them up and see for yourself.

The following is the code I used for the re-size tests, although I also used the much simpler version without the somewhat broken (in 2.6MT) ConvertToYV12() conversion and without the chroma shift code. I also tried using QTGMC deinterlacing, using the frame doubling option, and then re-sized and re-interlaced. The results were virtually identical to what I got with the various other options.

#Re-size function
#ConvertToYV12 function has problems depending on version of AVISynth used.
source=AVISource("e:\frameserver.avi").converttoyv12(interlaced=true).assumetff()
IResize(source,720,480).swapfields().assumebff().separatefields()

function IResize(clip Clip, int NewWidth, int NewHeight) {
Clip
SeparateFields()
Shift=(GetParity() ? -0.25 : 0.25) * (Height()/Float(NewHeight/2)-1.0)
E = SelectEven().Spline36resize(NewWidth, NewHeight/2, 0, Shift)
O = SelectOdd( ).Spline36resize(NewWidth, NewHeight/2, 0, -Shift)
Ec = SelectEven().Spline36Resize(NewWidth, NewHeight/2, 0, 2*Shift)
Oc = SelectOdd( ).Spline36Resize(NewWidth, NewHeight/2, 0, -2*shift)
Interleave(E, O)
IsYV12() ? MergeChroma(Interleave(Ec, Oc)) : Last
Weave()
}

[nhope]

The deinterlacing/re-interlacing required for proper re-sizing of interlaced material is not explicitly exposed to the user in Vegas Pro, but it obviously is being done "under the covers."

This brief article (http://www.custcenter.com/app/answers/detail/a_id/334) says that for the "Full resolution rendering quality" setting in Vegas Pro, "Best" uses bicubic scaling with integration, while "Good" uses bilinear without integration.

Does anyone know what "integration" might mean in this context? It may be significant.

[Didée]

@ johnmeyer: small sample? Without knowing where it started from, it's hard to draw conclusions. Moreover, it's doesn't seem feasable that with QTGMC+reinterlacing you got the same detail loss as from the plain fieldbased resize...


Dropping a thought about it ... if you're interested in producing an interlaced result, and want to minimize the downsides of lowpassing, two basic approaches are obvious:

a) be motion adaptive: only moving areas are the main target for lowpassing

b) make an spatio-temporal alias: produce a lowpass, and produce a temporal average. From the lowpass, use only that change that is "confirmed" by the difference caused by the temporal filter.


Clear? It's not so that everything has to be lowpassed. There are certain structures that might need lowpassing. And I could swear to have suggested such an adaptive approch years ago. (But my interest never lied in producing interlaced results, hence nothing was fleshed out.):)

[johnmeyer]

@ johnmeyer: ... it's doesn't seem feasable that with QTGMC+reinterlacing you got the same detail loss as from the plain fieldbased resize...Thank you, thank you, thank you Didée for posting. Because I respect your opinion so much, it forced me to go back and re-do the QTGMC testing from yesterday. This time, I broke it down into smaller steps and found two errors: one with the re-interlacing (simple, but I blew it anyway) and one with the codec choice.

As you expected, the code below does provide better results than Vegas, and actually provides really fantastic results, if your goal is to take interlaced HD and produce great looking interlaced SD. I compared the uncompressed results with what I get with various codecs and found that the quality of the result really shows ALL the flaws in each codec. Obviously this is nothing surprising to readers on this forum, but my point is that this provides about the highest level of detail these SD codecs (like DV codecs) ever have to deal with.

So, be careful what codec you use, or you can throw away some of the detail that you worked to hard to preserve.

#Script to re-size from HD to SD using deinterlace/framedouble - resize - followed by re-interlace
loadplugin("C:\Program Files\AviSynth 2.5\plugins\MVTools\mvtools2.dll")
loadplugin("C:\Program Files\AviSynth 2.5\plugins\RemoveGrainSSE2.dll")
loadplugin("C:\Program Files\AviSynth 2.5\plugins\SSE3Tools.dll")
loadplugin("C:\Program Files\AviSynth 2.5\plugins\mt_masktools-25.dll")
Import("E:\Documents\My Videos\AVISynth Scripts\QTGMC-3.31.avsi") #

AVISource("e:\frameserver.avi").assumetff()

QTGMC( Preset="Very Fast", FPSDivisor=1, EdiThreads=0, ShowSettings=false ) #use for 60p output

LanczosResize(720,480)
separateFields()
#SelectEvery(4,0,3) #BFF
SelectEvery(4,1,2) #TFF
Weave()

[nhope]

As a test, I'm trying to run this file (http://www.jazzythedog.com/testing/videos/AVCHD.zip) (not mine) through a single-threaded variant of johnmeyer's script for subsequent encoding to MPEG-2 with CCE Basic for DVD. Here's my script:

DirectShowSource("D:\My Videos\Amendegw-AVCHD.MTS")
ConvertToYV12(interlaced=true)
AssumeTFF
LanczosResize(720,height)
QTGMC( Preset="faster" )
LanczosResize(width,480)
separateFields()
SelectEvery(4,1,2) #TFF
Weave()

However I'm getting errors. CCE tells me "Frame size 852 x 56 is not supported". If I drag the script into MeGUi it tells me "Source image is too small for this resize method. Width=1 Support=3". I get no such trouble with a 1440x1080 60i HDV file. Anyone know what I'd have to do to get it working in AviSynth? I messed around with tsMuxeR a bit but no joy, and I also tried adding "audio=false". I have Haali Splitter installed.

Mediainfo on the file:

General
ID : 0 (0x0)
Complete name : D:\My Videos\Amendegw-AVCHD.MTS
Format : BDAV
Format/Info : Blu-ray Video
File size : 24.7 MiB
Duration : 13s 500ms
Overall bit rate : 15.4 Mbps
Maximum Overall bit rate : 18.0 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Codec ID : 27
Duration : 13s 430ms
Bit rate mode : Variable
Bit rate : 14.5 Mbps
Maximum bit rate : 16.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.233
Stream size : 23.2 MiB (94%)

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Codec ID : 129
Duration : 13s 536ms
Bit rate mode : Constant
Bit rate : 256 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Delay relative to video : -67ms
Stream size : 423 KiB (2%)

[Didée]

"Frame size 852 x 56" suggests that Avisynth is returning an error message clip. Something is not in order, maybe you're missing a plugin, or something.

Open your script in VirtualDub, there you can see the error message.

BTW - ouch, that clip is evil.:scared: :D

[2Bdecided]

And I could swear to have suggested such an adaptive approch years ago. (But my interest never lied in producing interlaced results, hence nothing was fleshed out.):)You did - but letting high frequencies through when nothing moves is still going to allow horrible twitter on CRTs. It'll be OK on progressive displays with adaptive deinterlacers (assuming they work quickly).

Lots of things already work together to create a still=sharp moving=blurred effect; this is already objectionable (IMO) on many modern displays and low bitrate encodes. I think adding another intentional stage with this effect is just too much!

However, it could effectively combat the aliasing that sometimes occurs when something moves. Adapting like this might be the lesser of two evils for some people.

Cheers,
David.

[2Bdecided]

@johnmeyer

This code you suggest (http://forum.doom9.org/showthread.php?p=1492046#post1492046) has no filtering at all, and will flicker like mad on a CRT. It'll bob quite a lot during any motion on most progressive displays too.

I know - I've tried it. It's unbearable (IMO). And, as you say, very difficult to encode (lots of high frequencies and aliasing).

Cheers,
David.

P.S. IMO(!) that is not a good way to switch between TFF and BFF when re-interlacing - you should always use selectevery(4,0,3), but put assumetff() or assumebff() before it. Otherwise the output depends entirely on what field order AVIsynth thinks exists at that point - which will change with different functions, sources, etc, making the whole thing very easily broken - leading you to a big headache!

[nhope]

Thanks Didée. Same error in VirtualDub as in MeGUi. "AviSynth Open Failure: Resize: Source image is too small for this resize method. Width=1, Support=3". And then it refers to the first LanczosResize line. I have AviSynth 2.5.8 ST. I would be interested in knowing if anyone can get that file running sucessfully through a script such as mine.

Edit: By the way, if anyone is interested in the origin of that file and test, it's here (http://www.sonycreativesoftware.com/forums/ShowMessage.asp?MessageID=738210).

[2Bdecided]

Finally, people who are a lot smarter than me -- and smarter than anyone in this forum -- worked together during the late 1980s to invent HD television, and then again in the early 1990s when they re-defined it to make it digital (the original HD spec was analog). These very smart people not only included interlaced video in the spec, but made it the pinnacle of the quality ladder (1080p was added later). They did this partly because TVs in the early 1990s were still based on scanning CRT technology, but also because interlaced TV looks darned good.They did it for the same reason it was introduced in the 1930s - to increase the resolution without increasing the raw or encoded bandwidth to match.

Some of the original analogue HD formats weren't interlaced in the traditional sense - they had something far more evil (sometimes called dot interlacing).

Interlacing doesn't make any sense in the context of progressive displays or efficient codecs - never mind both. But we are where we are - and whether codecs are really so efficient as to make interlacing redundant is still up for debate (according to some).

Cheers,
David.

[Didée]

@ nhope: Can't tell what's up with that file, but something is not quite right with it. Slightly older versions of ffmpegsource crash right away with it. The most recent version can decode it, but the field/frame order is somehow not correct: everything is choppy, with some forward/backward/jump issues, ...
However, I have no problems with DGDecodeNV, this one decodes the file without problem. (And on my system, it is also correctly decoded by directshowsource ... but DSS is whacky, as you have experienced. Each system is unique in regard to DirectShowSource....)

In any case, the file is flagged with wrong field order. All tools report it to be TFF, but I need ComplementParity() to switch it over to BFF. Only then the field/frame sequence after bobbing is correct.

Funky file to make a challenge with. Seems the challenge is not so much how to get a good result ... the real challenge is to get the darn input file opened correctly in the first place! :rolleyes: :D

[nhope]

Thanks for looking into it. It's not that important. If I do an AviSynth-based test with it I'll probably put it in Vegas and frameserve out and accept the couple of conversion to RGB and back along the way. By the way, the owner tells me it's straight from his Canon HG21 recording in 1920x1080 60i, FXP (17Mbps) mode. Apologies for rather derailing the thread.

[johnmeyer]

They did it for the same reason it was introduced in the 1930s - to increase the resolution without increasing the raw or encoded bandwidth to match. ...Yes, that is exactly the reason.

Interlacing doesn't make any sense in the context of progressive displays or efficient codecs - never mind both. But we are where we are - and whether codecs are really so efficient as to make interlacing redundant is still up for debate (according to some).Once again, I agree completely.

However, the second sentence is the reason I responded. If you think back to the early 1990s, we were still using 486 computers, and "DSPs" were the only way to handle even the most rudimentary calculations related to video. Now, almost exactly twenty years later, with multiple cores and processor architecture that includes native instructions for handling media, we can finally deal with 1080p, although real-time performance for displaying this level of video has only happened in the past few years, and editing and encoding is usually far from real time (obviously depends on ... fill in the blank).

I will be the first to cheer the final demise of interlacing, but since we have so much legacy material that will be with us forever (I still play my 78 rpm records), I wish we could buy an LCD display that could handle interlaced material natively. For the life of me I do not understand why a line-addressable LCD display could not be built. This would provide a partial solution for displaying interlaced material. Some have said that this couldn't work because LCD persistence is different than CRT phosphors, but that I think that could be simulated using the same technology used in my "local dimming" Samsung LED LCD.

But, as I said, I agree with everything you said above.

[amendegw]

@ nhope: Can't tell what's up with that file, but something is not quite right with it. Slightly older versions of ffmpegsource crash right away with it. The most recent version can decode it, but the field/frame order is somehow not correct: everything is choppy, with some forward/backward/jump issues, ...
However, I have no problems with DGDecodeNV, this one decodes the file without problem. (And on my system, it is also correctly decoded by directshowsource ... but DSS is whacky, as you have experienced. Each system is unique in regard to DirectShowSource....)

In any case, the file is flagged with wrong field order. All tools report it to be TFF, but I need ComplementParity() to switch it over to BFF. Only then the field/frame sequence after bobbing is correct.

Funky file to make a challenge with. Seems the challenge is not so much how to get a good result ... the real challenge is to get the darn input file opened correctly in the first place! :rolleyes: :D

I guess I should register present here... that's my file & my camcorder. Canon HG21 1920x1080 60i FXP mode. The clip is straight out of the camera. The only change I made was to rename it from 00003.mts to AVCHD.mts.

Is there anything else I can do to resolve the problem? Maybe someone else with a HG20/21 (or similar a similar vintage Canon) can shoot a clip in the FXP mode and see if it displays the same funkiness.

...Jerry

[johnmeyer]

@ nhope: Can't tell what's up with that file, but something is not quite right with it ... the file is flagged with wrong field order. All tools report it to be TFF, but I need ComplementParity() to switch it over to BFF. Only then the field/frame sequence after bobbing is correct.Interesting that you too had problems with field order. I spent some time this morning on this test file, and posted the results in the Sony forum. I didn't bother to mention it there, but I've seldom had so much trouble with field issues. Very strange.

As for results, I tried the QTGMC deinterlace/frame double --> resize --> reinterlace approach that I posted earlier and that Nick is trying to duplicate. With this pathological test case (it really is a devilishly brutal test clip), the QTGMC approach totally failed: the resulting 720x480 file was nothing but obnoxious moiré patterns. By contrast, the resizing script (http://forum.doom9.org/showthread.php?p=1185790#post1185790) that was the result of a long discussion about resizing YV12 content a few years ago did a remarkable job of resizing this content. I created an interlaced 720x480 widescreen DVD MPEG-2 file from the result, created a DVD, and then displayed this DVD on my 30" Sony WEGA CRT, and it displayed with no appreciable artifacts whatsoever.

[Didée]

I guess I should register present here...
Hello! So it took only one and a half year until you made your 1st post? Not bad!;)

Frankly, I've only little clue about the "particularities" of Camcorder files/formats. It's just when you have a standard like AVC, it's a bit baffling when a usually well-working tool suddenly falls apart into pieces. Makes you wonder. :confused:


... the QTGMC approach totally failed: the resulting 720x480 file was nothing but obnoxious moiré patterns.
A good tool doesn't hinder you to use it badly. :)

1080i60 > TGMC > 480p60: http://www.mediafire.com/?djjcd5c88e2alqg

Lowpass-reinterlaced to 480i60: http://www.mediafire.com/?7d5fun3wiyjmep0

Ooops, sorry, I forgot to set the AR flag. Please set your player manually to 16:9. :D


Script ...
SetMTmode(5,4)
DGSource("X:\AVCHD.dgi")
changefps(last,last,true)
complementparity()

setmtmode(2)
tempgaussmc_beta2a(1,1,1,nsize=5,sharp=1,sharpness=0.0,svthin=0.0,sbb=0)

# -- >here< is a good point to save an intermediate Huffy or Laggy or FLV-y -- ;-)

bicubicresize(1440,960)
bicubicresize(720,960,-.8,.6)

p1 = bicubicresize(720,480,-.8,.6)

p2 = p1.QTGMC(1,1,2,inputtype=1)

p2.blur(0,1).sharpen(0,.51).blur(0,1).sharpen(0,.85)

i1 = assumetff().separatefields().selectevery(4,0,3).weave()

# p1 # straight to 60p
# p2 # plus more calmed
i1 # re-interlaced p2

return(last)

[sadie]

Speaking of strange source clips, I've come across a Japanese ntsc music video that is hardly catholic. https://rapidshare.com/files/457285734/KibSok_cut.avi for a 1 min segment.

It looks to be an ntsc tv capture and an attempted progressive divx encode but where someone forgot to turn off the interlace switch. The 4700 kbps is a giveaway it was handled by someone even more amateurish than myself. The trouble is that when QTGMC gets its mitts around it various sequences will show 'morphing' or stretching of facial features and such. As if the temporal smoothing is really having to work overtime (?) Very disagreeable.

I'm trying to overlay this into a timeline with standard Pal DV material so I've upscaled it and converted the FPS along the way, but even without, the deinterlacing is the stage that is either creating or emphasizing this phenomenon. If I import the video untouched into the NLE (Pinnacle 15), the resulting export (DV or Mpeg2) surprisingly reduces the issue to a minimum but the result is rather less detailed (as well as interlaced) than what QTGMC would give. I've tried throwing the job at Yadif, but no banana there either.

In short, is there a genial fix or is that cute little kawaii singer fit for the trash bin? Thanks.

[johnmeyer]

A good tool doesn't hinder you to use it badly. :)Das ist richtig.

Earlier in this thread, I showed the script I used:

QTGMC Deinterlace/FrameDouble-->Resize-->Reinterlace (http://forum.doom9.org/showthread.php?p=1492046#post1492046)

I tried various other QTGMC presets, but still did not achieve satisfactory results. This is an excellent tool, but even by AVISynth standards, has an unusually large number of optional parameters. Would you perhaps be willing to share what settings you used for this particular clip? Over at the Sony Vegas forum, about a year ago, several dozen people tried to resize this clip, and your result is certainly one of the best results of those I have seen.

[amendegw]

Hello! So it took only one and a half year until you made your 1st post? Not bad!;)


Das ist, weil mein Nachname ist "am Ende". :) Actually, I've been a "lurker".

...Jerry (who's almost always "at the end") :)

Oh, and one more thing, if this is helpful. I just captured another clip. This time using a Panny TM700. It's here if anyone is interested: http://www.jazzythedog.com/testing/videos/TM700-60i.zip

And, I compared the MediaInfo stats on the Canon & Panasonic:

http://dl.dropbox.com/u/20447760/MediaInfoCompares.png

[sadie]

A quick follow-up to myself. I've tried to run the clip through Assume TFF/BFF().SeparateFields() with indifferent results (normal since this is after all a 'progressive clip'.) But both do show the distinctive signs of a field order problem (forward & back then forward again). The question remains: how to clean this up if possible?