Interlaced HD to DVD AGAIN - some test renders

Back to post

Comments

johnmeyer wrote on 5/5/2011, 12:09 PM
A few quick comments on Nick's amazingly excellent script:

SetMemoryMax

I have generally never had to use this, although I did briefly use it when having problems getting the QTGMC script to work. If you don't end up using QTGMC (see my comment below), then you probably don't need this.

SetMTMode(5, X)

Nick recommends starting by setting "X" to the number of cores in your computer. Since I have an 8-core computer, this would be SetMTMode(5, 8). Nick's advice is good, but I would add one more thing: if you are using QTGMC you should open the Windows Task Manager and look at CPU utilization. I have found that with QTGMC, if this utilization exceeds about 90% -- something that would usually be very desirable -- the script may become unstable and crash. So, after a lot of trial and error I found that if I have any instability, I reduce the setting of "X," then run about ten seconds of video through VirtualDub (which I use to quickly preview the results) using the "Run Video Analysis Pass" (found in the File menu of VirtualDub) and watch the CPU utilization. I keep changing the number of cores until I get CPU utilization in the high 80s. So far, that has given me the perfect trade-off between stability (no crashes at all) and performance.

ColorYUV(levels="TV->PC")

I always bring back onto the Vegas timeline the results from a five second test encode created with the script. I then "A/B" between that test and the original footage and check both with my eye and with the 'scopes to make sure the levels match.

QTGMC/Blur/Sharpen

This script comes out blazing with both barrels in an attempt to kill line twitter, shimmering, and other interlace artifacts. That's good, and is certainly part of what people have been looking for. However, as I think back to all the posts over the past two years about this HD-->SD conversion subject many -- if not most -- of these posts complained about what was perceived as the apparent lack of sharpness and clarity compared to native SD footage. Many of the posts responding to these complaints have pointed to the sharpening included inside many DV (and other SD) camcorders, and that without that artificial sharpening, the results may not meet expectations set by years of watching over-sharpened footage. My point here is that in the desire to reduce twitter and shimmering, this script may actually slightly reduce detail because of the multiple blur steps and the QTGMC function.

Thus, you might end up actually reducing detail -- the very thing you were trying to improve -- in an attempt to deal with artifacts that are, unfortunately, somewhat native to the NTSC (and probably PAL) interlaced format.

So, in my next HD --> SD encode, I will definitely use this script, but my initial trials will be done with QTGMC commented out, and with the

blur(0.0,1.0) # vertical blur

line also commented out. Thus, I will be relying on the TDeint and the clever multiple scaling steps to get superior results. Then, if I see obnoxious levels of twitter, I'll start by adding the blur back, and then if that doesn't do it, I'll add QTGMC. Finally, if the result seems over-sharpened, I'll delete the

sharpen(0.0,0.75) # vertical sharpen

line. I doubt I will ever use the replacement blur/sharpen lines designed for even more low-pass filtering. For those not familiar with how the term "low pass filtering" applies to video, it is in essence a blur function, but it only gets applied to really sharp luma transitions. An example would be a black line on a white basketball court where the very sharp, sudden transition from black to white would be slightly blurred but colored lines on a colored jersey that were roughly the same luma value would not be blurred.

"Low pass" normally refers to audio frequencies and means that low frequencies are allowed to go through to the speakers, but high frequencies are decreased. It turns out that the same math that is used to convert the time representation of sound (what you see on an oscilloscope) to frequencies are also used to convert pixel-based representations of images into compressible video files, and so some of the old terminology has been brought across, even though "low-pass," when applied to video files, only makes sense to someone who has had a class in Fourier transforms and their video/photo counterpart, the Discrete Cosine Transform (DCT).

OK, more than you wanted to know ...



NickHope wrote on 5/6/2011, 6:34 AM
I've found that the resize method is much less relevant than the choice of bob method and the post-resize filtering.

Each of these should do a bob:

1. Bob()
2. Yadif(mode=1)
3. TDeint(mode=1)
4. QTGMC()

Yet if you apply these to the 1920x1080 Belle Nuit test chart, frameserved out of a 1080-60i project, they have dramatically different effects, especially on section 1, where the lines are 1 pixel apart. On the basis of what farss said about wanting to see no flicker at all, it seems the stable grey from TDeint is a clear winner. However I still have this nagging feeling that alternating blocks of colour are actually what we should be seeing in section 1 after processing, if we're doing interlaced>interlaced. The other 3 bobbing methods all give that. In theory, TDeint seems to be getting the bob wrong, as if it's doing a blend instead. Confusing! But I guess this is all part of the trade-off between flicker and detail-retention.

