PAL to NTSC and NTSC to PAL

[old-hack]

I just spent my entire weekend using about every method suggested by folks in this forum (& thread) to convert a PAL source to NTSC. The video conversion isn't a problem unless this is what drives the audio being out of sync. Synching up the audio is. Some conversion techniques say you can just mux the converted video with the original soundtrack. Others say use bsweet. I've used bsweet to convert 25000 to 23976 and 25000 to 29970. Done it. Been there. Audio is still out of sync and I've pretty much given up. Can't be this hard. Maybe it's the authoring program. I've tried IFOEdit and TMPGenc DVD. Can't afford much more.

[Xesdeeni]

I'm sorry you're having such a difficult time. I haven't seen these type of issues. Whenever I convert the frame rate (i.e. change the duration of the video), I have used both BeSweet and AVISynth's built-in conversion to alter the audio without sync issues (although you have to be very careful in AVISynth to keep from losing any precision in your calculations, and of course there is a pitch shift). However, I normally do conversions that don't change the duration at all. In that case I don't touch the audio at all, and I don't have sync issues there either.

Perhaps some more details are needed.

Xesdeeni

[old-hack]

OK. I've resolved myself to figuring this out. I'm re-reading this entire thread to see if I missed something or messed something up. Can you just confirm that the following is the script I should use for PAL DVD to NTSC DVD? If there's a line that should be there that isn't let me know. I took this from one of the web page sources mentioned in this thread.

I'd like to be able to do a conversion where I don't have to modify the audio as well.

Thanks.

# PAL DVD (50 fps) to NTSC DVD (59.94 fps)
LoadPlugin("SmoothDeinterlacer.dll")
LoadPlugin(PluginPath + "MPEG2DEC.dll")
InputVideo = MPEG2Source("PALDVD.d2v")
SmoothDeinterlace(tff=true, doublerate=true)
BilinearResize(720, 480)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4, 1, 2)

[makoto916]

Just wanted to interject and offer a PAL<->NTSC script that has served me very well. I've never had to worry about audio sync, which is a good thing.

