Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 1st April 2011, 01:32   #561  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
Quote:
Originally Posted by -Vit- View Post
Didee's script can work with any bobber but it doesn't work out of the box, this is the intent:
Code:
...
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.
__________________
GScript and GRunT - complex Avisynth scripting made easier

Last edited by Gavino; 1st April 2011 at 01:34.
Gavino is offline  
Old 1st April 2011, 02:18   #562  |  Link
-Vit-
Registered User
 
Join Date: Jul 2010
Posts: 448
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:
Code:
# 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.

Last edited by -Vit-; 2nd April 2011 at 00:27.
-Vit- is offline  
Old 1st April 2011, 08:55   #563  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
Quote:
Originally Posted by -Vit- View Post
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.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline  
Old 1st April 2011, 10:24   #564  |  Link
hydra3333
Registered User
 
Join Date: Oct 2009
Location: crow-land
Posts: 540
Quote:
Originally Posted by Didée View Post
@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.ph...42#post1488542 with Gavino's width adjustment.

I see there's generally no benefit to a fancy deinterlacer when downsizing to a re-interlaced result.
hydra3333 is offline  
Old 1st April 2011, 19:26   #565  |  Link
-Vit-
Registered User
 
Join Date: Jul 2010
Posts: 448
I believe the "Shift" calculation in the above is incorrect, it should simply be:
Code:
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():
Code:
# 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()

Last edited by -Vit-; 1st April 2011 at 19:28.
-Vit- is offline  
Old 1st April 2011, 21:03   #566  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
Quote:
Originally Posted by -Vit- View Post
I believe the "Shift" calculation in the above is incorrect, it should simply be:
Code:
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.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline  
Old 1st April 2011, 22:59   #567  |  Link
SubJunk
Registered User
 
Join Date: Jun 2010
Posts: 443
Quote:
Originally Posted by jpsdr View Post
Just out of curiosity, have you tried the version here ?
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.
SubJunk is offline  
Old 2nd April 2011, 03:47   #568  |  Link
hydra3333
Registered User
 
Join Date: Oct 2009
Location: crow-land
Posts: 540
Um, wasn't there a discussion over a few pages, in 2008, on this stuff here http://forum.doom9.org/showthread.ph...90#post1185790 ?
hydra3333 is offline  
Old 2nd April 2011, 04:42   #569  |  Link
-Vit-
Registered User
 
Join Date: Jul 2010
Posts: 448
That was regarding resizing fields. The above is about resizing progressive frames into fields. Same principle, but require different sampling offsets.
-Vit- is offline  
Old 2nd April 2011, 14:41   #570  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
Quote:
Originally Posted by hydra3333 View Post
Um, wasn't there a discussion over a few pages, in 2008, on this stuff here http://forum.doom9.org/showthread.ph...90#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).
__________________
GScript and GRunT - complex Avisynth scripting made easier

Last edited by Gavino; 2nd April 2011 at 14:46.
Gavino is offline  
Old 7th April 2011, 20:07   #571  |  Link
egrimisu
Registered User
 
egrimisu's Avatar
 
Join Date: Jan 2008
Location: Romania - neighbor of Dracula
Posts: 327
should i use qtgmc for ivtc or it will not work?
__________________
I7 920 @ 3.60GHz + Thermalright Ultra 120 Extreme
Asus P6T Deluxe, 6GB Corsair XMS3 1600MHZ 8-8-8-24
2x1TB Samsung + 1x500GB Samsung,
Corsair 520W, Thermaltake Soprano DX
GeForge GTX280
egrimisu is offline  
Old 11th April 2011, 00:53   #572  |  Link
henryho_hk
Registered User
 
Join Date: Mar 2004
Posts: 889
Use a proper ivtc function for telecine materials.
henryho_hk is offline  
Old 11th April 2011, 18:43   #573  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: UK
Posts: 1,673
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.
2Bdecided is offline  
Old 11th April 2011, 20:12   #574  |  Link
-Vit-
Registered User
 
Join Date: Jul 2010
Posts: 448
This script (the basis for the related discussion above) is better than bob/blur for interlaced HD > interlaced SD resizing
-Vit- is offline  
Old 12th April 2011, 16:12   #575  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: UK
Posts: 1,673
Quote:
Originally Posted by -Vit- View Post
This script (the basis for the related discussion above) is better than bob/blur for interlaced HD > interlaced SD resizing
Hi Vit,

I'm well aware of that script (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.ph...77#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.
2Bdecided is offline  
Old 12th April 2011, 17:07   #576  |  Link
-Vit-
Registered User
 
Join Date: Jul 2010
Posts: 448
Quote:
Originally Posted by 2Bdecided View Post
I'm well aware of that script (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...

Quote:
Originally Posted by 2Bdecided View Post
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 I posted earlier gave better MT stability? Boulder made some encouraging noises, but has not come back yet...
-Vit- is offline  
Old 12th April 2011, 17:21   #577  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
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.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline  
Old 12th April 2011, 19:04   #578  |  Link
johnmeyer
Registered User
 
Join Date: Feb 2002
Location: California
Posts: 2,691
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.

Last edited by johnmeyer; 12th April 2011 at 20:28. Reason: corrected spelling errors
johnmeyer is offline  
Old 12th April 2011, 19:19   #579  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
Quote:
Originally Posted by johnmeyer View Post
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?
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline  
Old 12th April 2011, 19:49   #580  |  Link
-Vit-
Registered User
 
Join Date: Jul 2010
Posts: 448
Quote:
Originally Posted by Boulder View Post
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.
-Vit- is offline  
Closed Thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 12:16.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.