Log in

View Full Version : Please check my NTSC 486-line workflow


Trixter
9th September 2005, 20:15
Hey guys, I have the "wonderful" task of taking PAL footage, converting it to an NTSC broadcast (486 lines, not 480) online editing system, doing some work, then burning it to DVD. I believe the best way to achieve this is to do the initial PAL->NTSC transcode to 480 lines, pad to 486 for work in the editor, then take the final output and chop off the padded lines. To preserve field order, I was going to add 2 lines to the top and 4 lines to the bottom (adding 3 and 3 would change field dominance).

First off: Sound like a decent plan?

Secondly, here are the scripts I'm going to use, please check them to see if I'm making a terrible mistake. First, my PAL->NTSC transcode looks like this:

# Load compatibility modules
LoadPlugin("D:\Program Files\AviSynth 2.5\oldplugins\LoadPluginEX2.dll")
LoadPlugin("D:\Program Files\AviSynth 2.5\oldplugins\SmoothDeinterlacer.dll")

# Load the actual file we're going to work with
AVISource("h:\assets\mc2\pal\groovy.avi")

function PAL2NTSC(clip c)
{
# Use the SmoothDeinterlace plugin to simulate 50p
c.SmoothDeinterlace(tff=true, doublerate=true)
# Convert to YUY2 (required by ConvertFPS)
ConvertToYUY2
# Resize to NTSC resolution
BilinearResize(720, 480)
ConvertFPS(59.94)
# ChangeFPS(59.94) adds/drops fields
# ConvertFPS(59.94) blends fields
# Turn 60p into 30i
SeparateFields()
return SelectEvery(4, 0, 3)
# 4,1,2 is for odd field first; 4,0,3 is for even field first
}

pal2ntsc
weave

#and now the retarded part, we have to pad to 486 lines by adding 2 at top and 4 at bottom
AddBorders(0,2,0,4)

I bring the file into my editor using the .avs script (thank god the editor loads .avs scripts!) and do my work. When I'm done editing, I export out a new 486-line .AVI, and write a wrapper script to chop off the lines I had previous added with this:

# Load the actual file we're going to work with
AVISource("h:\assets\mc2\pal\groovy_486.avi")

#and now the retarded part, we have to crop top 2 lines and bottom 4 to achieve 480
Crop(0,2,720,480)

...which is loaded into the MPEG-2 encoder instead of the original 486-line file.

Does all that sound reasonable? Am I missing something or making a terrible mistake? I have nearly a terabyte of footage to work on so I want to get my workflow right before I begin. Thanks in advance for any comments!

PS: I can't change my editor, nor can I do further editing work in PAL before the conversion, so please don't suggest those as alternatives. I must work in 486-line NTSC D1, and I must do edits in NTSC-land with the converted footage before the final MPEG-2 phase.

scharfis_brain
9th September 2005, 21:28
replace smoothdeinterlacer by either
- leakkernelbob() #fast
- tdeint() #medium
- mvbob() #slooooow

also ensure to set the fieldorder before separatefields() correctly by using assumetff() or bff() depending on the wished output fieldorder.

Trixter
9th September 2005, 21:43
SmoothDeinterlacer has worked really, really well for me in the past -- can you give me a little bit more information about the three alternatives you listed? I'm looking for the best quality, so speed isn't an issue. Which of the above is better than SmoothDeinterlacer, and why?

(I understand fields, etc. very well, and I am also a programmer, so you can use technical terms if necessary)

scharfis_brain
9th September 2005, 22:16
all deinterlacers are better than smoothdeinterlacer.

- leakkerneldeint is an ultra fast SSE optimised simple motion adaptive deinterlacer with kernel based (VT-kernel) interpolation.
this kind of interpolation supresses flicker at the cost of little more stairstepping on moving diagonales. This Kernel is commonly used in commercial standards converters.

- tdeint is an advanced motion adaptive deinterlacer, which tries to create the best as possible motion mask with less artifacts. So it is slower by a fair amount, than leakkerneldeint. Tdeint provides three kinds of interpolation:
linear -> like smoothdeint
kernel -> like leakkerneldeint
ELA -> edge directed interpolation. No more jaggy edges, but increased flicker.

- mvbob is a fully motion compensated deinterlacer, which recreates image detail even in moving image areas. Also it has lesser flickering than all deinterlacers above and reduces noise. It is painfully slow (between 1 to 3 fps...). It only works correctly with true interlaced contents of video cameras. telecined flim or 30p won't look much better with it than tdeint() or leakkernelbeo().