I'm also seeing that a simple LanczosResize or Spline36Resize gives a smoother grey in section 1 than does the unconventional 3-stage bicubic resize, which I really doing think isn't bringing anything significant to the whole process. So I'm leaning towards simplifying things and using the following as a base script:

AviSource("d:\fs.avi")

ColorYUV(levels="TV->PC")

AssumeTFF

LanczosResize(720,height)

TDeint(mode=1)

# QTGMC("very fast",sharpness=0) # Alternative to TDeint line above

LanczosResize(width,480)

blur(0.0,1.0)

sharpen(0.0,0.75) # adjust 2nd value between 0.5 and 1.0 to taste

assumetff()

separatefields()

SelectEvery(4,0,3)

Weave()
craftech wrote on 5/7/2011, 10:14 AM
Sorry I didn't get back to this thread sooner. Thanks John and Nick for all that detail. I can't wait to try these settings:


Thanks again,

John
craftech wrote on 5/7/2011, 10:16 AM
Has anyone else tested Nick's DVD test renders? We would all appreciate as much input as we can get.

Thanks,

John
craftech wrote on 5/9/2011, 12:46 PM
Nick,

I rendered an mxf intermediate file first before frameserving because I had a lot of color correcting, etc.

Before frameserving it as YUY2 I wasn't sure how to set the infamous None, Blend, or Interpolate in the project properties. I chose Blend. Is that what you did?

And also, Procoder recognizes (as a source) the avs script as avi, but as 4:3 LFF despite having Matched Properties in Vegas.

I changed it to 16:9 UFFhoping for the best. It is being rendered to an Mpeg 2 video file with light sharpening at a CBR of 8000.

John
craftech wrote on 5/9/2011, 6:14 PM
By the way, it rendered at 1/20th realtime. 5 hrs for an hour video. This was the script:

Code Block:

AviSource("e:\fs.avi")

ColorYUV(levels="TV->PC")

AssumeTFF

LanczosResize(720,height)

TDeint(mode=1)

LanczosResize(width,480)

blur(0.0,1.0)

sharpen(0.0,0.75) 

assumetff()

separatefields()

SelectEvery(4,0,3)

Weave()


So far it looks good in preview using DVDA. Maybe a good compromise between low twitter and relatively sharp SD video.

I wanted to try some of yours and John's other script suggestions such as the multithread version, but got confused. I just started using AviSynth scripts within the past month.

Also not sure about the mxf intermediate as opposed to something else. I knew that with all those color correction and levels filters, etc that it would have taken a long time to render from the original timeline. Again, None, Interpolate, Blend?? In fact I think I had the project properties set to Interpolate for the intermediate and Blend for the frameserve of the intermediate to the script.

Thanks again for this:

John
NickHope wrote on 5/9/2011, 9:20 PM
I rendered an mxf intermediate file first before frameserving because I had a lot of color correcting, etc.

In general, even with loads of effects, I still wouldn't render an intermediate if using that latest script. It adds an extra step and extra time to your workflow. Plus, .mxf is lossy in the parts that won't smart render. Personally if I really wanted to save an intermediate then I would find room for a Lagarith .avi (really big for 1 hour but lossless) and set it to YUY2 mode so as not to introduce a color space conversion.

If you do decide to render an intermediate file then it's better to open that directly in the AviSynth script instead of unnecessarily frameserving it from Vegas. In the case of a Lanczos intermediate:

AviSource("D:\Path\Lanczos-intermediate.avi")


In the case of an mxf intermediate you could install ffdshow and set it up to decode .mxf and then open it directly with a line like this:

DirectShowSource("D:\path\filename.mxf")


Before frameserving it as YUY2 I wasn't sure how to set the infamous None, Blend, or Interpolate in the project properties. I chose Blend. Is that what you did?

As long as you have "Upper field first" set, it doesn't matter what deinterlace is set in this scenario. The choice is only relevant if you are deinterlacing or resizing in Vegas, but you're doing neither. You're frameserving a full size, interlaced stream. Anyway I probably had mine set to "interpolate".

Procoder recognizes (as a source) the avs script as avi, but as 4:3 LFF despite having Matched Properties in Vegas.

By the time your signal has been through that AviSynth script and reaches Procoder, "Matched Properties" in Vegas has zero relevance. Procoder just sees 720x480 square pixels and makes a guess at what you want to do with them. You need to tell Procoder what to do with those pixels in terms of aspect ratio and field dominance.

