PAL to NTSC and NTSC to PAL [Archive]

easy2Bcheesy

9th February 2003, 14:26

I've noticed many posts in the past about the process of converting footage from one format to another, either NTSC to PAL or PAL to NTSC.

I've come to the conclusion that the best consumer level tool to get is **easily** Canopus ProCoder. It's far superior to any avisynth script I've seen, and almost as good as some of the enormously expensive production house converters.

First of all, it's incredibly easy to use - you can input quicktimes, avis, anything - and just specify the output format (MS DV PAL/NTSC, Quicktime PAL/NTSC, MPEG2 PAL/NTSC)...

What I'm doing is recording UK TV shows onto my Philips DVD Recorder and then re-encoding them into NTSC using ProCoder to send to my friends in the USA. So in this case, PAL to NTSC. I use a lot of NTSC to PAL conversion footage at work, so I've tested both.

You simply demux the VOBs elementary files (M2V and AC3) and input the M2V into ProCoder, set up to output NTSC. I used a 1-Pass VBR at 'Highest Quality'. It's not fast (4.3fps on my 1.2gig Athlon) but the results are almost as good as some of the commercial £80,000 standards converters I've used.

I've also used ProCoder's NTSC to PAL conversion. Again, the quality is more than acceptable. The NTSC to PAL conversion is much better than the PAL to NTSC conversion. This is because it's stripping frames out of the former and blending them, as opposed to the latter where it is having to create new frames.

I've just done two two-hour sets of footage and the sync is PERFECT. It's even *exactly* the same length as the input footage. So no lip sync problems at all.

Most of the current conversion methods I've seen on field-based footage involve deinterlacing at some point - not good when you're effectively halving the clarity of the picture. ProCoder has a pretty decent field-blending algorhythm and keeps detail high. Impressive.

I've yet to try either process on progressive frame footage, but the results will obviously be a lot better (just resizing of frames and blending, no mucking about with blending fields).

I do a lot of standards conversion at work and I think that for this feature alone, ProCoder is worth getting at $699.

Swan

9th February 2003, 19:25

For most people like me, who are not making any money out of video editing, Procoder costs way too much. 699 dollars, plus you're forced to use a USB dongle? That is not a tool for hobbyists. The dongle would drive me insane too. :)

I've been experimenting with aDVanced DV PAL/NTSC Converter which is much cheaper tool (it costs US$98, Euro 98) and produces nice results too. It only works with video in avi-format, but I believe Mpeg support is intended for future releases. The results from my PAL to NTSC tests are very impressive.
http://www.dvunlimited.com/

/Maria

easy2Bcheesy

10th February 2003, 10:52

I've tried this and it's terrible with interlaced footage - not useable at all IMHO. The motion detection algorhythm seems unable to cope with very complex scenes.

But there's a free trial download so people should give it a go and see you how get on with it.

As for ProCoder being expensive for the home user, CCE costs twice as much and yet it seems the majority of posters on this forum own it! ;)

easy2Bcheesy

10th February 2003, 13:03

Just noticed that a new version of the utility mentioned was uploaded on Jan 13, 2003, so I took a look at it.

Both frame-blending and motion interpolation options seem to be little changed from the last version I looked at. Certainly on converting NTSC interlaced footage to PAL, ProCoder is far, far superior.

Swan

10th February 2003, 18:03

Thanks for the info.
Yes, I tested with the latest version of aDVanced DV PAL/NTSC Converter.
Are you using the latest version of Procoder?
What is the version number of it?

I am mainly looking into a good solution for converting PAL to NTSC. It's my American friends that are causing the problem. :)
I want to be able to send material to them on an SVCD disc (and later DVD), and that's what's making me to look for a software standards converting solution. From PAL to NTSC.

/Maria

Xesdeeni

10th February 2003, 19:22

An AVISynth-based standards conversion script can be very good. It's as flexible as AVISynth as far as input and output formats, and it's free.

I originally posted a generic script that uses my AVISynth port of Gunnar Thalin's SmoothDeinterlacer (http://forum.doom9.org/showthread.php?s=&threadid=35387) complete with comments on use. That seems to have been a bit too daunting for many, probably because the script looks too long and complicated, and also because AVISynth itself (and the various codec issues it exposes) is complex as well.

To simplify things a bit and provide step-by-step conversions for as many source and destination formats as possible, I started my work in progress (so please be kind) Standards Conversion web page at http://www.geocities.com/xesdeeni2001/StandardsConversion/index.html.

One professional videographer who has been working with me on NTSC (Video) DVD to PAL DVD conversion says:
"The result...was absolutely amazing, far better than I had ever hoped for.
...I’m sure it would rival the best of conversion processes as far as smoothness goes and over the years I’ve seen many. Very few people would not believe that the source did not come from PAL."I'm not sure it's quite that good :rolleyes:, but if I do say so myself, it's very good.

It might be a bit rough at first, but did I mention it's free?

Xesdeeni
(yahoo.com has a Xesdeeni2001 address for me)

SomeJoe

10th February 2003, 19:45

I was browsing around the net and ran across this (http://www.matthiasm.com/pal.html) technique. The only thing required is Premiere, and the author says the results are very good. I haven't tried it myself, but I'd be interested to hear some opinions/comparisons.

Swan

11th February 2003, 00:24

@Xesdeeni
I did seee your script and gave it a shot a month ago (or more). Yes, it was too complicated for me. I am not very good with Avisynth, besides a simple fade in and out or something like that. I'll look into your guide and test it again. It's great that you take an interest in PAL to NTSC to this extent.;)
My source material will be PAL DV (avi) video and I want to make NTSC SVCDs.
I may have missed it, but don't see anything about color conversion in your script, doesn't one need to do some conversion in that area too? Or is that irrelevant in the Mpeg-world? It's just 4:2:0?

