QTGMC Deinterlacing Script (v3.32)

[johnmeyer]

Originally Posted by Gavino

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:



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:



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]

Originally Posted by johnmeyer

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 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]

Originally Posted by Didée

@ 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 (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.

[2Bdecided]

Originally Posted by Didée

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 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.

[2Bdecided]

Originally Posted by johnmeyer

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!

[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]

Originally Posted by 2Bdecided

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.

Originally Posted by 2Bdecided

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]

Originally Posted by 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!

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]

Originally Posted by Didée

@ 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 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]

Originally Posted by amendegw

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.

Originally Posted by johnmeyer

... 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.


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]

Originally Posted by Didée

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

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]

Originally Posted by Didée

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:

[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?