Trixter
10th September 2005, 01:33
Thanks for the explanations. However, I'm concerned that my video will be exposed to more post-processing than necessary ("sharpening", etc.). Which one of the three you listed would preserve the video the best? For example, what exactly is this "flicker vs. jagged edges" tradeoff you talk about?

Trixter
10th September 2005, 03:14
all deinterlacers are better than smoothdeinterlacer.

If that's the case, then why did SmoothDeinterlacer produce the best results when I just tried LeakKernelBob() and TDeint()? For example, check out the following:


LeakKernelBob(threshold=10,sharp=false):

http://www.oldskool.org/misc/LeakKernelBob_threshold-10_sharp-false.png

TDeint(mode=1,type=0,sharp=false):

http://www.oldskool.org/misc/TDeint_mode-1_type-0_sharp-false.png

Only SmoothDeinterlacer didn't produce artifacts, and I didn't even touch any of the settings (other than doublerate=true):

http://www.oldskool.org/misc/SmoothDeinterlace_doublerate-true.png

If every other one is better, what am I doing wrong? The only way I could get TDeint() to eliminate the artifacts is if I set threshhold=0 which I know can't be right...

I agree that SmootherDeinterlacer produces some "dirty" frames but I've never had a problem with missing some areas completely like I did with the previous ones. Help?

Mug Funky
10th September 2005, 03:32
input field-order is wrong there.

when you get that kind of artefact, you can bet it's input field-order. :)

btw, when resizing to NTSC, you might want to take into account whether you're resizing 576 to 480, or actually 625 to 525... this one does my head in, and i don't know for sure which preserves the correct aspect ratio (probably the 576 to 480 method), but i know standards-converters all do it the 625->525 way.

scharfis_brain
10th September 2005, 03:37
try the ap-parameter of TDeint.

smoothdeinterlace is resistent against such artifacts, because its mask seems to be more sensible for spatial than for temporal.

Trixter
10th September 2005, 03:49
(Mug) input field-order is wrong there.

No, it's quite correct. Otherwise I'd see forward-back-forward-back single-stepping through the file, which I don't.

(schar)try the ap-parameter of TDeint.

I will, thanks for the help. (I didn't have that parameter, so research showed I wasn't running the most recent one. With www.avisynth.org down for the past few days, finding this information has been annoying.)

Also, I think you meant to swap "spatial" and "temporal" in your last sentence -- if it was not sensible for temporal, then I would see those artifacts when using it. Unless I'm misunderstanding the filters and how they work. Which is unlikely, but possible :-)

So, to the original question -- no problems with the workflow I have in mind?

Mug Funky
10th September 2005, 05:05
No, it's quite correct. Otherwise I'd see forward-back-forward-back single-stepping through the file, which I don't.

that's weird... but i'll believe you of course :)

could you post a sample clip? it's not unheard of that non-linear editing programs will bizz0rk a clip when they're trying to get them right - i'm thinking of a situation where a clip has correct field-order, but appears wrong to a kernel-based deinterlacer. this effect would be pretty visible though, so i'm probably on the wrong track.

Trixter
10th September 2005, 08:32
Different broadcast editing systems have traditionally worked in different field dominances -- at least, this was true up until around 1999 when most people started getting their act together. That being said, I am sure my post setup is fine.

However, for those who would like to experiement, here is the actual untouched footage I'm working with. As you'll see, it is TFF among other things: http://www.oldskool.org/misc/groovy_25i.7z

Mug Funky
27th September 2005, 05:12
actually, 1 thing i've noticed about 486 stuff (i'm learning this as i go... PAL land means blissfully few encounters with NTSC formats) is that they ARE bottom field-first. i think adding 3 lines top and bottom is what's needed.

to clarify - NTSC DVD is 480 lines, top field first, and this is what you get when playing a digibeta (full 525 lines, 486 picture area) out to an MPEG-2 encoder (480 lines). you could take 486 as being "expanded top-first" i suppose... i'm not sure, but i think the full 525 lines go in top-first, so in a way it's all consistent and just depends how much gets cropped away. this would also explain why standalone video gear doesn't get confused by field-order no matter what you feed them (unless order was made bad by human/computer error).

now i don't know how nonlinear editing apps handle this, because they tend to work in 480 lines anyway. maybe they crop first?