@SomeJoe
I will test the method you discovered too.

But why is so often deinterlacing mentioned when it comes to PAL to NTSC conversion?
I do not want to deinterlace, just in a clever way, by interpolation or similar, add enough frames (and fields) from the original PAL video, so it gets to be converted to NTSC.

easy2Bcheesy

11th February 2003, 10:30

I should take a look at the "SmoothDeinterlacer" and see how it works, but I'm very suspicious about any method involving deinterlacing, because by its very definition, deinterlacing involves stripping out a great deal of the original detail on the movie and using interpolation to fill in the gaps.

I too am not keen on AVIsynth from a complexity standpoint - but hey, it's free, and therefore worth a look... cheers Xesdeeni, I'll take a closer look at that and let you know how I get on :)

The Premiere method by SomeJoe looks interesting in that it is attempting to create its own interlacing, but it's still deinterlacing the source and thus stripping out the detail, something ProCoder doesn't seem to do.

easy2Bcheesy

11th February 2003, 11:04

Originally posted by Swan
@Xesdeeni
But why is so often deinterlacing mentioned when it comes to PAL to NTSC conversion?
I do not want to deinterlace, just in a clever way, by interpolation or similar, add enough frames (and fields) from the original PAL video, so it gets to be converted to NTSC.

Deinterlacing is used because in converting PAL between NTSC, you are changing the frame rate and therefore completely mucking up the field order as you stretch (or contract) the available data in moving between 25fps<-->29.97fps and resizing between 720x480 (NTSC) and 720x576 (PAL).

If you want to see why deinterlacing is often used, set up a PAL project in Premiere, import an NTSC clip and set it to render. Enjoy the results!! ;) Then deinterlace the same clip and import it again and you'll see an instant improvement at the loss of detail...

easy2Bcheesy

11th February 2003, 11:42

Well it's official, I'm useless at AVI Synth! I'm trying to convert across a NTSC DV file in the Matrox DV codec into another AVI file, using the script in VirtualDub - all I get is this error in line 151 : "ConvertFPS: requires YUY2 input"

Hmmmm, I've tried re-exporting the same file as either a Huffyuv or uncompressed AVI and get exactly the same error.

Does the script not work in VirtualDub? Is there a problem copying and pasting the text using Notepad? Is there a download pack so I get all the files just right without worrying about copying and pasting adding carriage returns that could muck up everything? :confused:

Any chance of a GUI? ;)

Xesdeeni

11th February 2003, 18:10

@Swan
I did seee your script and gave it a shot a month ago (or more). Yes, it was too complicated for me.
...
My source material will be PAL DV (avi) video and I want to make NTSC SVCDs.
Try this:# PAL (50 fps) to NTSC (59.94 fps)
LoadPlugin("SmoothDeinterlacer.dll")
AVISource("PALDV.avi")
SmoothDeinterlace(doublerate=true)
LanczosResize(720,480)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4,0,3) # or SelectEvery(4,1,2)
Weave()
#ConvertToRGB() if you are using TMPGEncI may have missed it, but don't see anything about color conversion in your script, doesn't one need to do some conversion in that area too? Or is that irrelevant in the Mpeg-world? It's just 4:2:0?All of the codecs can provide and will accept YUV in 4:2:2 (some will also deal with 4:2:0 that can be used by AVISynth 2.5.0). The encoders also accept this format and internally convert to 4:2:0 as used by MPEG (this conversion is not needed if the format is already in 4:2:0, which is why AVISynth 2.5.0 is so cool).@easy2Bcheesy
I should take a look at the "SmoothDeinterlacer" and see how it works, but I'm very suspicious about any method involving deinterlacing, because by its very definition, deinterlacing involves stripping out a great deal of the original detail on the movie and using interpolation to fill in the gaps.Actually that's not quite true. Deinterlacing doesn't by definition remove information. You have to differentiate between deinterlacing to the same frame rate and deinterlacing to double the original frame rate.

