avisynth: convertFPS vs changeFPS

[lordsmurf]

Has anybody run tests on these?

I noticed that convertFPS may have better horizontal motions, but tends to make the image vibrate vertically.

Then changeFPS has some random sticking of frames horizontally, but perfect vertical hold.

Your thoughts?

[adam]

Yup sounds about right. Changefps changes fps by duplicating or decimating frames. So motion, particularly pans, will be jerky but vertical hold will have no reason to be adjusted.

ConvertFPS doesn't drop or insert frames. It instead either blends multiple frames into one (to decrease fps) or "switches" one frame into two by literally breaking it into parts. Blend obviously results in motion blurring, and switch introduces wobble during pans.

No way to avoid this using these filters. That's just how they work.

[lordsmurf]

And it's safe to assume these are unavoidable when performing PAL <-> NTSC conversions, correct?

I had to convert a video, and this was the code:

LoadPlugin("c:\shared\Convolution3d.dll") 
LoadPlugin("C:\shared\SmoothDeinterlacer.dll") 
LoadPlugin("C:\shared\MPEG2Dec3.dll") 
MPEG2Source("c:\shared\testvid.d2v")
ConvertToYUY2(interlaced=true)
SeparateFields() 
odd=SelectOdd.Convolution3D (0, 6, 10, 6, 8, 2.8, 0) 
evn=SelectEven.Convolution3D (0, 6, 10, 6, 8, 2.8, 0) 
Interleave(evn,odd) 
Weave() 
AddBorders(16,12,16,12) 
SmoothDeinterlace(tff=true, doublerate=true) 
LanczosResize(352,480) 
ChangeFPS(59.94) 
SeparateFields() 
SelectEvery(4,1,2) 
Weave() 
ConvertToRGB(interlaced=true)

It didn't look too bad, but I could tell it was not perfect.

Encoded in TMPGENC. Since the original size was messed up anyway, I had to resize in TMPGENC. I'm not sure if the AVISYNTH code should have had "AddBorders" or not, but it was really a moot point.

I would like to know if it was necessary, however.

[adam]

If going from interlaced PAL->NTSC then yes I would say these sorts of things are unavoidable.

Without a crop command, the only reasons I can think of to add borders would be to make sure none of the picture got cut off due to overscan, or if you needed to pad your source to get it to the correct aspect ratio before resizing. If this is just a sample script you picked up somewhere, I'd say lose the addborders command.

If you are going to resize in TMPGenc I'd just remove the resizing command altogether in Avisynth.

[lordsmurf]

Yeah, it was something I sort of pieced together from FulciLives, Xesdeeni, and then reading some comments on the commands. I was flying blind, but it worked pretty well.

Thanks.

[Father X]

You could just frameserve it to TMPGEnc without any change to the framerate, then in TMPGEnc Advanced tab select "Do not convert frame rate".

You'll need to adjust the audio separately.

This has worked for me in the past. PAL movies are actually 24fps speeded up slightly, so if going to NTSC don't change the framerate, just stretch the audio (I think factor is 1.004? Anyway, BeSweet can do the audio conversion automatically, there's a PAL to NTSC checkbox.) and encode in NTSC Film mode.

Do the reverse for NTSC Film to PAL.

29.97 NTSC to PAL is a horse of different color, however.

Cheers.

[adam]

If his source is PAL interlaced he cannot convert to NTSCfilm without deinterlacing. Since he apparantly doesn't want to do this, his only option is to convert to 29.97fps interlaced, which cannot be done by just speeding up the playback.

[manono]

Yes, but although the script is obviously based on an interlaced source, nowhere has he said how he determined that the source is, indeed, interlaced. If he based it, for example, on what DVD2AVI told him, then the chances are good that it's progressive anyway. Lots of PAL DVDs have shifted fields which can easily be made progressive again. Lots of PAL DVDs are encoded as interlaced when the material is really progressive. If it's a movie, then almost certainly it's progressive. If it's from a concert or TV series DVD, then most likely it really is interlaced. He didn't say what kind of video he was converting. If it's a capture, then maybe it's interlaced.

In any event, if the source is progressive, he'd be much better off using AssumeFPS(23.976) and then adjusting the audio length. That'll avoid the jerkiness and/or blurry blends that the other 2 commands will cause.

So, when he says:

And it's safe to assume these are unavoidable when performing PAL <-> NTSC conversions, correct?

then, no, that's not correct in all, or even in most, cases. It depends on the source material. I'm not arguing with you adam, because everything you said is correct for interlaced sources, although, personally, I'd deinterlace it first. But that's just me. I spend so much time unblending crappy blended DVDs that there's no way I'd ever create one intentionally.

[lordsmurf]

It's interlaced. This is a continuation from past days.

[adam]

I took his post at face value. I couldn't think of a reason why he'd be using that script unless his source was interlaced and he wanted to keep it that way. I guess I assumed too much, but I know that Lordsmurf knows enough about this that he wouldn't have used that script on a progressive source.

I too would rather deinterlace, but that's a totally subjective thing.

When he asked about PAL->NTSC I assumed he was converting to 29.97 and not 23.976fps, or else he would have written PAL->NTSCfilm.

[lordsmurf]

What kind of deinterlace method would you have used?

I assume you'd then scale back to 23.976, right?

[adam]

If it were me, I'd use decomb's field deinterlacing (default is blend) and then assumefps to 23.976fps. Encode to 23.976fps and apply pulldown flags. There may be a better way.

FieldDeinterlace()
AssumeFPS(23.976)

We all know what deinterlacing does to the source. Try it and see if the softer image is preferable to the problems created through the hard telecine.

[gastorgrab]

So then to speed up or slow down interlaced material should we separate fields (doubleing the framrate, but no bob), then adjust the framerate, and then re-weave?

If interlaced material is simply speed up, or slowed down, then only the framerate changes. It seems that the time difference between the fields of a single frame should remain at the original rate. Then the interlace lines would be slightly misaligned for proper playback.

Does this sound about right?

---edit---

Nope, i just read the post wrong!

[lordsmurf]

Ahhh... hell. We lost a bunch of posts here. There were some really good scripts being written down in here, in regards to converting PAL <-> NTSC.

If that was you... put them back?

[pijetro]

No, adam is the closest..
I've done many interlaced PAL>NTSC conversions, and what's worked for me is:
avisource("I:\bobloblaw.avi")
assumefps(23.976,true)
separatefields()
lanczosresize(352,240)
weave()
fielddeinterlace()#play around with threshold values if you like
resampleaudio(48000)#I open this script in CoolEditPro

Encode for interlaced (assuming you're using CCE)..

If your source is progressive 25fps, then skip the separatefields() alltogether.
Encode for progressive..

[tedkunich]

And it's safe to assume these are unavoidable when performing PAL <-> NTSC conversions, correct?

Have you looked at the DePan and MVTools plugins? Both perform motion estimation and can be used for adjusting frame rates. Have never used them for such, but may be worth talking a look at. There are active threads for both filters on the Doom9 Avisynth forum.


T