Since it's quite long (including comments) I've put the script here (http://www.blainehelmick.com/hosted/PAL_NTSC_Converter.avs) .

It requires this (http://biphome.spray.se/gunnart/video/#deinterlacearea) VirtualDub filter to operate.

I'll admit I've never done a NTSC->PAL with it, but I use it on a semi-daily basis for PAL->NTSC and I've yet to have an unsatisfactory result despite feeding it numerous sources all in various forms, including MPEG-2 and DirectShowSource.

[Xesdeeni]

The bad thing about the Internet is that old stuff stays around a long time :-|

The script makoto916 links is the earliest version of my conversion script. It uses the VirtualDub filter Gunnar Thalin wrote. I ported the filter to AVISynth because:[list=1] the script was so complicated,
the dual nature of the script was slow,
the AVISynth version can operate on YUV space directly, so it's faster
[/list=1]However, the script old-hack quotes shouldn't work at all (sorry, that page needs a refresh). Ahem....

Anyway:

First, make sure you are using AVISynth 2.5 (http://www.avisynth.org).
Next get the 2.5 version of SmoothDeinterlacer (http://www.avisynth.org/warpenterprises/files/smoothdeinterlacer_25_dll_20030218.zip).
Then get DGMPGDec (http://neuron2.net/fixd2v/decodefix.html).
Place all the DLLs in the AVISynth 2.5 plugin directory. That way you can do away with the LoadPlugin() lines.
Use DGIndex like you would DVD2AVI and create your .D2V and .AC3 files.
Then start with this script:MPEG2Source("PALDVD.d2v")
YV12toYUY2(interlaced=true) # Don't use this script if the source is completely progressive
SeparateFields() # Correct bug in...
Weave() # ...SmoothDeinterlacer
SmoothDeinterlace(doublerate=true)Load this script into VirtualDub to make sure the input field polarity is right. Step through the video and be sure it moves smoothly and doesn't jump back and forth (it's OK if some frames repeat, just as long as they don't move backwards). If there is a problem, add ComplementParity() before SmoothDeinterlace().

Then add these lines:LanczosResize(720, 480)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4, 0, 3)
Weave()Load this into your MPEG encoder, but only encode a small portion of video, preferably with some still and some motion. Take a look at this on your TV to be sure the output field polarity is OK. I find that the MPEG encoders vary, so you may have to change back to SelectEvery(4, 1, 2) if things don't look right.

Xesdeeni

[makoto916]

The bad thing about the Internet is that old stuff stays around a long time
Indeed.

Thanks for the update!

[garrem]

Originally posted by Xesdeeni

SeparateFields() # Correct bug in...
Weave() # ...SmoothDeinterlacer




Thanks for all your info in this thread! I have used your method to do a PAL-to-NTSC conversion, and it looks very nice! My one question is, is the above workaround still necessary, or has the smoothdeinterlacer bug you mention been fixed by now? Out of curiosity, what exactly is the bug? Thanks again!

[Xesdeeni]

Originally posted by garrem
Thanks for all your info in this thread! I have used your method to do a PAL-to-NTSC conversion, and it looks very nice! My one question is, is the above workaround still necessary, or has the smoothdeinterlacer bug you mention been fixed by now? Out of curiosity, what exactly is the bug? Thanks again! Unfortunately, as far as I know, the bug is still there. I have not had time to look closely enough at what actually is going on. I suspect that either the input stream's polarity is not always reported correctly, or the frame/field format is wrong. I tested a number of streams before releasing, and never saw a problem. So, I'm naive enough to believe SmoothDeinterlacer isn't really at fault ;). Besides, I'm not even sure how the above work-around works. AFAIK, SeparateFields() and Weave() are exactly opposites of one another, so doing both should effectively be a NOP. As a result, any info available after them had to be available before. And since this doesn't actually change SmoothDeinterlacer, I can't really see how it is SmoothDeinterlacer's fault. Also, see note below...

All that being said, I was recently pointed to KernelDeint/KernelBob (http://forum.doom9.org/showthread.php?s=&threadid=81322) by scharfis_brain. I've modified my conversion script to use this instead, and the results are at least as good as with SmoothDeinterlacer. Also, they appear to be faster with the older script-based KernelBob. The above-linked version should be faster still. So while it pains me to say this, I'd recommend using KernelDeint instead.

I'm trying to get some time to update my standards conversion web page. I intend to streamline it to a smaller set of conversions, with more explanation to enable people to handle the more unique situations they seem to hit. And in addition to switching to KernelDeint, I will use AVISynth 2.5 and DGMPGDec instead of DVD2AVI.

Note also, that in the course of testing KernelDeint/KernelBob, I found a similar problem to the one in SmoothDeinterlacer. I tried a bunch of things, although the SeparateFields()/Weave() trick didn't seem to work. I eventually found that I was able to correct the problem by explicitly using AssumeFrameBased()/AssumeFieldBased() as appropriate. My scripts are at home, but I'll post them on my web page when I update it.

Xesdeeni

[Clown shoes]

Hi Xesdeeni,

would you mind showing an example of the your script using the new Kerneldeint as I am having difficulty getting it to work well. The results look really bad and stuttery.

Cheers.

[Xesdeeni]

These should give you the idea:

PAL to NTSCAVISource("PALDV.avi") # Interlaced PAL input from DV (bff, 25i fps)
AssumeFrameBased() # Just in case
AssumeBFF() # Just in case (redundant with order=0 below?)
KernelBob(order=0) # Order = 0 for bff, 1 for tff => 50p fps
LanczosResize(720,480) # Convert to NTSC size, still at 50p fps
ChangeFPS(59.94) # Use replication...
#ConvertFPS(59.94) # ...or interpolation to change to 59.94p fps
AssumeFrameBased() # Just in case
AssumeTFF() # Makes frame 0 become even field below
SeparateFields() # We will be throwing out 1 of each pair
SelectEvery(4,0,3) # Choose even then odd, or TFF (use AssumeBFF()...
# ...or SelectEvery(4,1,2) here for BFF
Weave() # Combine fields for encoderNTSC to PALAVISource("NTSCDV.avi") # Interlaced PAL input from DV (bff, 29.97i fps)
AssumeFrameBased() # Just in case
AssumeBFF() # Just in case (redundant with order=0 below?)
KernelBob(order=0) # Order = 0 for bff, 1 for tff => 59.94p fps
#ChangeFPS(50) # Use replication...
ConvertFPS(50) # ...or interpolation to change to 50p fps
LanczosResize(720,576) # Convert to PAL size, still at 50p fps
AssumeFrameBased() # Just in case
AssumeTFF() # Makes frame 0 become even field below
SeparateFields() # We will be throwing out 1 of each pair
SelectEvery(4,0,3) # Choose even then odd, or TFF (use AssumeBFF()...
# ...or SelectEvery(4,1,2) here for BFF
Weave() # Combine fields for encoderAs always, test a small clip containing still and motion to be sure the output polarity is correct. However, I think I've figured out that the polarity throughout AVISynth scripts isn't always consistent (I'm sure the AVISynth team will shoot me, but I can't explain some of the things I've seen otherwise, and AssumeTFF()/AssumeBFF() seem to fix them). So I have a good feeling that AssumeTFF() + SeparateFields() + SelectEvery(4,0,3) will give you TFF, while AssumeTFF() + SeparateFields() + SelectEvery(4,1,2) (or AssumeBFF() + SeparateFields() + SelectEvery(4,0,3)) will give you BFF. And given that DV is BFF and DVD is TFF, the only variable left should be the encoder itself.

Note that for DVD content, I recommend DGMPGDec (http://neuron2.net/fixd2v/decodefix.html). Using that, you would use MPEG2Source() in place of AVISource() above. However, the output of MPEG2Source() is YV12, which some filters can't handle. ConvertFPS() is one. And your codec might not accept this either, so there may be another conversion performed outside of your script on the input to the codec. Unfortunately, there is a bug with some versions of the Microsoft converter (I don't know if it's fixed in XP) that causes color gradients (bands), so it's a good idea to pay attention to what your codec prefers as an input and serve that.

Xesdeeni

[jkbauer]

hello Xesdeeni,

There is a lot of great info here, just a bit difficult to grasp. I been through this thread trying to figure out the best way to convert my PAL dvd (25fps) to a NTSC dvd. Frankly, I am running into a bunch of trouble.

I copied your script and saved as .avs, but TMPGEnc always gives me an error with line 1, cannot load file. The path is definitely correct. When I load this script in VirtualDub (Run Script), I get the same error message. I can't figure out what I'm doing wrong.

Out of curiousity, I loaded the d2v file directly as the video source, and the output was ok, but not very smooth during playback.

Any help would be appreciated.

[easy2Bcheesy]

Originally posted by jkbauer
hello Xesdeeni,

There is a lot of great info here, just a bit difficult to grasp. I been through this thread trying to figure out the best way to convert my PAL dvd (25fps) to a NTSC dvd. Frankly, I am running into a bunch of trouble.

I copied your script and saved as .avs, but TMPGEnc always gives me an error with line 1, cannot load file. The path is definitely correct. When I load this script in VirtualDub (Run Script), I get the same error message. I can't figure out what I'm doing wrong.

Out of curiousity, I loaded the d2v file directly as the video source, and the output was ok, but not very smooth during playback.

Any help would be appreciated.

Are you actually sure you have AviSynth installed? I hope I'm not insulting you by suggesting such a simple error, but if your path is correct, that strikes me as a possible fault...

[Wilbert]

Please, post exact script!

[jkbauer]

Sorry. I should be more clear. The script/instructions I followed were from Xesdeeni's earlier post above.

First, make sure you are using AVISynth 2.5.
Next get the 2.5 version of SmoothDeinterlacer.
Then get DGMPGDec.
Place all the DLLs in the AVISynth 2.5 plugin directory. That way you can do away with the LoadPlugin() lines.
Use DGIndex like you would DVD2AVI and create your .D2V and .AC3 files.
Then start with this script:
code:
-----------------------------------
MPEG2Source("FILEPATH.d2v")
YV12toYUY2(interlaced=true) # Don't use this script if the source is completely progressive
SeparateFields() # Correct bug in...
Weave() # ...SmoothDeinterlacer
SmoothDeinterlace(doublerate=true)
-----------------------------------
Load this script into VirtualDub to make sure the input field polarity is right. Step through the video and be sure it moves smoothly and doesn't jump back and forth (it's OK if some frames repeat, just as long as they don't move backwards). If there is a problem, add ComplementParity() before SmoothDeinterlace().

Then add these lines:
code:
-----------------------------------
LanczosResize(720, 480)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4, 0, 3)
Weave()


Avisynth should be installed. I downloaded the latest 2.5.5 and ran through the install procedure. I also made sure that I loaded all the necessary dlls into the plugin folder under Avisynth (SmoothDeinterlace.dll, MPEG2Dec3dg.dll, DEDecode.dll, Decomb.dll, and a couple of others). For some reason, I keep getting the error for line 1 (cannot load file).

Thanks for the help.

[easy2Bcheesy]

OK, so those are the instructions and they look fine - can you post your exact script?

[Xesdeeni]

When you load the script into VirtualDub, load it exactly as you would an AVI (File|Open video file...). If it loads there, then you have AVISynth installed correctly.

Xesdeeni

[Wilbert]

Just start with the following (two line) script

MPEG2Source("c:\file.d2v")
ConvertToYUY2()

and replace c:\file.d2v with the actual path of your d2v. Open it in VDub/VDubMod to see whether you see something.

[jkbauer]

Just to be sure, I ran the install for Avisynth 2.5.5 again, and it said install was successful. I am pretty sure that it is installed on my system. I believe DVD-rebuilder needs Avisynth to work properly. That programs works fine.

I have tested again and still get the same error:
"MPEG2Source: Could not find file. ("PATH\FILENAME.avs, line 1")"
This error occurs in both VDub and TMPGEnc.

What I am doing:
- Decrypt a PAL dvd to the HD (this is not a movie house dvd, but rather a video recording of an event convert to dvd format). Contents are PAL 704x576, MPEG2, 4:3, 25 fps, Interlaced.
- Open vob in DGMPGDec and Save Project to create d2v and ac3 files
- Create script in Notepad and save .avs file

I am positive that the file path is correct in the script. I used the basic 2 line script. Is there any other way to see if Avisynth is installed correctly?

Thanks again for the help.

[easy2Bcheesy]

Please post your exact script. Go on, you know you want to!

[jkbauer]

Just to be clear:
I used the basic 2 line script suggested by Wilbert above:

MPEG2Source("c:\file.d2v")
ConvertToYUY2()

and replace c:\file.d2v with the actual path of your d2v. Open it in VDub/VDubMod to see whether you see something.

[jkbauer]

Sorry. I usually follow instructions better.
My exact script is:

MPEG2Source("D:\TEMP\convert\pal2ntsc.d2v")
ConvertToYUY2()

The d2v, ac3 and avs files are all in the same directory.

[Wilbert]

You can see whether avs is installed correctly by making script

Version()

and opening in VDubMod. However I suspect you installed it correctly.

1) You didn't move your d2v on your hdd?

2) Could you remove all mpeg2dec*.dll from the avs plugin dir, except: DGDecode.dll, and try again? Use DGIndex to make the d2v file:

http://neuron2.net/fixd2v/decodefix.html

[jkbauer]

Thank you very much Wilbert.

I no longer get the path/file error in VDub. VDub and TMPGEnc did not like the MPEG2Dec3dg.dll. When I remove it from the plugins folder, the programs work fine. I have this particular dll because of DVD-Rebuilder. It turns out that DVD-RB is not compatible with older versions of this dll.

Unless I have misunderstood earlier posts/instructions on this thread, I need to have MPEG2DEC.dll. I cannot seem to find a version earlier than MPEG2DEC3dg.dll. Any suggestions?

Thanks again.

[jkbauer]

I did some more digging around and found a MPEG2DEC.dll file that worked.

MPEG2DEC3dg.dll is not compatible with VDub, but I need to have this for DVD-RB to work. Does anyone have suggestions so that I can get both programs working without having to "swap" dll files?

[Wilbert]

MPEG2DEC3dg.dll is not compatible with VDub
Yes, it's compatible with VDub. You just need the right dvd2avi (to make the d2v), ie the version you got with DVD-RB.

[jkbauer]

Sorry it took so long to get back to everyone with a big THANKS!
I finally gave it a try and it works! It was really painless.

For the most part, the conversion result was pretty good.

My first test - I did a quick (Normal) conversion (TMPGEnc) of a 30 min clip. The video was watchable, but when the scene involved a lot of movement, it seemed to blur a bit.

My second test - I ran it in the Highest Quality mode. The overall video was noticeably better, but I got strange occurences at various places. Certain times areas (lines) would blur or stretch (horizontally) for a second. Sorry, I know the explanation is not very clear, but hopefully someone may know what I might be experiencing.

The script that I used (from Xesdeeni's earlier post)
-----------
MPEG2Source("PATH/FILENAME.d2v")
YV12toYUY2(interlaced=true) # Don't use this script if the source is completely progressive
SeparateFields() # Correct bug in...
Weave() # ...SmoothDeinterlacer
SmoothDeinterlace(doublerate=true)

LanczosResize(720, 480)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4, 0, 3)
Weave()
------------

I tried SelectEvery(4, 1, 2) as well, but it didn't seem to help.
Hopefully, someone has some tricks I could try to fix the problem. Regardless, getting this far was pretty good for a first time. Fortunately I won't be doing too many of these conversions. Thanks again.

[Kika]

Use KernelBob(order=1, sharp=true, twoway=true, threshold=0) instead of SmoothDeinterlace(doublerate=true)

And try ConvertFPS() instead of ChangeFPS()

[jkbauer]

Thank you for the reply. I am going to try this method now.
I just realized that my first attempt at the NTSC conversion resulted in combined files at >7 Gb. The original was only about 4 Gb. Is this normal?

I used TMPGEnc and encoded in Automatic VBR at the High Quality setting.

Thanks again to everyone for all the help.

[Kika]

The original was only about 4 Gb. Is this normal?

More or less... it depents on your Settings (Bitrate and so on).

Automatic VBR at the High Quality setting

I suggest you to use CQ (Constant quality)

[jkbauer]

I tried your suggestion and ran the conversion using CQ option. The resulting file size is now close to the original (~4 Gb). With the Auto VBR option, the converted file size was nearly twice as large.

Am I sacrificing a lot of quality using the CQ option instead? I can't really tell on my small monitor.

[Zeul]

wow this is a complicated thread :D
I have added the option in NuMenu4u to allow standard conversions. Everything lines up nicely in Scenarist, so I now only need to finalise the scripts to use.

I have no desire to alter the play time, so the audio requires no post-processing.

From what I can see I am going to requires scripts for the following situations:

PAL(i) -> NTSC(i)
PAL(p) -> NTSC(i) or NTSC(p)[ie film]
NTSC(i) -> PAL(i)
NTSC(p)[ie film] ->PAL(i) or PAL(p)

also, many of the menus in NTSC land are a combination of hybrid, telecined, film and interlaced. Because each vob/cell is encoded seperately, I can afford to have specific scripts targeted to each.

Do you suggest doing a progressive -> progressive conversion OR always convert the source into interlaced output.
many of the assets to be encoded will be stills, any special suggestions?

The scripts below were sent to me sometime ago: Suggestions?

#PAL (25i) -> NTSC (29.97i)
LoadPlugin("C:\xxx\SmoothDeinterlacer.dll")
SmoothDeinterlace(doublerate=true,tff=true,lacethresh=24,staticthresh=35,showlace=false)
LanczosResize(720,480)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4,0,3)
Weave()
AddAudio()
ConvertToYUY2(interlaced=true)

#PAL (25p) -> NTSC (23.976p)
mpegsource...
LanczosResize(720,480)
ChangeFPS(23.976)
AddAudio()
ConvertToYUY2() -> followed by pulldown to set the flags

#NTSC (29.97i) -> PAL (25i)
LoadPlugin("C:\xxx\SmoothDeinterlacer.dll")
SmoothDeinterlace(doublerate=true,lacethresh=24,staticthresh=35,showlace=false)
LanczosResize(720,576)
ConvertFPS(50)
SeparateFields()
SelectEvery(4,0,3)
Weave()
AddAudio()
ConvertToYUY2(interlaced=true)

#NTSC (23.976p) -> PAL (25p)
mpegsource...
LanczosResize(720,576)
ConvertFPS(25)
AddAudio()
ConvertToYUY2()

As an edit:
I just found this script for progressive -> progressive (with pulldown) which results in very smooth playback. Of course with this script the audio must be rescaled:

LoadPlugin("MPEG2DEC3.DLL")
mpeg2source("D:\MOVIE\VIDEO_TS\movie.d2v")
LanczosResize(720,480)
AssumeFPS(23.976, true)
ConvertToYUY2()
AddAudio

thanks for any guidance :)
Zeul

[Kika]

They are looking very similar to my old Scripts. Meantime, i'm using Kernelbob(order=1, sharp=true, twoway=true, threshold=0) instead of SmoothDeinterlace(blablabla). Like i posted earlier here.

And the following Script contains an Error:

#NTSC (23.976p) -> PAL (25p)
mpegsource...
LanczosResize(720,576)
ConvertFPS(25) <-- Change this Line to AssumeFPS(25)
AddAudio()
ConvertToYUY2()

[Zeul]

thanks Kika, will give that a try. BTW u know of an accurate audio processor to rescale audio - besweet will use the ac3enc that AFASIK still doesn't make compliant ac3 streams.

[Zeul]

also, the kernelbob script - is this the same for pal -> ntsc and vice versa?

[Xesdeeni]

If you don't want to process the audio (which I actually recommend), the most straightforward way is to always go to interlaced:

PAL(25i) -> NTSC(30i)

Here, 50 fields are converted to 60 fields. With our current tools (after deinterlacing), you have the choice of replication, partial frame, or interpolation. Partial frame results in tearing, which can be distracting. ConvertFPS() can do a blend at the edge, but I still don't recommend this. For PAL to NTSC, I find interpolation much more annoying than replication. But interpolation is closer to the "four-field" conversion used by professional converters. Of course, I'd recommend giving the user the option.

PAL(25p) -> NTSC(30i)

This closely resembles telecining film. Instead of a 2:3 pulldown, you get a 2:2:3:2:3 sequence. It jutters, but not much differently than telecined film, which NTSC viewers are used to. The only difference between this and the above conversion, is that deinterlacing is just field matching (in case the two fields you choose aren't in sync with the pair used for each frame), which is much less processor hungry.

NTSC(30i) -> PAL(25i)

In this case, the choices are decimation, partial frame, and interpolation. I still don't recommend partial frame for the reasons above, but in this case you actually throw out part of every source frame. This is also the reason decimation probably isn't the best. To convert from 60 progressive (deinterlaced) frames per second to 50, you have to throw out 10 frames every second. That's a lot of lost data. So in this case (although I still recommend a user option), I recommend interpolation.

NTSC(24p) -> PAL(25i)

This is the most difficult. It's obviously best to speed up and go to 25p instead. But as you mentioned, you need to process the audio. Apparently AVISynth now does this, but these algorithms don't work all that well across the entire audio spectrum (if dialog sounds OK, background music will sound weird, etc.). I haven't seen what 2:2:2:2:2:2:2:2:2:2:2:3 pulldown looks like, but I suspect the bumps might be very visible, spaced 1/2 second apart as they are.

Perhaps someone who lives where there are PAL TVs can give us an idea of whether this is too bad to use as a choice?

Also keep in mind that all of the above numbers were rounded. NTSC is really 29.97i, which complicates things even more. It also makes interpolation worse than it needs to be. One way I've been considering is to divide the video into pieces, and treat them as 30i. At the boundaries, I'd compensate for the difference, but during the piece, interpolation could be simple fractions (e.g. A, .2*A+.8*B, .4*B+.6*C, .6*C+.4*D, .8*D+.2*E, E).

Xesdeeni

[Zeul]

thanks for the info Xesdeeni
I have spent all day working on this and have got PAL -> NTSC off nicely. The scripts i decided upon are:

# PAL 25i -> NTSC 29.97i
mpeg...
LoadPlugin("C:\Build\new.avs\kerneldeint.dll")
Kernelbob(order=1, sharp=true, twoway=true, threshold=0)
LanczosResize(720,480)
ConvertToYUY2(interlaced=true)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4,0,3)
Weave()
AddAudio()

# PAL 25p -> NTSC 23.976p + pulldown
mpeg...
LanczosResize(720,480)
ConvertToYUY2()
ConvertFPS(23.976)
AddAudio()

Now it seems to my ears that in both these cases no audio processing is required, please confirm. (D3s7 and myself have been having a debate on this :D ) BTW ConvertFPS seems to give very smooth playback for the progressive material, and Kernelbob seems better than smoothdeinterlace (thanks to Kika for that one).

[Xesdeeni]

Originally posted by Zeul
thanks for the info Xesdeeni
I have spent all day working on this and have got PAL -> NTSC off nicely. The scripts i decided upon are:

# PAL 25i -> NTSC 29.97i
mpeg...
LoadPlugin("C:\Build\new.avs\kerneldeint.dll")
Kernelbob(order=1, sharp=true, twoway=true, threshold=0)
LanczosResize(720,480)
ConvertToYUY2(interlaced=true)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4,0,3)
Weave()
AddAudio()Well, if you set the threshold to 0, you are doing the same thing as Bob(). Also, if you do the color space conversion before the XXXBob(), you'll be doing half the conversion (25 fps instead of 50 fps). But I'm not sure ChangeFPS() needs the conversion, only ConvertFPS() does.# PAL 25p -> NTSC 23.976p + pulldown
mpeg...
LanczosResize(720,480)
ConvertToYUY2()
ConvertFPS(23.976)
AddAudio()Ech! You are getting two bad things. First, you are using ConvertFPS(), which interpolates your 25 to 24. And you are not taking advantage of the interlaced nature of NTSC for smoothness. In the end, you'll have the interpolation AND replication, due to 2:3 pulldown. This might compress a bit better, but it should look worse. Use something like this:

