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. |
1st April 2011, 01:32 | #561 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
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. Last edited by Gavino; 1st April 2011 at 01:34. |
|
1st April 2011, 02:18 | #562 | Link |
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() 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. |
1st April 2011, 08:55 | #563 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
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. |
|
1st April 2011, 10:24 | #564 | Link | |
Registered User
Join Date: Oct 2009
Location: crow-land
Posts: 540
|
Quote:
I see there's generally no benefit to a fancy deinterlacer when downsizing to a re-interlaced result. |
|
1st April 2011, 19:26 | #565 | Link |
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) 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() } 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. |
1st April 2011, 21:03 | #566 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
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. |
|
1st April 2011, 22:59 | #567 | Link | |
Registered User
Join Date: Jun 2010
Posts: 443
|
Quote:
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. |
|
2nd April 2011, 03:47 | #568 | Link |
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 ?
|
2nd April 2011, 14:41 | #570 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
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). Last edited by Gavino; 2nd April 2011 at 14:46. |
|
7th April 2011, 20:07 | #571 | Link |
Registered User
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 |
11th April 2011, 18:43 | #573 | Link |
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. |
11th April 2011, 20:12 | #574 | Link |
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
|
12th April 2011, 16:12 | #575 | Link | |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
Quote:
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. |
|
12th April 2011, 17:07 | #576 | Link | |
Registered User
Join Date: Jul 2010
Posts: 448
|
Quote:
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... |
|
12th April 2011, 17:21 | #577 | Link |
Pig on the wing
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... |
12th April 2011, 19:04 | #578 | Link |
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 |
12th April 2011, 19:19 | #579 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
Does it have a specific interlaced resize operation, or do you have to deinterlace first and re-interlace after resizing? |
|
12th April 2011, 19:49 | #580 | Link | |
Registered User
Join Date: Jul 2010
Posts: 448
|
Quote:
|
|
Thread Tools | Search this Thread |
Display Modes | |
|
|