NTSC 29.97 to PAL 25, what's the latest thinking?

[Floatingshed]

Its a while since I've done this. The source is true interlaced (videotape) NTSC and I want true interlaced PAL output.
Previously I used this:

AssumeTFF
tdeint(order=1, mode=1)

MotionProtectedFPS(50)

SeparateFields()
SelectEvery(4, 0, 3)

Weave()


I imagine newer scripts/ideas exist, can someone point me in the right direction please?

[manolito]

Basically your script is correct, AFAIK there are no revolutionary new and better methods for this kind of conversion.

Two things about your script:
1. If you already have "AssumeTFF()" at the top of your script then you can omit the "order=1" from your TDeint call.
2. MotionProtectedFPS is a little bit outdated, it has been superseded by mvtools2 based methods like FrameRateConverter.

I generally prefer using a simple "ChangeFPS(50)" in my NTSC to PAL conversion scripts. Much faster, and I don't mind the motion judder when the alternative often introduces artifacts.


If you want to experiment this is a template where you can use different bobbers and framerate changers.
AssumeTFF() # Specify source field order
PointResize(width,height+8,0,-4,width,height+8)
# Yadif(mode=1)
yadifmod(mode=1, edeint=tdeint(mode=1, mthreshL=0,mthreshC=0))
Crop(0,4,-0,-4)
# tdeint(mode=1)
Spline36Resize(720,576)
# ConvertFPS(50) # Blends frames
ChangeFPS(50) # Drops frames
# MotionProtectedFPS(50)
# jm_fps(50)
AssumeTFF() # Specify target field order
SeparateFields()
SelectEvery(4, 0, 3)
Weave()

Please note that for using YADIF or YADIFMod I use padding to avoid artifacts in the first scan line. This is mostly unnecessary for other bobbers. jm_fps is a frame interpolation script by johnmeyer which you can find here:
https://forum.doom9.org/showthread.php?p=1800439#post1800439

[TheFluff]

The source is true interlaced (videotape) NTSC and I want true interlaced PAL output.

why though

[johnmeyer]

I always support keeping interlaced video as interlaced, since deinterlacing always degrades the video.

However, this task might be one exception to my rule because just about any method I can think of for changing to/from NTSC/PAL interlaced video is going to require some sort of field/frame estimation to create intermediate fields and frames. Once you do that, the damage has been done, and therefore the argument for converting back to interlaced is fairly weak.

But, how to do the conversion, and do it well?

Nick Hope, an American ex-patriate living in Thailand who creates amazing underwater videos, long ago posted his "perfectionist's" AVISynth script for converting PAL to NTSC (which is what he does most often) and also the script that you want which converts NTSC interlaced to PAL interlaced:

https://www.vegascreativesoftware.info/us/forum/perfectionists-pal-ntsc-conversion--84824/

You may be able to find more up-to-date information on his website: www.bubblevision.com.

I've used his PAL to NTSC script many times, and it works really, really well.

I'm pretty sure that if you delete the last four lines of code from his NTSC to PAL script that you will end up with 50 fps progressive. These last four lines change that to 25 fps interlaced.

Here are the lines you'd delete if you want to keep it as 50 fps progressive:AssumeBFF()
SeparateFields()
SelectEvery(4,0,3)
weave()

FWIW, here is how I adapted Nick's PAL to NTSC script. I am posting this, even though it is converting the other way from what you want, just to show you some of the tweaks I made. Most of these should be easily adapted to the NTSC to PAL script.

#Script to convert PAL to NTSC
#Frameserve in RGB24 format (or RGB32 if AviSynth will not accept RGB24)

loadplugin("C:\Program Files\AviSynth 2.5\plugins\MVTools\mvtools2.dll")
loadplugin("C:\Program Files\AviSynth 2.5\plugins\RemoveGrainSSE2.dll")
loadplugin("C:\Program Files\AviSynth 2.5\plugins\SSE3Tools.dll")
loadplugin("C:\Program Files\AviSynth 2.5\plugins\mt_masktools-25.dll")

Import("E:\Documents\My Videos\AVISynth Scripts\QTGMC-3.31a.avsi") #Use version with hpad,vpad hardwired to 8 (avoids crash)