MPEG2Source("PAL-25p.d2v")
Telecide(order=1, guide=2) # Not usually necessary
LanczosResize(720, 480)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4,0,3)
Weave()Now it seems to my ears that in both these cases no audio processing is required, please confirm. (D3s7 and myself have been having a debate on this :D ) BTW ConvertFPS seems to give very smooth playback for the progressive material, and Kernelbob seems better than smoothdeinterlace (thanks to Kika for that one). You are right, neither conversion requires a change to the audio. In fact, you should not process the audio at all. Extract it with DGIndex, and don't touch it until you are ready to author your DVD. Don't fed it through AVISynth, since that will decode it, and then you'll have to re-encode it, which will cause a quality loss.

Xesdeeni

[Zeul]

MPEG2Source("PAL-25p.d2v")
Telecide(order=1, guide=2) # Not usually necessary
LanczosResize(720, 480)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4,0,3)
Weave()

well i tried this and the output was horrible (on the PC at least)

[Kika]

@Zeul

For a propper Conversion from PAL 25p to NTSC 23.976p, neither Telecide nor ConvertFPS is needet. Just slow down the Speed of the Video.

MPEG2Source("PAL-25p.d2v")
LanczosResize(720, 480)
ChangeFPS(23.976)

Encodet it with 3:2-Pulldown-Flag ON.