It is being rendered to an Mpeg 2 video file with light sharpening at a CBR of 8000.

Where are you adding that light sharpening? I would probably do all my sharpening in AviScript, and not add more later in Procoder. If you want more sharpening, adjust the parameters (0.0,0.75). 1st value is horizontal sharpening, 2nd value is vertical sharpening. Maximum value of each is 1.0. So if you want it sharper then you could try something like (0.5,1.0). But go easy on the horizontal sharpening. Personally I wouldn't add any. The Lanczos 3 sharpening in the script is already gives a sharper result than bilinear or bicubic. The vertical sharpen of 0.75 is primarily to counteract the previous vertical blur, which is part and parcel of this low-pass filtering.

I wanted to try some of yours and John's other script suggestions such as the multithread version, but got confused.

The highly commented version of the script I posted above, including the multi-threading code, was a more complicated script that we were trying earlier. Here's our later, simpler script with the multi-threading code added. You need to set the X value, and also the M value if you end up using that first line (by un-commenting the line). My multi-threading advice is based on what I've read. I've barely tried it myself yet as I only have a Core2Duo in action at the moment. John M is the man for further multi-threading advice.

#SetMemoryMax(M) # See instructions in fully commented script

SetMTMode(5, X) # See instructions in fully commented script

AviSource("d:\fs.avi")

ColorYUV(levels="TV->PC")

AssumeTFF

SetMTMode(2)

LanczosResize(720,height)

TDeint(mode=1)

LanczosResize(width,480)

blur(0.0,1.0)

sharpen(0.0,0.75)

assumetff()

separatefields()

SelectEvery(4,0,3)

Weave()

Distributor() # Don't know if Procoder needs this or not.

              # Try removing it and see if you get more speed


I'm still hoping to do a version 2 DVD of comparative HD>DVD methods, including the latest scripts and witht the different methods running back-to-back for easy comparison. If anyone has a specific request for a method they want included then please shout!
craftech wrote on 5/10/2011, 7:15 AM
If you do decide to render an intermediate file then it's better to open that directly in the AviSynth script instead of unnecessarily frameserving it from Vegas. In the case of a Lanczos intermediate:

Code Block:
==============
It would have to be an avi because Procoder won't recognize an mxf intermediate. You also said mxf is lossy as well so I guess an avi is the best choice.
===============
Where are you adding that light sharpening? I would probably do all my sharpening in AviScript, and not add more later in Procoder.
===============
I have used the sharpening filter in Procoder before, but if it is counterproductive, I'll stop. Either way it is supposed to be done After downscaling, but it looks like that happens within the script anyway.
==============
Thanks for that less condensed version of the multithread script. I'll try that next.
=============
I'm still hoping to do a version 2 DVD of comparative HD>DVD methods, including the latest scripts and witht the different methods running back-to-back for easy comparison. If anyone has a specific request for a method they want included then please shout!
================
I think many of us want to see the methods that worked the best compared directly to a few Vegas only scenarios.

Thanks again for all the work you have done.

John
NickHope wrote on 5/10/2011, 9:31 AM
I think many of us want to see the methods that worked the best compared directly to a few Vegas only scenarios.

I'll do a basic one 100% in Vegas with best/interpolate set, reduce interlace flicker OFF, and no sharpening etc..

Anybody want a render with Sharpen 0 or Unsharp Mask "Light" added?
johnmeyer wrote on 5/10/2011, 11:26 AM
Anybody want a render with Sharpen 0 or Unsharp Mask "Light" added? Since you asked, and since you seem to be a glutton for punishment :), I think it would be a good idea to add either (or both) of the sharpening workflow outputs since sharpening has become part of the "best practices" we seem to have collectively developed in this forum when doing, entirely in Vegas, an HD->SD render designed for viewing via DVD. You might want to include some statement in whatever you put on the DVD about how to set the pre/post toggles so that sharpening gets done at the proper point in the downsizing process (for those who might stumble on this at some later time ...)
amendegw wrote on 5/10/2011, 1:53 PM
Another vote for "Sharpen=0". Also, as you know, I'm also a proponent of "Reduce Interlace Flicker", but I think I'm a "lone wolf" on this one.

...Jerry

System Model: Alienware Area-51m R2
System: Windows 11 Home
Processor: Intel(R) Core(TM) i7-10700K CPU @ 3.80GHz, 3792 Mhz, 8 Core(s), 16 Logical Processor(s)
Installed Memory: 64.0 GB
Display Adapter: NVIDIA GeForce RTX 2070 Super (8GB), Nvidia Studio Driver 527.56 Dec 2022)
Overclock Off