In the former case, you are right. Some temporal information will be lost. But in the latter case, for almost all deinterlacers (even dumb Bob), you can reclaim the entire original video by selecting one field from each frame (you'll usually need to ensure you are in sync with the original pattern).

It is this second method that is used for most simple standards conversion.VirtualDub - all I get is this error in line 151 : "ConvertFPS: requires YUY2 input"The Matrox DV codec outputs only RGB? Weird. You can fix this by adding ConvertToYUY2() before the ConvertFPS(). Or you can use the MainConcept DV codec instead (free for decode).Any chance of a GUI?Although I'm absolutely certain I'll never get there, from the beginning I was aiming at a GUI. But if it ever happens, it will be quite a while. In the mean time, the Standards Conversion page (http://www.geocities.com/xesdeeni2001/StandardsConversion/index.html) is the most user friendly ;-)

Xesdeeni

easy2Bcheesy

11th February 2003, 18:24

Still having problems, but then I've never used AVI synth before today! I put ConvertToYUY2() in, but now I'm getting a "Invalid Arguments to functino ConvertToYUY2" error at line 147.

Obviously I've got the syntax wrong or put the command in the wrong place... can you correct this? I suspect that there's a lot of other stuff I need to alter (input fps, resize pixels etc), but I really don't know what.

And the user-friendly website doesn't seem to cover NTSC interlace to PAL interlace :( Any chance of some ready-made scripts to download just for the conversion process? I think a lot of us would be interested in NTSC to PAL scripts without the need to strip footage from MPEG2 and re-encode.

LoadPlugin(PluginPath + "SmoothDeinterlacer.dll")

vpro = Input.SmoothDeinterlace(tff=InputTopFieldFirst, \
doublerate=true)
vinfps = Input.framerate < OutputFrameRate ? \
vpro.BilinearResize(OutputWidth, OutputHeight) : \
vpro
ConvertToYUY2()
vfps = ConversionType == 2 ? \
vinfps.ConvertFPS(OutputFrameRate * 2, zone = 80) : \
ConversionType == 1 ? \
vinfps.ConvertFPS(OutputFrameRate * 2) : \
vinfps.ChangeFPS(OutputFrameRate * 2)
voutfps = OutputFrameRate <= Input.framerate ? \
vfps.BilinearResize(OutputWidth, OutputHeight) : \
vfps
vfields = voutfps.SeparateFields()
vlace = OutputTopFieldFirst ? \
vfields.SelectEvery(4, 1, 2) : \
vfields.SelectEvery(4, 0, 3)

Xesdeeni

11th February 2003, 20:07

I didn't realize you were using the big honkin' script instead of the smaller one above. In that case, the best place to add the ConvertToYUY2() to is at the end of the "Input=..." line after a dot (.). E.g.:

Input = AVISource("PALDV.avi").ConvertToYUY2()And the user-friendly website doesn't seem to cover NTSC interlace to PAL interlaceYes, I'm sorry I haven't gotten that one up yet. I've been working long distance with someone in a PAL country to help me work this out (I don't have any PAL equipment to view the results on, so I need to rely on others to help me be sure the process works correctly). I think I've got it worked out, but I haven't gotten the step-by-step up on the web site yet. Hopefully within a few days.Any chance of some ready-made scripts to download just for the conversion process? I think a lot of us would be interested in NTSC to PAL scripts without the need to strip footage from MPEG2 and re-encode.I'm not sure what you mean exactly. The step-by-step will include the scripts as the current conversions on the page do. But I don't know what you mean by "...strip footage from MPEG2 and re-encode." If your source is MPEG2 (you said yours was DV, so I was sticking with that), then you can use either DirectShowSource() (assuming you have an appropriate MPEG2 codec installed) or a combination of DVD2AVI + MPEG2DEC.dll + MPEG2Source() to supply the input to the AVISynth script. But there's no way to make the conversion without completely decoding the MPEG stream, scaling it (both spatially and temporally) and then re-encoding it.

Xesdeeni

easy2Bcheesy

12th February 2003, 15:07

ahhhh yes, the smaller script is far easier to get to grips with and I've had limited success converting NTSC interlaced to PAL interlaced using AVI Snyth and Virtual Dub. Here's my script:

# NTSC (29.97fps) to PAL (25fps)
LoadPlugin("SmoothDeinterlacer.dll")
AVISource("NTSC-Source.avi")
SmoothDeinterlace(doublerate=true)
LanczosResize(720,576)
ChangeFPS(50)
SeparateFields()
SelectEvery(4,1,2)
Weave()
#ConvertToRGB()

First of all, let me say that this is a brilliant script, it really does disprove what I was saying earlier about the horrors of deinterlacing! All the detail appears to be there.

BUT I get some pretty bad "tearing" effects when any kind of medium to fast movement takes place on screen. I hope you don't mind, but I've emailed you a sequence of three shots to your Xesdeeni2001@yahoo.com address so you can see this effect yourself.

Perhaps the script above (particularly the "SelectEvery" line) is still set for PAL to NTSC conversion rather than vice versa? Or maybe some tweaks need to be made to the settings in SmoothDeinterlace?

Any help much appreciated - when I see footage running without the fast movement, I can see that the quality level really is quite exceptional! But when anything moves, it's bad news :(

Xesdeeni

12th February 2003, 21:18

I don't see the problem you describe. In this case, without the source video, I'm not quite sure what the output should look like. The only thing I can think of that you are seeing is the interlacing on your PC in the destination that, due to the type of video you are using as a source, may not be apparent on the source. The output will have interlacing artifacts when viewed on the PC. This will look correct on TV. Is this what you are seeing?

Xesdeeni

easy2Bcheesy

12th February 2003, 21:29

Well, I'm viewing the output on a TV and it's definitely visible! If you put an NTSC interlaced clip on an Adobe Premiere timeline and render it you'll see a massively exaggerated version of the "tearing" I'm seeing when movement takes place, or if you have a sudden change of colour (like a white-out) etc.

Does the script look OK to you?

If you have a broadband account, maybe I could mail you a 5MB m2v or or something... which would show the tearing in motion... send me a PM if that's possible.

Xesdeeni

12th February 2003, 22:14

The script looks fine to me. The only other thing may be that you have your fields reversed (in time, not in space). Static shots will look OK because the lines stack up right, but with motion, the fields will be coming in the wrong order. Try replacing SelectEvery(4,1,2) with SelectEvery(4,0,3). Normally DVDs want the former and DV wants the latter.

If that doesn't work, send a link to the source and destination clips to my e-mail and I'll check it out.

Xesdeeni

easy2Bcheesy

13th February 2003, 14:13

I get similar distortion patterns just putting the bare Matrox AVI into ProCoder. So maybe it's a codec problem. I get around it in ProCoder by converting to an uncompressed AVI, or use the Huffyuv codec. Then the problem vanishes.

But no matter what conversion I do, the script still gives the same tearing distortion effect.

I've made three short six-second M2Vs (between 1.6MB and 2.4MB each). The NTSC original, a near-perfect ProCoder PAL translation and one with distortion using the script. I'll email you links when I upload them later when I get home...

I tried your suggestions in your last reply but that just introduced real bad field issues.

easy2Bcheesy

13th February 2003, 21:10

@xesdeeni - email despatched to your Yahoo account...

Xesdeeni

13th February 2003, 22:28

OK, after much trying, I think I might be seeing what you are talking about. I had to lighten the image and then I see some horizontal banding. I think this may be the same problem someone else reported. Try adding SeparateFields() and Weave() after you load the video and before you call SmoothDeinterlace().

Xesdeeni

easy2Bcheesy

14th February 2003, 12:10

Surprised you can't see the effect. It's really blatant! I've emailed some new shots to you that really do show off the problem.

Alas adding the SeparateFields() and Weave() made no difference.

Xesdeeni

14th February 2003, 14:49

Alas adding the SeparateFields() and Weave() made no difference.Bummer.

What did you see with just the SmoothDeinterlacer? Using the NTSC source you sent, I see one deinterlaced frame that has some interlace artifacts. That is deinterlaced frame 113:

NTSC-Deinterlaced-113.JPG

Taking this frame and scaling it will do screwy things to these artifacts, introducing a 5 or 6 line alias pattern that I hope is what you are seeing.

The problem appears to be the fog, which is confusing the deinterlacer. Try playing with the staticthresh setting. 0 will disable this completely, and the problem appears to go completely away (although for some reason it's now on frame 111 ???). But this might introduce problems elsewhere in the video, so you'll have to experiment.

Let me know if we've hit this one yet!

Xesdeeni

easy2Bcheesy

14th February 2003, 21:32

OK, the script is now working 100% thanks to a bit of behind-the-scenes email action between myself and Xesdeeni and some basic experimentation with the SmoothDeinterlacer...

And I have to say that Xesdeeni is a genius - when properly tweaked, the quality of this conversion runs rings around Canopus ProCoder, and is probably the best standards conversion I've seen outside of a professional broadcast studio. And even then, you'd be hard pressed to tell the difference visually.

The final AVI Synth script I used for NTSC to PAL is...

# NTSC (29.97fps) to PAL (25fps)
LoadPlugin("SmoothDeinterlacer.dll")
AVISource("NTSC-Source.avi") # Change to your filename
SeparateFields()
Weave()
SmoothDeinterlace(doublerate=true,lacethresh=1,staticthresh=20)
LanczosResize(720,576)
ChangeFPS(50)
SeparateFields()
SelectEvery(4,1,2) # Change to SelectEvery(4,0,3) if output video looks very jerky
Weave()
ConvertToRGB() # Might not be essential

Stunning NTSC-PAL conversion using VirtualDub!! Seriously guys, the quality has to be seen to be believed.

Xesdeeni

14th February 2003, 21:50

Thanks for sticking with it through the process! I ported the SmoothDeinterlacer, but I can't say I'm an expert on how it does its magic :). The tweaks we discussed ended up being related to the lacethresh and staticthresh values, so if you see what Easy described, take a look at those parameters.

Some more info:

The SeparateFields() and Weave() above seem to be necessary for more and more video. I have no idea what is going on here yet, especially since those two functions should theoretically (at least as far as I understand things) reverse one another and the results should be the same as before the two calls. But without them, SOME videos don't deinterlace properly. So far these only seem to be MPEG via DirectShowSource() or DVD2AVI.

At least one other source required a ComplementParity() after it was loaded, so watch out for that one.

The ConvertToRGB() above is there to work around the faulty YUV to RGB converter built into Windows. I'm pretty sure TMPGEnc uses it, although other codecs may not. The color will look like only a few bits are being used, so there will be "blotchiness." If you don't need this line, it'll just slow things down. But if you see that symptom, just add it to the bottom of the script.

Xesdeeni

auenf

17th February 2003, 11:33

Originally posted by easy2Bcheesy
The final AVI Synth script I used for NTSC to PAL is...

# NTSC (29.97fps) to PAL (25fps)
LoadPlugin("SmoothDeinterlacer.dll")
AVISource("NTSC-Source.avi") # Change to your filename
SeparateFields()
Weave()
SmoothDeinterlace(doublerate=true,lacethresh=1,staticthresh=20)
LanczosResize(720,576)
ChangeFPS(50)
SeparateFields()
SelectEvery(4,1,2) # Change to SelectEvery(4,0,3) if output video looks very jerky
Weave()
ConvertToRGB() # Might not be essential

Stunning NTSC-PAL conversion using VirtualDub!! Seriously guys, the quality has to be seen to be believed.

ill have to save that for later, and if i remember, ill post the avisynth script ive been playing with at work.

Enf...

auenf

20th February 2003, 13:56

well, i took a look at my script and threw it away, and am currently testing this new script (after working out that Nic's MPEGDecoder.dll doesnt work too well, meaning the first half of the clip is the whole clip at 2x speed, and the 2nd half is black).

so far it looks pretty good.

btw, where did this script originate from initially?

Enf...

easy2Bcheesy

20th February 2003, 14:28

I believe it's Xesdeeni's work, being that he wrote the SmoothDeinterlace plug-in for AviSynth. I've run about an hour's worth of footage through it so far, and I still can't see any appreciable difference between this script and the Alchemist PH.C, it's *that* good. It's certainly a massive step up from Canopus ProCoder.

I think this particular script might well need tweaking for other sources, but so far it's not let me down once.

Xesdeeni

20th February 2003, 14:36

You mean initially, initially? :) (OK, now you're going to see the man behind the curtain.) It started with the AVISynth documentation for ConvertFPS():AVISource("NTSC_clip.avi") # Get clip
Bob() # Separate fields and interpolate them to full height.
BicubicResize(768,576) # Resize to PAL square-pixel frame size. (Use 720,576 for CCIR.)
ConvertFPS(50) # Convert field rate to PAL, using Blend Mode.
SeparateFields.SelectEvery(4,0,3) # Undo Bob, even field first. Use SelectEvery(4,1,2) for odd field first.
Weave # Finish undoing Bob.Since Bob() isn't exactly the best deinterlacer, it occurred to me that a smart deinterlacer would improve the quality.

Having more familiarity with VirtualDub at the time (including playing with the SDK), and having read that VirtualDub filters could be used with AVISynth, I tried Donald Graft's Smart Bob (http://shelob.mordor.net/dgraft/bob.html), Gunnar Thalin's Area-Based Deinterlacer (http://home.bip.net/gunnart/video/#deinterlacearea), and some others. However, there was a problem. In VirtualDub, filters can't change the frame rate of the stream, so these filters take (for example) 30 Fps in and output 30 Fps. Bob(), on the other hand, creates 60 Fps from a 30 Fps input. So I spent a lot of time and effort figuring out how to use AVISynth and force these filters (I preferred Gunnar's) to give me a progressive output at double the frame rate. That was a very complicated script (http://www.dvdrhelp.com/forum/viewtopic.php?t=84215#243979) and took a while to convert, but the output was great.

So, to simplify the script, I figured I'd need to modify the deinterlacer to give me double the input frame rate. Thanks to open source, I grabbed the AVISynth SDK and Gunnar's source and ported the deinterlacer. After I was nearly finished, I contacted Gunnar about hosting the port on his page, since all I had really done was take his work and re-wrap it for AVISynth. At that time he let me know that he wasn't messing with the Area-Based Deinterlacer any longer and instead referred me to his new Smooth Deinterlacer (http://home.bip.net/gunnart/video/). So I grabbed that source and ported it to AVISynth instead.

Anyway, once the port of Smooth Deinterlacer (http://home.bip.net/gunnart/video/AVSPorts/SmoothDeinterlacer/) was done, I posted a newer, simpler conversion script (http://www.dvdrhelp.com/forum/viewtopic.php?t=118120). Eventually I modified the AVISynth port of Smooth Deinterlace's page to include some more specific and simplified versions (see bottom of homepage) of the all-in-one script.

Somewhere along the line I learned of LanczosResize() and changed to that scaler. And a problem I encountered with TMPGEnc that exposed a faulty Microsoft YUV->RGB conversion DLL caused me to add the optional ConvertToRGB().

Recently, some people have been having problems with the Smooth Deinterlacer plugin. I worked really hard to allow it to handle either fields or frames as input, and to allow it to provide output at the original or double the original framerate. But somehow a problem I haven't had the time to track down has been exposed. I found that adding the SeparateFields() and Weave() calls before calling SmoothDeinterlace() fixes the problems, although what this actually changes, I don't know yet.

Whew! That should be more than you ever wanted to know about that script.

Xesdeeni

auenf

21st February 2003, 13:34

interesting history.

one thing ive come accross:

using AVI source is fine, when im using a m2v source (using Nic's MPEGDecoder.dll) if i dont put in AssumeFieldBased before the smoothdeinterlace line (ive discarded the separatefields/weave lines), then the footage plays back at 2x for the first half of the clip, and the 2nd half is black ;)

Enf...

Xesdeeni

21st February 2003, 14:59

That's not quite the same issue I'm seeing that caused the addition of the SeparateFields() and Weave() commands. The issue is that the first few frames are deinterlaced properly, but after that it looks about like Weave(). The first thing I tried was AssumeFrameBased() and AssumeFieldBased(), but that didn't seem to help. The above pair were kind of a last-ditch try that seems to work. But I have no idea how this pair, that seem to reverse one another and should thus output the same thing they started with, fixes the problem. I'll get time to investigate soon, but this is a good stopgap.

Xesdeeni

easy2Bcheesy

22nd February 2003, 00:39

You have to admit though, once you've got it all tweaked to your individual project settings, the results speak for themselves - I've passed on the results to three video editors all of whom have pulled work from production houses who usually carry out their standards conversion work. High recommendation indeed!

aguilar

14th March 2003, 20:35

hi
maybe this is out of context but i am trying to convert a PAL dvd to ntsc before use procoder i need to convert the vob´s to avi or mpeg .
which is the best way? do i loose quality?
regards

SurfDrifter

19th March 2003, 00:45

The last script posted in this post, is capable to convert from PAL to NTSC?

Thanks!

Scarabus

19th March 2003, 01:41

I'm guessing that for PAL to NTSC you'd just have to change 576 (the line count) to 480 and 50 (the frame rate) to 60 (or possibly 59.94?)
I plan to try this tonight.

Xesdeeni

19th March 2003, 14:28

Take a look at the Standards Conversion Page (http://www.geocities.com/xesdeeni2001/StandardsConversion/index.html) or the AVISynth Smooth Deinterlacer Port Page (http://home.bip.net/gunnart/video/AVSPorts/SmoothDeinterlacer/) and see if that gives you what you want.

Xesdeeni

SurfDrifter

19th March 2003, 19:07

Well, here's the story...
I work in a company for a few weeks that started in DVD authoring...
So, there was a film(PAL) that they asked me if a could make it NTSC
We have a Snell (9600 I think) convertor there, but it's very old and the PAL>NTSC conversion sucks...
So they gave me the PAL DVD...
I used the first complicated script and yielded very good quality(clear picture), due to a "random" reason...The whole film was mostly static, without any paning of the camera...It had very few ones, so a very slight "jerky" picture on some few shots that the camera was paning was acceptable by our customer...
Oh, by the way, i didn't thank you about the script!!
Really thanks!
So, i continue...Now they gave us 2 documentaries about Greece and its landscapes, where ALL the shots are with the camera paning...
So, i tried Canopus Procoder v.1.0.35 and the motion is very smooth, yet, the picture becomes unacceptably blurred...
So, i tried v.1.25 DEMO which is far more superior than the previous version of Procoder. Yet the picture isn't as sharp as your script with CCE encoding...

So here is the question. In about 3 days, we are going to make a deal with the local Procoder seller, but i was wondering weather your script can perform better than Procoder v.1.25(and not 1.0.35)?
All my files would be MPEG-2 and not any other format.Also i want the quality to be good both on PC and TV monitors(since i create DVDs)

I tried all the previous scripts you've mentioned and played with all possible combinations of field orders(and 4,1,2/4,0,3) between DVD2AVI,AVIsynth script and CCE, but it didn't show good in my PC monitor...
Should i better use TMPGEnc for final encoding?

Also, i noticed that since the image is getting blurred a little (not much) sharpen filter during the capturing helps after with the conversion...

Thanks again! You're really great!

EDIT: I just read in your page about setting the ttf flag!!!
I didn't set that at all, since i copy/pasted from a previous post...
I'll try now and let you know!!!

Xesdeeni

20th March 2003, 15:07

First, there are two field polarity issues that you need to make sure you have correct. One is the input field polarity. Use a script like:LoadPlugin("MPEG2DEC.dll")
LoadPlugin("SmoothDeinterlacer.dll")
MPEG2Source("DRIVE:\PATH\VTS_xx_x.d2v")
SmoothDeinterlace(doublerate=true)and load it into VirtualDub. Step through the frames and be sure that the motion is smooth and doesn't jump back and forth.

Then you have to be sure the output polarity is correct. The only way to do this is to encode some video through the entire script and test it on an actual video monitor or TV. You don't have to encode the whole video, just some motion.

But the bigger issue is that some panning and scrolling will never look good with any conversion program that doesn't use motion estimation/compensation. There will be some stutter if you use a frame replication/decimation technique like ChangeFPS(), or jutter if you use a frame interpolation technique like ConvertFPS().

In some cases, if the pan was done by hand, the stutter of the framerate conversion may not be any worse than the natural speed changes of a cameraman and may not be objectionable. (One of the shots in Jurassic Park was of some dinosaurs drinking at a beautiful lake. The lake in Hawaii was scouted by Steven Spielberg, but before they could actually film the scene, a hurricane wiped it out. He used a high resolution picture of the lake before the hurricane and a computer to create the scene instead. The "camera" pans across the completely virtual scene. But Speilberg added an intentional "bump" to simulate a human cameraman!)

That being said, if you have the time (and inclination), there may be a way to work around this and make the results as smooth as the original. The trick is to NOT convert the frame rate of the panning. All of this depends on the contents of the pan. If the sound is not strictly synchronized to the pan, and depending on what types of action may be going on in the video (some things are obvious when their speed is changed, like something falling or someone running), you can just slow down or speed up the pan. AVISynth provides enough editing features so that you can create a custom script to treat different sections of the video differently. Once you have it written, you then just feed it to your encoder (and go to sleep :) ).

Going from NTSC to PAL is a bit easier than the other direction. You just choose the most appropriate 83% of the pan shot by using the Trim() function in AVISynth and cause that section to only be scaled, but not framerate converted. It needs to be 83% (50/59.94) of the original so that it plugs into the destination video, which IS framerate converted.

PAL to NTSC is a bit trickier. Obviously, you can't use 120% (60/50) of the pan. I'm not really sure what would be satisfactory. You could slow the video to 47.952 fps and throw out every other frame. This would give you 23.976 fps that you could telecine using 3:2 pulldown. NTSC viewers are used to the view of this technique. But without the exposure time of actual film, which would cause more blurring, the strobe effect of the lower frame rate may be too distracting. I'm not sure what to tell you here.

I guess if the pan is over a completely static image, pretty far from the camera (or a photo) you could grab frames from opposite ends of the pan and stitch them together into a bitmap. Someone a few days ago posted a plugin that will allow you to pan across the bitmap, so you'd be able to adjust the speed to match the original pan.

Wait a minute, is the PAL DVD from film (25fps) or video (50i fps)? All the above applies to video. If the PAL DVD is from film, you can just use 96% (23.976/25) of the pan, slow the section to 23.976 fps and use 3:2 pulldown.

Any of these techniques would obviously take a while to work out. But if you are doing this professionally, it may be worth half a day of work to get the quality you desire. The results will certainly be much better than any devices except the most expensive conversion devices can supply.

Xesdeeni

SurfDrifter

22nd March 2003, 12:04

Thanks for all the wonderful information here...

Yet, I'm almost a newbie, in video editing.
All I was ever using from Avisynth was the transcoding of DVD9 to DVD5 for hobby. So i never got actually into video editing.
So, i was hired as a DVD authorist...

I totally agree about spending half or a full day to get results, yet i don't have the luxury (or maybe the mood, because i know that my boss wants to reduce costs here, but i believe that it would be better for the overall workflow, to buy the 25,000$ Snell Convertor) of experimenting.
During a DVD creation, I either capture directly from a Digital betacam to .m2v and .ac3 streams (using Sonic's SD-1000 Encoder) or "ripping" a DVD and re-author from scratch with new menus...
So, i actually don't know if this material is called film or video. Can you help me here pls? . All i did to feed CCE was DVD2AVI>AVISynth channel, using your script.
Then i tried Canopus Procoder and i had the results i mentioned before in my earlier post.
Now the Standards conversion has become a interesting quest for me!
Not for pleasing my boss (since i'm going to be paid the same, no matter if spend hours on a film testing AVIsynth usage or just feed Procoder and go home and spend time with my friends), but for having the feeling of enjoyment that i did it(ACTUALLY YOU DID IT!)

1)So, as for upper/lower field i already know how to solve the problem. It's only a problem in 4:3(not in 16:9) PAL material in TV monitor.
2)Please tell me what's the difference between video(50i) and film(25fps) or at least point me a link to study
3)If the abovementioned term "film" applies i admit i didn't understand the procedure. Pls point me to sth i can study to
4)And something last. I am not authoring corporate/artistic DVDs. Just movies that go to Video club for rental or sale. So you get the idea about the material i'm using!

Really, really thanks

Xesdeeni

23rd March 2003, 00:40

I totally agree about spending half or a full day to get results, yet i don't have the luxury (or maybe the mood, because i know that my boss wants to reduce costs here, but i believe that it would be better for the overall workflow, to buy the 25,000$ Snell Convertor) of experimenting.I can't blame you for using the "automatic" route :)

During a DVD creation, I either capture directly from a Digital betacam to .m2v and .ac3 streams (using Sonic's SD-1000 Encoder) or "ripping" a DVD and re-author from scratch with new menus...
So, i actually don't know if this material is called film or video. Can you help me here pls?DVD2AVI can provide analysis for you, but I prefer to have a look myself. I would create a DVD2AVI project file for either the VOB or M2V. Be sure to check "None" under "Field Operation." Then create the following AVISynth script and load it into VirtualDub (www.virtualdub.org):LoadPlugin("MPEG2DEC.dll")
MPEG2Source("YourVideo.d2v")Now I would look for a region in the video that has movement and step through the video. This is PAL video, so I'm not looking for quite the same thing as I would for NTSC.

If none of the frames have interlacing artifacts, then the source is film.

If the frames have interlacing, the source might still be film, but with the field pairing in the wrong sequence. To check this, I'd modify the above script to addSeparateFields()
Trim(1,0)
Weave()Then I'd look in VirtualDub again. If the frames now don't show any interlacing, then the source is film.

If the frames still have interlacing, then the original source is video.

1)So, as for upper/lower field i already know how to solve the problem. It's only a problem in 4:3(not in 16:9) PAL material in TV monitor.That doesn't make sense. The aspect ratio shouldn't have any effect on the field polarity. It is possible that you've only seen 16:9 content that is from film, so the field polarity didn't matter. But there can definitely be 16:9 content that is interlaced, even moreso from PAL countries that are already using 16:9 televisions for their everyday broadcasts.2)Please tell me what's the difference between video(50i) and film(25fps) or at least point me a link to studyAnalog television is always interlaced. That means that 50/60 fields are shown per second. But that doesn't necessarily mean that each field comes from a completely different "instant of time."

You've seen shots of a still photograph on TV. The TV is still showing 50/60 fields per second, but the image isn't changing. Every field comes from the same "instant of time," the instant that still iamge was taken. So you could use an odd and an even field together to reconstruct a nice 576/480-line picture.

But you've also seen a sporting event live on TV. These are almost always shot in native video, so each field is actually from a different "instant of time," and they are a 50/60th of a second apart. Now if you wanted to grab a picture, you'll have a problem. Any even and odd fields you choose show the scene at two different "instants of time." And the objects in the image will have moved between the two fields. When you combine fields like this, you see the "combing" or "feathering" interlaced artifacts.

If the source of a video is film, it is very much like the above still photograph example. Except in this case, the "instant of time" shown is not the same for a very long time. But it is the same image for several fields. For PAL it is the same for 2 fields (the 24 fps film is actually sped up by 4% to 25 fps and each frame is shown for two fields). And as above, by choosing the right two even and odd fields (they must be successive in this case), you could reconstruct a 576-line image (for NTSC, it is the same for 2 or 3 fields and you could reconstruct a 480-line image). This is the 25 Fps case.

But as the sports example illustrates, if the source is video, then each field stands alone. If you want a still image from the video, you'll have to take only one field and that will give you only 288 (240 for NTSC) lines. You could interpolate it up to 576 (480), but it won't be as clear as the still image above. This is the 50i fps case.

BEWARE: There are times when a program is a hybrid of video and film. In this case, I recommend just doing a video (50i -> 60i) conversion. And if there is any doubt, a video conversion should always work.

I hope this helps clear things up.4)And something last. I am not authoring corporate/artistic DVDs. Just movies that go to Video club for rental or sale. So you get the idea about the material i'm using!Then these are almost definitely from film.

Xesdeeni

jbalakri

31st March 2003, 22:20

I am afraid I was not very happy with results of the smoothdeinterlaced () version this NTSC to PAL conversion script because, the resultant video was jerky. It did not matter if I used SelectEvery(4,1,2) or SelectEvery(4,0,3). It was equally jerky.

I found the original AVISynth documentation version with bob() to give a better result as far as jerkyness is concerned.

- Jay

Xesdeeni

1st April 2003, 14:36

If you are seeing more "jerkiness" with the SmoothDeinterlacer() version, then you have some problem with your field polarity. I should never be worse than the Bob() implementation.

To ensure the input polarity is correct, try putting just the following into a script:LoadPlugin("SmoothDeinterlacer.dll")
xxxSource("Input.xxx")
SeparateFields()
Weave()
SmoothDeinterlace(doublerate=true)Look at the result in VirtualDub and step through the frames. If the video moves back and forth when it should be just moving one direction (call it the "Cha Cha Cha" effect ;) ), then the automatic detection of the field dominance is failing (maybe due to the source file, maybe due to a screwup in SmoothDeinterlacer :) ). Add either ComplementParity() before the SmoothDeinterlace() line, or try "tff=false" and "tff=true" until you get the correct motion.

Then add the remainder of the conversion script and test on a small piece of the video using both SelectEvery(4, 0, 3) and SelectEvery(4, 1, 2) to get the output polarity correct.

If you have any more problems, let me know, and I'll work with you to get this right. The results are MUCH better than Bob() (http://forum.doom9.org/showthread.php?s=&threadid=47870#post275032).

Xesdeeni

jbalakri

1st April 2003, 23:58

Xesdeeni,

I think it is not the field polarity problem. I tried your script you mentioned and the video did not apprear to move back and forth as you said it might happen if field polarity was the problem. Out of curiosity, I introduced ComplementParity() and now, it did move back and forth. So parity was good to begin with.

Here is the script I am using:

LoadPlugin("SmoothDeinterlacer.dll")
AVISource("D:\input.avi")
SeparateFields()
Weave()
SmoothDeinterlace(doublerate=true,lacethresh=1,staticthresh=20)
LanczosResize(720,576)
ChangeFPS(50)
SeparateFields()
SelectEvery(4,0,3)
Weave()

The jerkeyness is not pronounced, but quite apparent only in sections where there is a fast moving object, for example a train moving across the screen. But I must admit, the result is better than bob() version of the script, but for this jerkeyness.

The source is NTSC DV avi file and I am trying to encode it in CCE and author a PAL DVD using DVDit PE.

Let me know if i am doing anything wrong. Thanks for helping.

Thanks,
- Jay

Xesdeeni

2nd April 2003, 14:41

Try using ConvertFPS() instead of ChangeFPS(). But in either case, there will be an artifact usually called "jutter" when the scene pans. ChangeFPS() will give you what you call a "jerk," while ConvertFPS() will give you more of a "strobing" effect. This is unavoidable when using the techniques we can accomplish on a PC today. To avoid this problem, you would need an expensive conversion device capable of doing motion estimation/compensation. But the above technique is very similar in quality and side-effects to the less expensive "four-field" standards converters...at a MUCH cheaper price. [There also may be some things you can do by hand to fix this if you want to go to the trouble, but you really have to want professional quality to take the time.]

Also, I'm curious why you needed to adjust the thresholds so radically. There have been a few videos that needed some tweaking (one particularly with lots of fog), but the defaults I borrowed from Gunnar's original VirtualDub version appeared to be very good in most cases.

Xesdeeni

easy2Bcheesy

2nd April 2003, 18:51

The only way you can avoid the "jerkiness" you are talking about is to put your file onto digital tape and take it to a production house - ask for them to run the footage through an Alchemist PH.C. This uses motion vectors to replot every single pixel, and is the industry standard for standards conversion. An Alchemist will cost you over £80,000 so you basically hire time from someone who has one!

I've spent three years in DVD production now and Xesdeeni's script is a revelation. The jerkiness you talk about is only visible on sustained pans and won't be noticed by 95% of your audience. There are some exceptions where it's really not useable - for example, I captured some racing footage. Here all the cameras pan from left to right and the results of the conversion are not impressive at all. But for all other applications, I've found that it sustains quality and sync in brilliant fashion. You couldn't do this on Adobe After Effects or any other industry level tool. Canopus Procoder - a decent enough second place, but still not a patch on this (you'll get jerking on that too).

In terms of the parameters for the deinterlacer - those are mine from my tweaked version of the script earlier in the thread! I've tinkered a little more, but I still can't find better. But I should stress that those settings are optimised for the style of footage I use - you'll most likely get better results by tinkering with them on your own clips.

jbalakri

3rd April 2003, 21:14

Using ConvertFPS() does help a lot in improving the jutter or jerkeyness because that "strobing" effect as you put it, makes it better to watch. Now the jutter is the same as the original bob() version, but overall quality and sharpness is much better than bob() version. I am quite happy with it now. Thanks for your help.

Yes, I used easy2Bcheesy's parameters for the SmoothDeinterlace initially. Now I removed both the parameter's and am going with the default parameters.

Thanks,
- Jay

redeemer-dk

7th April 2003, 20:50

Dunno if this has been tried before, but i just tried this NTSC to PAL script and it works pretty good.

It will create interlaced contents, but standalone dvd players will be able to display that fine right?

LoadPlugin("D:\Program Files\GordianKnot\MPEG2Dec.dll")
MPEG2Source("H:\8MILE\8mile.d2v")
ChangeFPS(50)
SeparateFields()
LanczosResize(720,288)
SelectEvery(4,1,2)
Weave()

I'd like to get some comments to see if this is a good way or if it's bad with some movies.

Thanks :)

Xesdeeni

8th April 2003, 14:33

Yes, the output is interlaced. But, I would recommend that you scale the video before you change the frame rate and before you separate the fields:LoadPlugin("D:\Program Files\GordianKnot\MPEG2Dec.dll")
MPEG2Source("H:\8MILE\8mile.d2v")
LanczosResize(720,576)
ChangeFPS(50)
SeparateFields()
SelectEvery(4,1,2)
Weave()This will be faster (since you are only scaling 24 fps instead of 50) and give you a bit better image (because you are using the entire frame to scale, instead of every other line).

This technique will work for movies, but it won't be quite as smooth as the other technique used on my Standards Conversion Page (http://www.geocities.com/xesdeeni2001/StandardsConversion). OTOH, with that method, the movie will run slightly slower, and the audio will need to be processed. Since 8 Mile probably has a lot of music (I'm guessing because Eminem is in it...I haven't seen it), that probably wouldn't be acceptable with the usual methods. But give it a try using WSOLA and let us know what you think.

Xesdeeni