But you should use an Audio-Editor to convert the Audio-Part or the Advanced AVISynth-Commands for Audio-Processing (i'm not familiar with these too...)
From my point of view, it is much better to keep Video-Quality at the highest Level than Audio. That's why i suggest to slow down and pitch the Audio-Part.


Well, if you set the threshold to 0, you are doing the same thing as Bob().

Yes, but in a better way.

[Xesdeeni]

Originally posted by Zeul
MPEG2Source("PAL-25p.d2v")
Telecide(order=1, guide=2) # Not usually necessary
LanczosResize(720, 480)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4,0,3)
Weave()

well i tried this and the output was horrible (on the PC at least) Can you be more specific? Remember that PC viewing of an interlaced video will look bad. That's OK, since the PC is progessive. It will look right on the TV.Originally posted by Kika
For a propper Conversion from PAL 25p to NTSC 23.976p, neither Telecide nor ConvertFPS is needet. Just slow down the Speed of the Video.

MPEG2Source("PAL-25p.d2v")
LanczosResize(720, 480)
ChangeFPS(23.976)That doesn't slow down the video. It will convert the frame rate, but the speed will be the same. If you want to slow down the video, you use AssumeFPS(23.976)...but I don't recommend it, since you have to also slow down the audio.But you should use an Audio-Editor to convert the Audio-Part or the Advanced AVISynth-Commands for Audio-Processing (i'm not familiar with these too...)
From my point of view, it is much better to keep Video-Quality at the highest Level than Audio. That's why i suggest to slow down and pitch the Audio-Part.Each to his/her own. But audio, especially for movies, generally has a large dynamic range and frequency coverage. Most techniques that change the speed without changing the pitch (at least those we can get access to in our domain) introduce distortion at one or more frequency ranges. Of course, you can slow the audio and let the pitch go down, but I find that really weird sounding too.

Also, lots of content is 5.1. This means handling 6 channels of sound, which I've found to be pretty cumbersome.

Anyway, as I said, we view 24 frames/s telecined to 60 fields/s every single day and don't really notice. 25 frames/s telecined to 60 fields/s doesn't look much different, and there isn't any need to adjust the audio at all.Well, if you set the threshold to 0, you are doing the same thing as Bob().Yes, but in a better way.I'm not sure why. I thought KernelDeint() had a better scaling algorithm, but I haven't been able to find an image on which I can see the difference. And Bob() will be much faster.

Xesdeeni

[Kika]

That doesn't slow down the video. It will convert the frame rate, but the speed will be the same. If you want to slow down the video, you use AssumeFPS(23.976)...

Oops, right. Darn Copy & Paste. ;)

