Interlaced PAL -> NTSC: opinions on this script?

[Matthew]

I'm taking PAL DV, deinterlacing/resizing to 720x480 25 fps, encoding in CCE, and then using DGPullDown to pad out the m2v to 29.97.

I'm not looking to do testing/optimising, etc, I'm just after something that should be decent.

And I'm sure what I've cobbled together is pretty crude:

LoadPlugin("H:\dvtestfootage\encode\degrainmedian.dll")
LoadPlugin("H:\dvtestfootage\encode\TDeint.dll")
AVISource("H:\dvtestfootage\testfootage0001.avi",audio=false)
ConvertToYUY2(interlaced=true)
TDeint(mode=2,order=0)
DeGrainMedian(interlaced=false)
BicubicResize(720,480,0.0,0.6)

Suggestions?

Thanks :)

[neuron2]

Looks OK. Just be sure that the PAL DV really is interlaced. If it's phase-shifted progressive, it will look interlaced but you can recover the progressive frames with Tfm() or Telecide(), in which case you can avoid deinterlacing.

[Matthew]

Thanks for the reply.

It's DV so it's definately truely interlaced. It's a bit sucky because on NTSC output does appear less smooth than the interlaced PAL version. At least for the next video the most important footage will be shot using a tripod, without panning.

[scharfis_brain]

use a good bob-deinterlacer with motion compensated framerate conversion.
THis will avoid the stuttering at all.

[neuron2]

It's DV so it's definately truely interlaced. That's a non-sequitor.

[Matthew]

That's a non-sequitor.

Granted I should have qualified the statement with a comment about the camera's capabilities. It's pretty crap as far as fancy pants features (e.g. progressive mode) are concerned.

@scharfis_brain...could you possibly provide a sample script? Because I don't have a clue what you are talking about :\

[neuron2]

It's not just an issue of DV cameras. DV is a format that can be used to store any content. Someone might store progressive content in that format, just for ease of editing. Or, for example, there are lots of DV capture devices that might be used to record progressive film shows. I used to use one to capture Sopranos, for example, and I could do IVTC on the hard 3:2 pulldown to recover progressive video. The same applies to PAL, but without the pulldown, of course.

If you had stated originally that it was from a DV camera, as you observe in your last post, I would not have raised this point.

Unless I misunderstand, Scharfi's idea will result in 59.94fps, while you specifically stated you want 29.97fps.

[Matthew]

I didn't realise DV was used in capturing tv ;o I did mention a tripod though :/

Anyway, provided that the audio only needs to be timeshifted by a factor of 25->25 (i.e. none) or 25->23.976, I find acceptable any of the following options:

1) 23.976 progressive + DGPulldown
2) 25 progressive + DGPulldown
3) 29.97 progressive
4) 29.97 interlaced

Whatever looks the xxxx :)

[Matthew]

I tried the following and the results were definately better.

LoadPlugin("H:\dvtestfootage\encode\degrainmedian.dll")
LoadPlugin("H:\dvtestfootage\encode\LeakKernelDeint.dll")
AVISource("H:\dvtestfootage\testfootage0001.avi",audio=false)
ConvertToYUY2(interlaced=true)
LeakKernelBob(order=0) #order=0 means BFF, #order=1 means TFF
DeGrainMedian(interlaced=false)
LanczosResize(720, 480)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4, 1, 2)
Weave()

[Mug Funky]

you could try this:

LoadPlugin("H:\dvtestfootage\encode\degrainmedian.dll")
LoadPlugin("H:\dvtestfootage\encode\LeakKernelDeint.dll")
AVISource("H:\dvtestfootage\testfootage0001.avi",audio=false)
ConvertToYUY2(interlaced=true)
DeGrainMedian(interlaced=true)
LeakKernelBob(order=0) #order=0 means BFF, #order=1 means TFF
LanczosResize(720, 480)
convertfps(60000,1001)
assumetff().SeparateFields().SelectEvery(4, 1, 2).Weave()

that'll be a little less jerky, but will give you "field blending' which may be objectionable depending on your content.

you could also replace convertfps(60000,1001) with mvfps or motionprotectedfps (use search :)) to get slower, but probably more pleasing results. for home-shot stuff this it probably the best option as there's less chance of stuff that will throw off the motion-compensation (flashes, scene cuts, etc).

[Matthew]

Thanks for the amended script.

As it is, using that script I get an RT peaking at 0.4, so I'll probably stick with ConvertFPS rather than an even slower option.

This conversion is for a specific recording only, and the camera isn't crash hot, so "pretty good" is just fine :) Given the response of others to the (IMO jerky) test footage, average joe appears to be rather undiscerning.

[Boulder]

You might also want to move the ConverttoYUY2() line after bobbing/deinterlacing. It'll give you a speed and quality boost. Or do you get RGB from AVISource somehow?

[Matthew]

Thanks for the reply.

I only put it there because otherwise I get an error message saying that degrain supports only YUY2 and YV12.

If I use an avs with just AVISource VirtualDub says the decompressor is "uncompressed RGB24".

[Boulder]

I recommend downloading and installing the Cedocida DV codec which will give you YV12 (that's the native colorspace of DV).

http://forum.doom9.org/showthread.php?t=94458

[Matthew]

Thanks, I installed that and moved ConvertToYUY2 until the line after resizing :)

[Mug Funky]

I get an RT peaking at 0.4

hmm. i get (just) faster than realtime on my work and home computers (work: opteron HT @ 3.6 GHz, home: AMD 64 3500+ @ 2.2 GHz).

cedocida should speed you up nicely. and if you use HC or Quenc instead of CCE (quality wise they're all about the same on average, each has strengths and weaknesses), you'll be able to keep yv12 all the way through and possibly get a speedup there.

also, leakkernelbob will go faster if you raise the threshold, but only do this if it doesn't hurt quality because it might leave combs which will turn into horizontal waves after resizing. 4 is a useful max threshold, i tend to use 1 for most things.

.4x realtime is still okay though...

[edit]

also, note that the output of the script is top field first, rather than DV's native (stupid) bottom-field first. so in CCE, "offset line" will need to be 0 (i think that's how it works).

[Matthew]

I thought it seemed a little slow too. I always get well over 2 with DVD source (no processing).

Using anything other than CCE might speed up encoding time but it will mean more manual effort (I have encoding/authoring from avs automated).

When it comes time to encode I'll just leave the script as is...and leave it running. A couple of slow encodes won't kill me.

And I found out about the swapped field order after encoding a sample. CCE now actually has a tff flag as well as an offset line, so one has a choice :)

Thanks again for the help :)