Display: 1920x1080 144 hertz
Storage (12TB Total):
OS Drive: PM981a NVMe SAMSUNG 2048GB
Data Drive1: Samsung SSD 970 EVO Plus 2TB
Data Drive2: Samsung SSD 870 QVO 8TB

USB: Thunderbolt 3 (USB Type-C) port Supports USB 3.2 Gen 2, DisplayPort 1.2, Thunderbolt 3

Cameras:
Canon R5
Canon R3
Sony A9

craftech wrote on 5/10/2011, 4:34 PM
OK,

I tried AviSynth MT (Multithread). It works. I frameserved an hour and 20 minute heavily color enhanced mxf timeline into Procoder using the normal AviSynth script first and multithread AviSynth script second. I rendered to a CBR of 8350 with no Procoder filters.

The normal AviSynth script rendered at 7% of realtime and the multithread at 15% realtime. I have a quad core.

So it works.

Thanks,

John
craftech wrote on 5/11/2011, 5:19 AM
Nick,

In the most recent script:



#SetMemoryMax(M) # See instructions in fully commented script

SetMTMode(5, X) # See instructions in fully commented script

AviSource("d:\fs.avi")

ColorYUV(levels="TV->PC")

AssumeTFF

SetMTMode(2)

LanczosResize(720,height)

TDeint(mode=1)

LanczosResize(width,480)

blur(0.0,1.0)

sharpen(0.0,0.75)

assumetff()

separatefields()

SelectEvery(4,0,3)

Weave()

Distributor() # Don't know if Procoder needs this or not.

              # Try removing it and see if you get more speed


Why did you not include the scaling increments that were in method 3?

John
NickHope wrote on 5/11/2011, 11:12 AM
Why did you not include the scaling increments that were in method 3?

I compared the results and didn't think they were really adding anything to the quality of the result. It was an unconventional way of doing things that I think Didée on the doom9 forum introduced specifically as part of a strategy to tackle that moiré-inducing background on amendegw's hula doll clip. I'm not sure it actually had much effect anyway, compared to the other steps in the script. For most normal footage I think it's just complicating things. To quote some recent correspondence I've had with him:

As stated earlier: for straight interlaced downsizing,

But by all means try it and see if you see a difference from the Lanczos resize. I may have missed something.
craftech wrote on 5/11/2011, 12:22 PM
But by all means try it and see if you see a difference from the Lanczos resize. I may have missed something.
===============================
So if I try that I would take the multithread script I used:

#SetMemoryMax(800) 

SetMTMode(5, 4) 

AviSource("e:\fs.avi")

ColorYUV(levels="TV->PC")

AssumeTFF

SetMTMode(2)

LanczosResize(720,height)

TDeint(mode=1)

LanczosResize(width,480)

blur(0.0,1.0)

sharpen(0.0,0.75)

assumetff()

separatefields()

SelectEvery(4,0,3)

Weave()

Distributor()


and change it to:

#SetMemoryMax(800) 

SetMTMode(5, 4) 

AviSource("e:\fs.avi")

ColorYUV(levels="TV->PC")

AssumeTFF

SetMTMode(2)

TDeint(mode=1)

bicubicresize(1440,960)

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

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

blur(0.0,1.0)

sharpen(0.0,0.75)

assumetff()

separatefields()

SelectEvery(4,0,3)

Weave()

Distributor()


Does that look right?

Thanks,
John
NickHope wrote on 5/12/2011, 5:38 AM
Yep, that looks right. Note that if you want to actually use the first line, you need to un-comment it by removing the #. Also do some stability/time trials with and without the distributor() line. Procoder may or may not need it.

Interested to know if you see any difference between those resize methods. I was finding FAR more effect from adjustments to the blur/sharpen sequence than from the resize method.
craftech wrote on 5/12/2011, 8:33 AM
OK,

Thanks Nick. Wasn't sure about the # symbol.
Distributor didn't seem to bother it last time so I'll just leave it in.

I'll render this and let you know sometime tonight how it compares.

John
NickHope wrote on 5/12/2011, 8:57 AM
I did resizing comparisons by rendering Lagarith files, putting them on a 720x480 59.94p progressive timeline at full/best and muting tracks. Those renders were without the blur/sharpen or re-interlacing stages. I tried bilinear, bicubic, Lanczos3, Spline36, and the 3-stage bicubic method.
craftech wrote on 5/12/2011, 6:15 PM
Still rendering. This is rendering slower than the other ones (probably the 3-stage bicubic resize) unless it is the memory max setting (doubtful).