I thought KernelDeint() had a better scaling algorithm, but I haven't been able to find an image on which I can see the difference. And Bob() will be much faster.

It's only because of the Scaler. The difference is visible by some flickering in some Areas with small lines etc. on the TV.
I'm doing alot of PAL <-> NTSC Conversions. First i used Bob(), then SmoothDeinterlace(), now KernelBob() which is a very good compromise in Speed and Quality (imho).

About conversion to interlaced Video... Sure, the difference is not really visible, but you need much more Bitrate for encodings like that. And don't forget the users of Beamers. They might prefer progressive Video.
But you are right, Audio-Speedp/Slow-Down isn't an easy job, especialy on 5.1-Audio. You need damn good tools to do that.

[scharfis_brain]

if you want to achieve 'better' scaled files, use tdeint(mode=1) it does edge directed interpolation.

the only thing, I love about kerneldeint is, that it reduces flickering an improves resolution with fieldblended video (only if set up correctly!).
But I really dislike its jaggy diagonales and edge ghosts.

this is, why I am using tdeint.
slight more flicker, but better defined image.

and - uhm - threshold = 0 is terrible IMO.
if converting some shaky DV-Footage without static areas this may suffice but with TV-show like video the static areas are turned into a weird womble-effekt (no field flicker, it's worse!)

[Kika]

and - uhm - threshold = 0 is terrible IMO. if converting some shaky DV-Footage without static areas this may suffice

I mostly convert Camcorder-Footage. On Source like this, i get realy good results. But there are so many different Deinterlacers now, is there any List with theirs pros and cons?

[Xesdeeni]

Originally posted by Kika
About conversion to interlaced Video... Sure, the difference is not really visible, but you need much more Bitrate for encodings like that.I've spent some time with the MPEG-2 specification. While I can't tell whether the encoders are using it, the specification allows for great flexibility in encoding interlaced frames. It looks like, if the encoder is smart enough, it can inverse the telecine and encode progressively. It can even encode progessively on purely interlace video, for frames or areas of frames that don't move! So while there will be more data, it seems like it could be negligible if the encoder is decent enough.

BTW, on a related note. I was examining some streams from Dish, and their encoders apparently do just this. For telecined video, a few frames at a switch would be interlaced, but then it would switch to progressive and encode fewer frames. The MPEG-2 decoder in VirtualDubMod apparently doesn't deal with this very well, so the video actually appeared to change speeds as it missed virtual fields, which is how I noticed. DGIndex/DGMPEG didn't have a problem with it.

But even if the encoders we use aren't as sophisticated as they might be, I've gone through both methods (I even ported an audio converter before one was available in AVISynth or BeSweet), and the audio headache isn't worth it. It takes more time, there are audible distortions, and synchronization is an issue.And don't forget the users of Beamers. They might prefer progressive Video.What does an expensive car have to do with this?

Xesdeeni

[Zeul]

Originally posted by Xesdeeni
Can you be more specific? Remember that PC viewing of an interlaced video will look bad. That's OK, since the PC is progessive. It will look right on the TV.
Xesdeeni

well the strangest thing has happened. I re-encoded again, and this time the output is very clear. Previous encode had lots of 'flashing' is the only way I can describe it. But whatever I do in the CCE settings, I can't replicate it. Damn strange. Anyhow glad to say this script looks very clean. Personally I can't see a difference with the ConvertFPS(23.976) script, but I am not testing on the TV yet, only viewing on the PC. Perhaps any problems would show up more on the big set.

BTW is ConvertToYUY() still required, and with (interlaced=true) for interlaced scripts.
And when would [Telecide(order=1, guide=2) # Not usually necessary] be required.

[Xesdeeni]

Originally posted by Zeul
Personally I can't see a difference with the ConvertFPS(23.976) script, but I am not testing on the TV yet, only viewing on the PC. Perhaps any problems would show up more on the big set.I would guess that is right. On a PC (unless your player is deinterlacing), the interlacing artifacts will probably overshadow anything else. The different between ChangeFPS() and ConvertFPS() will be visible on steady motion, like a camera pan. ConvertFPS() will show something I refer to as a "reverse strobing." (One of these days I'm going to make a sample and post it on my web site.) ChangeFPS() will show what I call a "bump" a few times a second on video, but shouldn't be any different than telecine on film.BTW is ConvertToYUY() still required, and with (interlaced=true) for interlaced scripts.Not for ChangeFPS(), but I think ConvertFPS() needs it (or ConvertToRGB()). And yes, if your source is interlaced, set it to true. If the source is PAL telecined film, then you can set it to false. But this assumes the source is encoded correctly. You take a look at the difference and see the effects.And when would [Telecide(order=1, guide=2) # Not usually necessary] be required. 25 fps film on PAL will put one frame every two fields. Most of the time, when you decode, the frame you get from the codec will contain both fields of the same frame. Now and then, things go wrong and you get one field from to adjacent frames. You can fix this manually by SeparateFields()/Trim(1,0), if the whole video sync is the same. But rarely, the sequence changes at edit points (it's difficult to edit on field boundaries, but I've seen it at commercial cuts), so you'd have to manually break the program up and handle each part separately. Telecide can do this work for you. But it definitely slows things down, so don't use it unless you have to.

Xesdeeni

[Kika]

It looks like, if the encoder is smart enough, it can inverse the telecine and encode progressively. It can even encode progessively on purely interlace video, for frames or areas of frames that don't move! So while there will be more data, it seems like it could be negligible if the encoder is decent enough.

That's right, but there are not many Encoders in the Consumer range which are able to encode Video this way. As far as i know only ProCoder and mpeg2enc are able to do this.


What does an expensive car have to do with this?

Nothing... imho. But look at some discussions here about interlaced Video. Especially the last one about HDTV i was involved. :cool:

ConvertToYUY() still required, and with (interlaced=true) for interlaced scripts.

For quality reasons..., yes. That's this darn thing with the Chroma-Upsampling.

[scharfis_brain]

do NOT converttoyuy(interlaced=true) before the deinterlacing!

Deinterlace in YV12 and do the conversion to YUY2 directly BEFORE convertfps() this helps chroma quality a LOT.

[Kika]

do NOT converttoyuy(interlaced=true) before the deinterlacing!

Guess, this depents a bit in how the Deinterlacer internaly works.
That's a thing, the programers of the Deinterlacers have to explain, but as far as i know, it is better to perform converttoyuy(interlaced=true) if you want realy "clean" fields.

Maybe i'm wrong here, deinterlacing isn't my special Field. Will you please explain a little, why you prefer to convert after the Deinterlacing, not before?

[Xesdeeni]

That's right, but there are not many Encoders in the Consumer range which are able to encode Video this way. As far as i know only ProCoder and mpeg2enc are able to do this.I'm not sure how to go about analyzing this, but I suspect if ProCoder does it, CinemaCraft (which I use) does as well. Maybe you know of a way to verify this?do NOT converttoyuy(interlaced=true) before the deinterlacing!

Deinterlace in YV12 and do the conversion to YUY2 directly BEFORE convertfps() this helps chroma quality a LOT.Yes, maybe you can explain that.

As I understand it, YV12 (4:2:0) combines chroma across lines. And since fields can be stored paired into frames, chroma can be shared between fields. Deinterlacing requires you to separate those fields, so you have to extract the chroma in a similar way to converting to YUY2 (4:2:2).

The reason I haven't taken the time to update SmoothDeinterlace (well, in addition to two small children that take most of my time :) ), is because I would have to handle extracting the chroma correctly from each field, and then re-combining them so the resulting frames shared the chroma again, in accordance with YV12 format. (The combinations and permutations of separated fields, progressive frames, etc. was enough to put me off in my first attempt.)

Converting YV12 to YUY2 after the deinterlacer would seem to be redundant, since in the middle of the deinterlacing, you would effectively have 4:2:2 data before combining back to 4:2:0.

Also doing the conversion before deinterlacing (well, bobbing, as we are discussing here) means you convert pairs of fields, which is half the number of frames as the progressive output of the deinterlacers.

But maybe I'm missing something?

Xesdeeni