SetMemoryMax(1000)
SetMTMode(5,8)
AviSource("e:\fs.avi").AssumeTFF()
SetMTMode(2)

ConvertToYUY2(interlaced=true, matrix="PC.601")

Spline36Resize(720,height)

#The following worked well for HD PAL video that I restored for someone on the Internet
QTGMC( Preset="Slower", SubPel=2, EdiThreads=4,ThSCD1=180, ThSCD2=98, Blocksize=32,Overlap=4) #Nick's latest settings default scene detection is thSCD1=304, thSCD2=100
#QTGMC( Preset="Slower", SubPel=2, EdiThreads=4,ThSCD1=180, ThSCD2=98 ) #Nick's latest settings default scene detection is thSCD1=304, thSCD2=100
#QTGMC("faster", sharpness=0, SubPel=2) #SubPel must match pel in MSuper below
super = MSuper(levels=1, pel=2)
MFlowFps(super, QTGMC_bVec1, QTGMC_fVec1, num=60000, den=1001,ThSCD1=180, ThSCD2=98) #Change scene detection to match QTGMC
Spline36Resize(width,480)

#Spline36Resize(720,480)

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

separatefields()
SelectEvery(4,0,3)
#Selectevery(4,1,2) #For reversed fields
Weave()

[StainlessS]

On first inspection, me is less than happy with the mani script, but, Mani is well good,
and I am forced to accept that it works. (resize before De-interlace, seems a messed up but, if Mani says it works, I refuse to dispute it,
still seems a bit messed up.)

Mind you, I think that the real reason that I refuse to dispute the mani claim is, he got the best smile,
Mani was such a star in High Chapporal, it's his smile that deflects my disbelief.

Mani, is a born con-man. He always got me. :)

[manolito]

The script I posted has basically been THE method for interlaced NTSC to interlaced PAL since a long time. I believe that it was made and promoted by Xsdeeni. The first time I saw it was in the SmoothDeinterlacer manual.

PointResize(width,height+8,0,-4,width,height+8)
Yadif(mode=1)
Crop(0,4,-0,-4)

This is not "Resize before Deinterlace". The real resizing comes after the bobber. This is padding (courtesy of Didée). You can read about it here:
https://forum.doom9.org/showthread.php?p=1325574#post1325574test the


I think the real question here is why you'd want to convert to PAL at all, since virtually all playback devices today have no problem with NTSC playback, even in PAL land.


@ johnmeyer
I remember you posted the Nick Hope scripts here a while ago, and I did test the NTSC to PAL script then. Looking closer you will see that the workflow is absolutely the same as the one I posted. The difference is that he used all the ultra high end tools like QTGMC for bobbing and MVTools2 based frame interpolation for frame rate conversion. You could easily insert QTGMC in my script, and jm_fps should even look better than his MVTools parameters.

The main difference is SPEED. The Nick Hope script is painfully slow, and for me the slight gain in quality is not worth the lost time. Using Yadifmod with TDeint as the interpolator is very high quality (the parameters come from tritical himself), and if frame interpolation looks so much better than a simple ChangeFPS can be disputed. Also depends a lot on the source characteristics.

[Sharc]

For the sake of completeness let me add Etienne Charland's (aka MysteryX) FrameRateConverter
https://github.com/mysteryx93/FrameRateConverter/blob/master/FrameRateConverter.avsi
https://github.com/mysteryx93/FrameRateConverter/releases


Some time ago MysteryX took huge efforts to reduce interpolation artifacts by introducing sophisticated masking. It is based on before mentioned tools and can help in some situations, depending on the source.

Discussion see here:
https://forum.doom9.org/showthread.php?t=174410
https://forum.doom9.org/showthread.php?t=174793

[johnmeyer]

@ johnmeyer
I remember you posted the Nick Hope scripts here a while ago, and I did test the NTSC to PAL script then. Looking closer you will see that the workflow is absolutely the same as the one I posted. The difference is that he used all the ultra high end tools like QTGMC for bobbing and MVTools2 based frame interpolation for frame rate conversion. You could easily insert QTGMC in my script, and jm_fps should even look better than his MVTools parameters.Yes, the big difference is what tool you use to deinterlace.