Has anyone suggested or tried a 3-stage Lanczos resize? Since Lanczos 3 is often described as the better resize method by lots of people.

John
craftech wrote on 5/12/2011, 8:57 PM
Results:

This script:



SetMemoryMax(800) 

SetMTMode(5, 4) 

AviSource("e:\fs.avi")

ColorYUV(levels="TV->PC")

AssumeTFF

SetMTMode(2)

TDeint(mode=1)

bicubicresize(1440,960)

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

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

blur(0.0,1.0)

sharpen(0.0,0.75)

assumetff()

separatefields()

SelectEvery(4,0,3)

Weave()

Distributor()



produced significantly better results than this script:



SetMemoryMax(800) 

SetMTMode(5, 4) 

AviSource("e:\fs.avi")

ColorYUV(levels="TV->PC")

AssumeTFF

SetMTMode(2)

LanczosResize(720,height)

TDeint(mode=1)

LanczosResize(width,480)

blur(0.0,1.0)

sharpen(0.0,0.75)

assumetff()

separatefields()

SelectEvery(4,0,3)

Weave()

Distributor()


I had to put each in DVDA and preview them, but the difference was really noticeable. Much more detail in the gradual resize script. It rendered at around 11-12% of realtime compared to 15-16% of realtime for the other.

John
NickHope wrote on 5/12/2011, 10:19 PM
That's interesting John. I'll look at it again. I think it's important to break the process down and see how the resizes compare before adding the blur/sharpen/reinterlace/compression.

In the meantime I got another bobbing and resizing suggestion on the doom9 forum. I didn't attempt it or even attempt to understand it yet. If you're in the mood... Bob wiwki, Resize wiki, AddBorders wiki.
craftech wrote on 5/13/2011, 4:13 AM
That Resize Wiki had some interesting facts in it about Lanczos 3 resize, particularly this:

Lanczos was created for AviSynth because it retained so much detail, more so even than BicubicResize(x,y,0,0.75). As you might know, the more detail a frame has, the more difficult it is to compress it.

Now to be clear, in my comparison above, I used a CBR of 8350 to compare the two scripts, ignoring the file sizes.

They also spoke about Lanczos 4 (which I never heard of):

Lanczos4Resize is a short hand for LanczosResize(taps=4). It produces sharper images than LanczosResize with the default taps=3,

Has anyone over at Doom 9 tried Lanczos 4, and if so how did they script it?

John

EDIT: What in the world is distributor in the script? What does that do?
Never mind. I used a CPU monitoring utility and saw what it does. It distributes the CPU utilization evenly (fairly evenly) across the cores.
NickHope wrote on 5/13/2011, 4:47 AM
This means that Lanczos is NOT suited for low bitrate video

Well, the bitrates we're using for DVD are not really low bit rate. If we were compressing for self-hosting on the web then that's more relevant. Seems like most of the gurus prefer spline36resize anyway. I have been in the habit of using Lanczos 3 because it's more of a known quantity and is in the options of so much software such as VirtualDub, Handbrake etc., but I might switch to spline36 as my "generally preferred" AviSynth downsizer. It's a little slower though.

Has anyone over at Doom 9 tried Lanczos 4, and if so how did they script it?

I have tried it and read quite a bit about it. My conclusion was to disregard it for downscaling because of the danger of over-sharpening. However it is supposed to be excellent for upscaling. I am intending to try upscaling some of my PAL DV footage to pillarboxed 720p for "fake" YouTube HD upload and Lanczos 4 is very much in my reckoning for that, along with spline resizing.

If you want to use it you simply insert the number 4. i.e. Lanczos4Resize. Without the number, LanczosResize defaults to Lanczos 3.

By the way, if you're interested, keep up with the doom9 discussion I linked above. Hopefully some more of the doom9 heavyweights might chime in besides Henry.
craftech wrote on 5/13/2011, 5:11 AM
I have been in the habit of using Lanczos 3 because it's more of a known quantity and is in the options of so much software such as VirtualDub, Handbrake etc., but I might switch to
=================================
Didn't you try that in Method 2 at the beginning of the thread? Most of us didn't seem to like the results very much.

Also, why are the forum members over at Doom 9 relying on the rendered results of the Belle Nuit test chart so much? It is after all a still image that doesn't seem relevant to real world moving image comparisons IMO.

John