However, there are several smaller differences. One is re-sizing. Nick's scripts do that in two steps, doing the horizontal resizing before the deinterlacing, and the vertical resizing afterwards. He did a blur/sharpen step to take care of residual jaggies after the resizing. Also, he did not crop, something I assume you did because analog sources often have garbage at the edges.

I'm not stating an opinion as to whether these differences are good or bad either way, only to point out that there are actually quite a few other differences in the two scripts (beyond the deinterlacing tool used), and most of them are not entirely trivial.

[manolito]

However, there are several smaller differences. One is re-sizing. Nick's scripts do that in two steps, doing the horizontal resizing before the deinterlacing, and the vertical resizing afterwards. He did a blur/sharpen step to take care of residual jaggies after the resizing. Also, he did not crop, something I assume you did because analog sources often have garbage at the edges.

Not true for the SD NTSC to SD PAL script. And the blur/sharpen step is only useful when you are downscaling from HD to SD. Cropping to mod4 is something I always do without even thinking about it. It is just safer for a lot of filters

[johnmeyer]

Not true for the SD NTSC to SD PAL script. And the blur/sharpen step is only useful when you are downscaling from HD to SD. Cropping to mod4 is something I always do without even thinking about it. It is just safer for a lot of filtersI would think the blur/sharpen would be useful for any resizing; HD to SD is just more of the same thing, compared to NTSC<-->PAL.

I didn't realize the cropping was to get to MOD4 since, AFAIK, all the various resolutions for NTSC and PAL are already MOD4:

480
576
704
720

[manolito]

I didn't realize the cropping was to get to MOD4 since, AFAIK, all the various resolutions for NTSC and PAL are already MOD4:

Sorry, please disregard the above, I was telling BS... :o

The cropping has the only purpose to reverse the PointResize which was done to give Yadif more scan lines at the top and bottom to work with. Gavino explains it here:
https://forum.doom9.org/showthread.php?p=1326150#post1326150

[manolito]

Just for the fun of it I just did some test conversions to get a realistic picture of the speed vs. quality ratio for such an interlaced NTSC to interlaced PAL conversion. And the rsults were quite interesting... :eek:

Of the few commercial NTSC DVDs I own only one has true interlaced content, and this is the old "The Hits Collection" by Prince. The quality is not on a par with what people expect today, and it has a 4:3 aspect ratio, but it sure has an historic value.

What I did was to use different resizers and frame rate converters, wrote down the conversion speed and visually compared the results. To see what a frame interpolator like jm_fps can do I added another conversion where after the bobber and resizer I directly converted the frame rate from 59.94 fps to 25 fps progressive using jm_fps.

My test platform was a ThinkPad T 530 with a Core i5 CPU (2 physical cores plus hyperthreading) and 8 GB of RAM running under Win7-64 and using the latest AVS+. Multithreading was enabled and set to 4 threads. All tools were running with their default parameters.

The results are here:
https://we.tl/t-i1UBwnRMCe

The file names reveal the bobber and the frame rate conversion method plus the conversion speed. The most surprising result was the speed of the QTGMC_ChangeFPS compared to the QTGMC_jm_fps conversion. With ChangeFPS the conversion should have been much faster, but it was almost 50% slower than with jm_fps. I can only guess what was going on there. The AVS+ Multithreading probably takes advantage of the fact that both QTGMC and jm_fps use the same MVTools2 plugin. But there may be other reasons...

For the quality of the conversions I really do not see any significant visual differences. So I would probably use the fastest method. What surprised me was the very good quality of the progressive conversion where jm_fps had to convert 59.94 fps progressive directly to 25 fps progressive.

[Cary Knoop]

1. Take the NTSC source and deinterlace to 59.94p
2. Use optical flow to convert to 50p
3. Interlace the 50p source

[manolito]

1. Take the NTSC source and deinterlace to 59.94p
2. Use optical flow to convert to 50p
3. Interlace the 50p source

Did you even bother to read the previous posts in this thread?

1. This is what everybody is doing already
2. What do you mean by "Optical Flow"? Some expensive commercial software? The best what us poor AviSynth users can get is MVTools2 based frame interpolation. And this may be just as good as the commercial offerings.
3. Again this is exactly what everynody is doing here,

[johnmeyer]

Just for the fun of it I just did some test conversions to get a realistic picture of the speed vs. quality ratio for such an interlaced NTSC to interlaced PAL conversion. And the rsults were quite interesting... :eek:
<snip>

The results are here:
https://we.tl/t-i1UBwnRMCeI really love it when people take the time to do these tests.

Thank you!!

The link you provided took me to a 500+ MB file that looked like it might have been a Kiss video. I didn't download it.

I agree that getting better performance from QTGMC is likely due to the multi-threading. I often get 4-5 times the performance with scripts, which are based mostly on MVTools2, when I enable multithreading, and that was with the older MVTools2 versions using the old versions of AVISynth (like 5.8).

The other variable with QTGMC is the preset used. Some of the "slow" presets are indeed just that, whereas the fast presets can rival simple deinterlacers.

As for quality, I have found two ways to test this whenever I do anything with motion estimation. The first is to watch on a big screen TV, using some method to quickly switch between two or more test clips. If I can't tell any difference after two or three viewings, I declare them equal.

The other way is to walk through each test frame-by-frame. This makes is much easier to compare one frame with the next, and I can look at every possible artifact.

However, this approach is not entirely valid because many artifacts don't reveal themselves during playback. In this sense it is a little like MP3 audio compression which throws away the parts of the audio that will be masked by other parts of the sound in that audio file. If you look on a time or spectral display you'll instantly see a difference between the original and MP3 versions, but if the encoding is done right, the original and the MP3 can often sound fairly close to one another when actually played.

So, once again, thanks for doing the test!

[Mounir]

2. What do you mean by "Optical Flow"? Some expensive commercial software? The best what us poor AviSynth users can get is MVTools2 based frame interpolation.

Seems to be a premiere pro plugin, GPU accelerated for smooth slow motion effects

https://www.youtube.com/watch?v=3YE5tff8pqg

[Cary Knoop]

Did you even bother to read the previous posts in this thread?

1. This is what everybody is doing already
2. What do you mean by "Optical Flow"? Some expensive commercial software? The best what us poor AviSynth users can get is MVTools2 based frame interpolation. And this may be just as good as the commercial offerings.
3. Again this is exactly what everynody is doing here,
Not everybody is doing this in this topic.

I would say don't blend frames and only resize right before you interlace the 50p version.

MVTools2 is doing ok for optical flow especially when going down in framerate. It is not as challenging as for instance converting 16p to 24p which is very challenging. I did a comparison with for instance the optical flow operation in DaVinci Resolve and it is of comparable results. Slightly better is the neural approach, This works with Vapoursynth, not sure if it is Avisynth compatible though.

[manolito]

The link you provided took me to a 500+ MB file that looked like it might have been a Kiss video. I didn't download it.

No way, the archive contains 4 different converted to PAL versions of "Kiss" by Prince, so the archive is called "Kiss Variations".

[johnmeyer]

No way, the archive contains 4 different converted to PAL versions of "Kiss" by Prince, so the archive is called "Kiss Variations".Stupid me. A few years back, StainlessS and I came up with a way to undo interlaced resizing artifacts on a video of a Kiss concert, and that was stuck in my head. I didn't know that Prince had a song or album of the same name.

[StainlessS]

and Tom Jones too:- https://www.google.com/search?source=hp&ei=EWVEXqOCPa6ajLsPwf2xmA8&q=tom+jones+kiss&oq=tom+jones+kiss&gs_l=psy-ab.3..0l10.2839.5667..5855...0.0..0.170.1753.1j14......0....1..gws-wiz.....8..0i362i308i154i357j0i131j0i70i251.SGzEQzWv89Q&ved=0ahUKEwjjztf58cznAhUuDWMBHcF-DPMQ4dUDCAc&uact=5

EDIT: Not sure, think is same as Prince song [Author Prince, methinks].

[Floatingshed]

As the originator of this thread I feel a little guilty for not responding. Be assured that I found the discussion very interesting and useful, I simply have nothing to contribute. Thanks.