PAL to NTSC and NTSC to PAL

[easy2Bcheesy]

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]

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]

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]

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]

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]

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]

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]

@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]

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]

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]

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]

@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]

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]

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]

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]

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]

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]

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]

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]

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

[Xesdeeni]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

Thanks!

[Scarabus]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Adamb]

Very Interesting thread. I want to convert PAL DV to NTSC for DVD.
Xesdeeni, which of your scripts should I use? Is there a good guide to explain how to use the scripts? Will this work with CCE Basic for encoding?

Just a thought, as PAL is 25fps (i) and DVD film is 24fps (p), is there not an easy way to convert the 25fps interlaced to progressive and then just slow it down by 4% (or whatever)? Would such an output work on a NTSC DVD player??

[brw]

I don't see any technical reason why you would need to slow down 25 fps to 24 fps to go from PAL to NTSC since your target is 29.97 fps. I was a little surprised to find that pulldown.exe won't properly convert 25 fps to 29.97 fps so I'm attaching a program I wrote a little while ago which will insert the rff and tff flags necessary to bring an mpeg2 video stream to 29.97 fps, it will work on input that's 25, 24, or 23.976 fps. The usage is fairly simple, just type: m2ntsc source.m2v destination.m2v. It doesn't have all the options of pulldown.exe but it is faster if your source and destination are on the same drive (larger buffer results in less drive seeks than with pulldown.exe) so you may want to try it out even if you're working exclusively with NTSC. I haven't extensively tested it (I don't even use it anymore), but I have used it with 23.976 and 25 fps material and it has worked fine.

[Xesdeeni]

brw

I think you can play flag games with the DVD stream to get 25 fps to play at 29.97 fps, but I'm not sure all DVD players can deal with this correctly. My biggest question would be about progressive DVD players that use the flags to figure out how to deinterlace (or not to interlace). I would think that would seriously confuse them.

AdambI want to convert PAL DV to NTSC for DVD.
Xesdeeni, which of your scripts should I use? Is there a good guide to explain how to use the scripts?I'm afraid my Standards Conversion Page (http://www.geocities.com/xesdeeni2001/StandardsConversion) doesn't have this combination yet. Since I don't have a PAL DV and you do...do you want to volunteer to help? :)

Try this (you'll need the beta versions of BeSweet and BeSweetGUI):

1. Open BeSweetGUI.
2. Select "AC3" from the yellow pulldown in the right middle of the interface.
3. Click the "Input" folder icon to open the input dialog box.
4. Select the ".avi" entry in the pulldown in the upper right of the dialog, and then locate your input AVI. The full path should appear in the "VOB/AC3/LST" section at the bottom of the dialog.
5. Click the "WAV/MPx" button in the section at the bottom of the dialog, and then select the destination and name of the AC3 file at the top of the dialog.
6. Click "OK" at the bottom to close the dialog.
7. Click the "AC3 & OGG" button in the right middle of the interface.
8. Check the "Bitrate" box and choose your desired bitrate.
9. Click the "AVI to AC3" button in the lower right to convert the audio from the AVI file to an AC3 file.
10. Create and open a new text file with an AVS extension (to be used with AVISynth), using your favorite text editor (like Notepad).
11. Add the following lines, filling in the location and filename of the file you created above: LoadPlugin("SmoothDeinterlacer.dll")
DirectShowSource("DRIVE:\PATH\PAL.avi")
SeparateFields()
Weave()
SmoothDeinterlace(doublerate=true)
LanczosResize(720,480)
ChangeFPS(59.94) # or ConvertFPS(59.94)
SeparateFields()
SelectEvery(4,0,3)
Weave()
ConvertToRGB() 11. Save the AVS file.
12. Load the AVS file into TMPGEnc as the "Video Source."

NOTE: Cancel the Wizard dialog box which appears when you run TMPGEnc.

13. Load the "DVD (NTSC)" template into TMPGEnc.
14. Load the "unlock" template (located in the "Extra" directory).
15. Select "Video only" in the "Stream type" region.
16. Specify the location and name of the "Output file name" with an M2V extension.
17. In the "Rate control mode:" field, choose the type of encoding you want. Multi-pass variable bit rate (VBR) settings produce better quality, but take longer to encode. Choose your bit rate based on quality desired, length of video, size of AC3 above, size of other files that will be on the destinaion disc, and the size of destination medium. Do not exceed 9800 kbit/sec.
18. Choose "Motion estimate search (fast)" or "Highest quality (very slow)" in the "Motion search precision:" field on the "Video" tab of the "Setting" dialog.
19. Press "Start" to convert, and encode the video.Will this work with CCE Basic for encoding?Sure, just feed the AVISynth script to CCE instead of TMPGEnc.Just a thought, as PAL is 25fps (i) and DVD film is 24fps (p), is there not an easy way to convert the 25fps interlaced to progressive and then just slow it down by 4% (or whatever)? Would such an output work on a NTSC DVD player??Certainly, and you might think that the video would be a bit smoother. But remember that video is captured at 50 fields per second, while film is 24 frames per second. These two formats use different exposure times, so the 24 Fps frame will have more motion blur in each frame than a 50 fps capture, which makes the film seem just as smooth as the video. But when you convert from 50 fps to 25 Fps, you will be effectively throwing out half of the motion blurring. The remaining video will have a strobe effect. Then you are going to do a 3:2 pulldown on this after you've converted it to 23.976 Fps for NTSC, making the difference in duration between frames (3 vs 2 fields) much more apparent. I believe this will look worse and be more distracting than the jutter introduced by the conversion above. And the advantage of the above technique is that no processing of the audio is necessary.

But you'd need to try the conversion yourself and see what you think. I think this is similar to what my DVD player itself does when it does PAL to NTSC conversion internally (although instead of deinterlacing, it just throws away one field completely). You may find that you prefer this technique, and this hobby is nothing if it isn't about experimenting!

Xesdeeni

[shoarthing]

Xesdeeni - Hi - can't thank you enough for all the work you've put into this, & for the astonishing quality your technique & tools give for NTSC>PAL DVD conversion.

OK, it's slow at 2-pass VBR 5600ave; but crikey the quality is good - far better than Procoder [1.0.3.5 - haven't used the new one yet].

[philippoumartin]

I'm trying to convert Gladiator PAL into NTSC to have a french 5.1 version (I does not exist in Canada)

I've been able to change the format using neoDVD : it does an acceptable job while transferring the format. However, the new file is stereo.

I try to use VOBedit and IFOedit to extract the AC3 soundtrack and the remux it with the film but I get unsynchronized (about 1 sec per 20 minutes)

I used besweet with the AC3 to try to fix the problem but it does not seem to fit.

I decided to split each VOB of the original (PAL) and extract an AC3 file for each of them. Then I convert each vob of the film to NTSC. I extract the m2v's to rebuilt all the film using "reauthor" in IFOedit. That way, I should "readjust" the sound at the end of each VOB.

On the final product, I have sound on the first vob only...??? Can somebody help me

[ryangs]

I tried converting a progressive-scan PAL video into an interlaced, DVD-format NTSC video, and it didn't quite work. The source is originally 25i, from British TV, but it was deinterlaced when it was made into an OGM. Using the 25i->29.97i tutorial on your site, Xesdeeni, looks fine on the computer monitor, but when I try to play it on a TV I get a really terrible strobing flickering. It's hard to describe. When I look at it closer frame by frame I can see that it's going in and out of interlacing. That is, looking at constant motion, a few frames are interlaced, then a few are solid, then interlaced, etc. It kind of weaves back and forth between interlacing and no interlacing, and I believe this is what's causing the strobing. Is there a way I can modify your 25i->29.97i script to do 25p->29.97i?

Thanks for all the help you're providing with standards conversion!

[philippoumartin]

Ryangs,

if you only want to convert PAL to NTSC with stereo or mono soundtracks, NEODVD is a very cheap and do a good job for a non-professionnal use.

I was able to convert the video very well. My problem is that NEODVD downgrade the AC3 5.1 soudntrack in stereo and I want to keep it

[Xesdeeni]

ryangs
What you describe sounds like the output fields may be reversed. If shots that don't move look good, but moving stuff seems to "shimmy" back and forth, then that's probably the issue. If you are using SelectEvery(4, 0, 3), switch to SelectEvery(4, 1, 2) or vice versa and see what you get.

Xesdeeni

[scharfis_brain]

for 25p->29,97i, I would slowdown 25p to 23,976p and then telecine to 29,97i. (telecine not really nessesary, because the DVD player will telecine the 23,976p Video)
This would IMO give the best result.

[Xesdeeni]

More info on several methods of conversion on my Standards Conversion page (http://www.geocities.com/xesdeeni2001/StandardsConversion).

Xesdeeni

[ryangs]

Originally posted by Xesdeeni
ryangs
What you describe sounds like the output fields may be reversed. If shots that don't move look good, but moving stuff seems to "shimmy" back and forth, then that's probably the issue. If you are using SelectEvery(4, 0, 3), switch to SelectEvery(4, 1, 2) or vice versa and see what you get.

Xesdeeni

I was using (4,1,2). Switching to (4,0,3) doesn't seem to help much. I can't really tell because both look acceptable on a computer monitor; it's once you get them on a real TV they look terrible. I wish I could check more accurately without wasting a DVD-R.

Scenes with no motion look fine; it's only motion. With both (4,1,2) and (4,0,3) I see the same problem: a few frames seem to be interlaced, then a few seem to be progressive. Here's some examples.

http://mail.chartermi.net/~ryangs/frame1.jpg
http://mail.chartermi.net/~ryangs/frame2.jpg

This is taken from a scene with constant motion. The big colored blocks (actually letters) are moving at the same speed. The first screenshot shows a frame which appears progressive. The next shot, from two or three frames later, appears to be interlaced. Since it's constant motion, shouldn't they both be interlaced? I think it's the "going in and out of interlacing" thing that's causing the flickering/strobing, and changing the numbers in SelectEvery doesn't seem to affect it. Do you have any other ideas, Xesdeeni?

One thing I thought could be the cause was SmoothDeinterlacer. It shouldn't be necessary since I'm starting with a progressive source, right? I removed it from the script and it didn't seem to affect the output, aside from making encoding go a hell of a lot faster!

[Xesdeeni]

I was using (4,1,2). Switching to (4,0,3) doesn't seem to help much. I can't really tell because both look acceptable on a computer monitor; it's once you get them on a real TV they look terrible. I wish I could check more accurately without wasting a DVD-R.You could try a DVD-RW, but once you've established the correct output polarity, you shouldn't have to make any more changes unless you change your MPEG encoding program (or potentially your DVD authoring program). Unfortunately you'll only be able to judge the correct polarity on the actual interlaced device. Scenes with no motion look fine; it's only motion. With both (4,1,2) and (4,0,3) I see the same problem: a few frames seem to be interlaced, then a few seem to be progressive....The first screenshot shows a frame which appears progressive. The next shot, from two or three frames later, appears to be interlaced. Since it's constant motion, shouldn't they both be interlaced?The output will not always be interlaced. Remember that we can't genuinely generate 60 new fields from the original 25 frames. You will be duplicating data from each frame into either two or three fields. Depending on whether the pairs show up on your progressive PC or not, you may see a progressive frame or an interlaced one (telecined NTSC has exactly the same effect, but when converting 25 fps, the jutter pattern is irregular, so it's more noticable).One thing I thought could be the cause was SmoothDeinterlacer. It shouldn't be necessary since I'm starting with a progressive source, right?Well, I warned you that although the conversion would be easier, depending on your source and on your eye, you might not be satisfied. From the video you describe, I'm sure you'll need to instead reverse the telecine and slow the video frames. In PAL, reversing the telecine is normally just a matter of combining pairs of fields, but sometimes you have to tweak which pair (even then odd or odd then even). Then the best bet is to slow the video down to 23.976 Fps and scale it.

Of course, you then have the pain of converting the audio. Most conversions will shift the pitch of the audio down by 4%. This might not be too bad for your use, but it's the tradeoff for avoiding the video artifacts you saw. I've tried to make WSOLA available as a replacement. It does the slow down (or speed up for the reverse direction) without changing the pitch. However, I'm still not sure whether the quality is as good as the guy who posted the algorithm says. I'm still trying to get feedback. Also, my implementation has some problems:

1. DVD2AVI's WAV outputs don't appear to be legal. WSOLA checks this and refuses to deal with these WAVs. I posted a message last week about this, but no-one has addressed it. I suspect I'm going to have to make the modification to DVD2AVI myself, and I just won't have the time, at least for the next few weeks. In the mean time, I think just loading the audio into any other sound program and re-saving it should fix the headers.

2. WSOLA is a huge memory hog. I've tried to modify it a bit, but I haven't figured out exactly how the spaghetti code works inside, so I haven't been successful in eliminating the multiple allocations of huge memory. I already eliminated one level, but I didn't realize it was like peeling an onion. Breaking the audio into sub-chunks appears to be the only solution at presents....my apologies.

All of the above is why I suggested that you instead just convert to interlaced NTSC and leave the audio alone. Yes, you will have some jutter, which may or may not be better to your eyes using ConvertFPS() instead of ChangeFPS(), but the above issues seemed to be a bigger problem in the short term. But for the video you describe, you may need to deal with converting the audio. Try ConvertFPS() first on a test section, and if you don't like it, do the slow down and audio conversion. You are welcome to try WSOLA and give me feedback on the quality, but you can also use the conversion in BeSweet (you can also do the same with AVISynth), although you'll get the pitch shift.

Xesdeeni

[philippoumartin]

The link given by xesdeeni about the conversion is really good and worked perfectly for my conversion....

Great tool!!

Phil

[ronnie_t]

Amazing deinterlace script. This script has been the key for me to successfully transcode a NTSC-dvd to a PAL Mpeg2 stream.

I had to edit the script on several lines and had to downgrade to avisynth 2.08, but the endresult is amazingly good. I mainly followed this (http://www.geocities.com/xesdeeni2001/StandardsConversion/index.html) guide and I borrowed some lines from here (http://biphome.spray.se/gunnart/video/)

Background: I live in Europe (PAL) I bought an import dvd from the USA (NTSC) as a present to my father. Unfortunately his dvd-player doesn't support NTSC dvd's. After looking on the forum I quickly came to this de-interlace script and it helped me to feed TMPGenc a PAL non-interlaced AVI to encode. Now my father can enjoy his dvd afterall.

my script looks as follows:

LoadPlugin("SmoothDeinterlacer.dll")
AVISource("H:\New Folder\123_d2v_vfapi.avi").ConvertToYUY2()
SmoothDeinterlace(tff=true, doublerate=true)
LanczosResize(720,1152)
ConvertFPS(50)
SeparateFields()
SelectEvery(4, 1, 2)

[scharfis_brain]

You may want to try my automated NTSC -> PAL conversion function.

http://forum.doom9.org/showthread.php?s=&threadid=67161

It can convert your NTSC-Video with PAL-Speedup (progressive output)
or without PAL-SPeedup (interlaced Output)

Additional, it automatically dectects Telecined Film, which will be passed by the framerate conversion. Thus Avoiding blending in Film parts.

[Alex Z]

Originally posted by scharfis_brain
You may want to try my automated NTSC -> PAL conversion function.

http://forum.doom9.org/showthread.php?s=&threadid=67161

It can convert your NTSC-Video with PAL-Speedup (progressive output)
or without PAL-SPeedup (interlaced Output)

Additional, it automatically dectects Telecined Film, which will be passed by the framerate conversion. Thus Avoiding blending in Film parts.

@scharfis_brain

Is it posible to convert badly converted PAL->NTSC DVD (25p->29.96i) back to 25p and then slowdown to 23.976?

[auenf]

Originally posted by Alex Z
@scharfis_brain

Is it posible to convert badly converted PAL->NTSC DVD (25p->29.96i) back to 25p and then slowdown to 23.976?

automagically? almost impossible

even remotely easy? doubtful

Enf...

[Xesdeeni]

It depends on how badly the conversion was done.

If there is actual missing information (i.e. frames from the source that didn't make it to the destination), then it would be nearly impossible (well, some kind of heavy motion estimation might be able to reconstruct guesses at the missing frames).

If the frames are mixed (e.g. AVISynth's ConvertFPS()), it would be extremely difficult, but maybe not impossible. I did read a while back about doing some people doing some video recovery from this type of thing. I believe it was in connection with the Dr. Who episode recovery effort (some episodes were converted to NTSC and broadcast in North America, where they were recorded on early VCRs, but then the original and NTSC converted broadcast tapes were destroyed). By knowing the amount of mixing that was done, and following the cadence of the conversion, I believe they had some luck recovering most of the original PAL frames/fields from the NTSC recording. But I don't believe anyone has published their algorithm for us to use.

Xesdeeni

[Alex Z]

Originally posted by Xesdeeni
It depends on how badly the conversion was done.

If there is actual missing information (i.e. frames from the source that didn't make it to the destination), then it would be nearly impossible (well, some kind of heavy motion estimation might be able to reconstruct guesses at the missing frames).

If the frames are mixed (e.g. AVISynth's ConvertFPS()), it would be extremely difficult, but maybe not impossible. I did read a while back about doing some people doing some video recovery from this type of thing. I believe it was in connection with the Dr. Who episode recovery effort (some episodes were converted to NTSC and broadcast in North America, where they were recorded on early VCRs, but then the original and NTSC converted broadcast tapes were destroyed). By knowing the amount of mixing that was done, and following the cadence of the conversion, I believe they had some luck recovering most of the original PAL frames/fields from the NTSC recording. But I don't believe anyone has published their algorithm for us to use.

Xesdeeni


Well, it looks really bad on pc just ok on TV. I think to keep audio unchanged they added 4fps. You can reproduce the effect if use this .avs on PAL progressive source. Any fast motion scene looks a bit stuttered and the edges of fast moving objects are not sharp. Is there a way to undo it?

xxxSource("PALFilm.xxx")
LanczosResize(720,480)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4,1,2)
Weave()

[Xesdeeni]

Originally posted by Alex Z
Well, it looks really bad on pc just ok on TV. I think to keep audio unchanged they added 4fps. You can reproduce the effect if use this .avs on PAL progressive source. Any fast motion scene looks a bit stuttered and the edges of fast moving objects are not sharp. Is there a way to undo it?

xxxSource("PALFilm.xxx")
LanczosResize(720,480)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4,1,2)
Weave()The script you show does not add 4fps. It uses a technique similar to NTSC 3:2 pulldown (telecine) for 24p material. It distributes the 25 frames among the 60 fields, repeating as necessary (001112233444556667788999...) On a computer, this will look pretty bad, because of the difference between fields, unless the player can deinterlace pretty well (this is true for any interlaced source). On a TV, this should look pretty good, at least not much worse than any film you've ever seen, since the process is similar to telecine.

My personal opinion on this is to use this technique instead of slowing the video to 23.976p fps. If you do the conversion, playback will be telecined (3:2 pulldown) either explicitly or implicitly anyway. So you still get the replicated pattern. Even on a progressive TV, the gain is fairly minimal, depending on how good the deinterlacer in the TV may be. But you are guaranteed to be screwing with the audio if you adjust the frame rate. So I recommend just leaving the audio alone and using the above technique.

That said, if you want to undo the conversion, and it was done the way you illustrate in the script above, you definitely can. If you think you can match the cadence (sequence of repeated fields), then you can just use an AVISynth script like this:xxxSource("NTSCVidOfPALFilm.xxx")
DoubleWeave()
ChangeFPS(50)
SelectEvery(2,0)
LanczosResize(720,576)But you have to make sure this matches the cadence for the entire movie. I suspect this isn't practical (I've never tried it), so I'd recommend using Decomb instead. You should DoubleWeave() and then use Decomb to decimate back to 25p. Then you can do what you want.

Xesdeeni

[Alex Z]

Originally posted by Xesdeeni
The script you show does not add 4fps. It uses a technique similar to NTSC 3:2 pulldown (telecine) for 24p material. It distributes the 25 frames among the 60 fields, repeating as necessary (001112233444556667788999...) On a computer, this will look pretty bad, because of the difference between fields, unless the player can deinterlace pretty well (this is true for any interlaced source). On a TV, this should look pretty good, at least not much worse than any film you've ever seen, since the process is similar to telecine.

My personal opinion on this is to use this technique instead of slowing the video to 23.976p fps. If you do the conversion, playback will be telecined (3:2 pulldown) either explicitly or implicitly anyway. So you still get the replicated pattern. Even on a progressive TV, the gain is fairly minimal, depending on how good the deinterlacer in the TV may be. But you are guaranteed to be screwing with the audio if you adjust the frame rate. So I recommend just leaving the audio alone and using the above technique.

That said, if you want to undo the conversion, and it was done the way you illustrate in the script above, you definitely can. If you think you can match the cadence (sequence of repeated fields), then you can just use an AVISynth script like this:xxxSource("NTSCVidOfPALFilm.xxx")
DoubleWeave()
ChangeFPS(50)
SelectEvery(2,0)
LanczosResize(720,576)But you have to make sure this matches the cadence for the entire movie. I suspect this isn't practical (I've never tried it), so I'd recommend using Decomb instead. You should DoubleWeave() and then use Decomb to decimate back to 25p. Then you can do what you want.

Xesdeeni

@Xesdeeni

Can you explain the Decomb script in more details. What am I doing wrong here?

xxxSource("NTSCVidOfPALFilm.xxx")
DoubleWeave()
decimate()

[Xesdeeni]

Originally posted by Alex Z
Can you explain the Decomb script in more details. What am I doing wrong here?

xxxSource("NTSCVidOfPALFilm.xxx")
DoubleWeave()
decimate() I'm sorry, my mistake. You don't have to use DoubleWeave(). Just tryxxxSource("NTSCVidOfPALFilm.xxx")
ConvertToYUY2()
Telecide(order=1)
Decimate(6)
AssumeFPS(25)The only problem with this is that the NTSC timing isn't 60 fps, but 59.94 fps. As a result, there may be a hiccup now and then. This is why I had to add the AssumeFPS() at the end.

Xesdeeni

[Alex Z]

Originally posted by Xesdeeni
I'm sorry, my mistake. You don't have to use DoubleWeave(). Just tryxxxSource("NTSCVidOfPALFilm.xxx")
ConvertToYUY2()
Telecide(order=1)
Decimate(6)
AssumeFPS(25)The only problem with this is that the NTSC timing isn't 60 fps, but 59.94 fps. As a result, there may be a hiccup now and then. This is why I had to add the AssumeFPS() at the end.

Xesdeeni

@Xesdeeni and all

Thanks a lot. The script is working wonderfully.

[cweb]

What's best with regards to quality, converting an NTSC film dvd source backed to PAL dvd using this script with some minor filtering or just making an NTSC dvd backup reencoded from the source (playback with pulldown)? Assume that a PAL dvd player is available and it can play back NTSC encoded dvd's.
Of course the first option would take more time to encode..

[Xesdeeni]

That depends on the quality of the DVD player's conversion.

My NTSC DVD player can convert PAL DVDs to NTSC. It's real NTSC out of the player, because almost no NTSC TVs can take PAL or a hybrid. But the way the player does the conversion is pretty poor. I'm not privy to the internals of the DVD player, but just based on observation and SWAGs, it appears to me as if it starts by throwing out every other field. This makes any PAL source 25 progressive frames, but of course reduces the vertical resolution to 288 lines. It then scales this video. Based on the fact that the resulting video is a bit short vertically (black bars at the top and bottom), I'm guessing it uses the already built-in letterbox scaler. That scaler done 480->360 scaling, or .75x. Taking 288 * 2 * .75 gives 432 lines, which is just less than the 440-ish lines that show up on a typical TV. You can see evidence of the missing lines in stair-stepping on nearly horizontal lines. But 288 lines scaled to 432 is not quite as bad as throwing away one field of NTSC would be. Of course, since the letterbox scaler is already in use, it can't use the scaler to letterbox 16:9 stuff, so anamorphic PAL is vertically stretched. It then looks like it shows the 25 fps video at 24 fps with 3:2 telecine. I'm not certain how it plays back the audio slower, but it has pitch shifting in the Karaoke feature, which might be useful for this.

Anyway, if you'll pardon my digression, the point is that the player doesn't do that great a job. My understanding of PAL players playing NTSC DVDs is that the results might be a bit more satisfactory.

I've heard that most PAL TVs will accept 525/60 inputs, although they may not like the NTSC color encoding. So I believe that most PAL DVD players, when they play an NTSC DVD, output 525/60 with the PAL color encoding. This hybrid would look pretty good, and in general should be better than converting the video. But of course, there are no guarantees.

Xesdeeni

[max2k]

@Xesdeeni:

I've read this thread and your "Standards Conversion" page with great interest.

My source material is NTSC DV, interlaced ( Digital Camcorder footage ) - captured to AVI (Type2, DV).
Need to make a PAL DVD ( interlaced would be fine, I guess ) - to be viewed on TV.

Which script should I start with ? I saw the grid on the webpage - but there was nothing corresponding to this ....

Can you point me to the script that I can use as a starting point ?

Thanks a bunch :)

[Xesdeeni]

I use the Main Concept DV codec, which works as a Video For Windows codec. I had no luck with the Microsoft (included with Windows) codec. The Main Concept one worked great, and it's free for decode, which is all you need in your case.

Use the latest AVISynth and get the 2.5.x SmoothDeinterlacer from http://www.avisynth.org/warpenterprises. Put the DLL into the AVISynth plugins directory.

Start with the following script:AVISource("NTSCDV.avi")
SeparateFields() # Correct for bug...
Weave() # ...in SmoothDeinterlacer
SmoothDeinterlace(doublerate=true)Load this script into VirtualDub and step through the video to be sure that the input field polarity is correct. SmoothDeinterlacer reads the polarity, but some codecs don't seem to get it right (well, it could be SmoothDeinterlacer, but I'll blame the codecs ;)). If the video doesn't move correctly, add ComplementParity() before the SmoothDeinterlace() call above and check again. Then complete the script:ConvertFPS(50) # or ChangeFPS(50)
LanczosResize(720,576)
SeparateFields()
SelectEvery(4,0,3)
Weave()Load this script into VirtualDub just to do a sanity check. Then load the script into your encoder. Encode a short sample clip that includes some still and some motion. Author and burn a sample (DVDRW) to test the output field polarity. View the result on a TV (not a PC) and ensure the still images look OK and that the motion is correct. If the motion is wrong, replace the SelectEvery() call above with SelectEvery(4,1,2).

Then you are set to make your DVD.

Xesdeeni

[scharfis_brain]

xesdeeni: why do you recommend using that old smoothdeinterlacer?

kernelbob is much better IMO....

[Xesdeeni]

Originally posted by scharfis_brain
xesdeeni: why do you recommend using that old smoothdeinterlacer?

kernelbob is much better IMO.... I assume that's a rhetorical question (http://biphome.spray.se/gunnart/video/AVSPorts/SmoothDeinterlacer/) ;)

Xesdeeni

[cyberbob25]

Xesdeeni,

I have followed your instructions on your website for converting a PAL movie to NTSC. When I load the .avs file into TMPGENC, in the preview window, it shows the following message: "Evaluate: Unrecognized Exception: D:\movies\dvd\dvd2avi\test.avs, line 3"

I've followed your steps exactly. If I continue anyway, and click on start, it creates a 2.5KB file that I can't play. The only exception is that i am using MPEG2DEC3dg.

I am using the following versions:
-The latest version of DVD2AVI (1.77.3)
-The newest Deinterlacer.dll off of http://www.avisynth.org/warpenterprises. (2.5xx)
-AVISynth 2.5
-TMPGENC 2.54.36.134

Do you have any ideas?

[Xesdeeni]

Originally posted by cyberbob25
"Evaluate: Unrecognized Exception: D:\movies\dvd\dvd2avi\test.avs, line 3"I've never seen an error like that one. What is on line 3 of your AVS script? Can you load the D2V directly into TMPGEnc (it has this ability)?

Also, at this point, although I've sinned by not updating the web page, I'm using DGMPGDec (http://neuron2.net/fixd2v/decodefix.html) instead of DVD2AVI and MPEG2DEC.dll. I'd recommend switching to those.

Xesdeeni

[cyberbob25]

Wow...I think that was the quickest reply I've ever gotten on a forum.

As for the .avs script, I literaly did a copy and paste from your example on your website, and just changed line 3 to:

mpeg2source("d:\movies\dvd\dvd2avi\test.d2v").

I'm sure I'm doing something wrong, I just can't figure out what. When I get home, I'll try using DGMPGDec instead. I had previously tried using MPEG2DEC.dll, and I'm pretty sure that I got an error in TMPGENC then stating that MPEG2DEC is not a valid plugin for AVISynth 2.5. Can't remember for sure though. That was using a version of MPEG2DEC.dll that I found somewhere off of the internet.

Please forgive my newbiness.

[Xesdeeni]

Before you switch to DGMPGDec, just try loading the D2V into TMPGEnc. It should load.

If not, then there's something wrong with the D2V file. Be sure your source is still there and hasn't been moved. A path to the VOBs is stored in the D2V, so if you remove a DVD or move the files, the D2V isn't valid any more.

If the D2V loads into TMPGEnc, then it's probably MPG2DEC.dll that is the problem. Since DGMPGEnc includes DGIndex.exe and DGDecode.dll as a matched set, fixing this is probably easiest by just switching to DGMPGDec.

We were all newbies once, and we're all newbies in some other area still.

Xesdeeni

[max2k]

xesdeeni:

Thanks a bunch for your detailed response .... I would try it out and let you know if it went well

Thanks again !

Originally posted by Xesdeeni
I use the Main Concept DV codec, which works as a Video For Windows codec. I had no luck with the Microsoft (included with Windows) codec. The Main Concept one worked great, and it's free for decode, which is all you need in your case.

Use the latest AVISynth and get the 2.5.x SmoothDeinterlacer from http://www.avisynth.org/warpenterprises. Put the DLL into the AVISynth plugins directory.

Start with the following script:AVISource("NTSCDV.avi")
SeparateFields() # Correct for bug...
Weave() # ...in SmoothDeinterlacer
SmoothDeinterlace(doublerate=true)Load this script into VirtualDub and step through the video to be sure that the input field polarity is correct. SmoothDeinterlacer reads the polarity, but some codecs don't seem to get it right (well, it could be SmoothDeinterlacer, but I'll blame the codecs ;)). If the video doesn't move correctly, add ComplementParity() before the SmoothDeinterlace() call above and check again. Then complete the script:ConvertFPS(50) # or ChangeFPS(50)
LanczosResize(720,576)
SeparateFields()
SelectEvery(4,0,3)
Weave()Load this script into VirtualDub just to do a sanity check. Then load the script into your encoder. Encode a short sample clip that includes some still and some motion. Author and burn a sample (DVDRW) to test the output field polarity. View the result on a TV (not a PC) and ensure the still images look OK and that the motion is correct. If the motion is wrong, replace the SelectEvery() call above with SelectEvery(4,1,2).

Then you are set to make your DVD.

Xesdeeni

[cyberbob25]

Xesdeeni:

I'm apparently really stupid. The reason I was getting that particular error was because I was trying to do this using a remote desktop from work. Because of this, I didn't notice that DVD2AVI was actually trying to process the entire video to create the .d2v file... Ihad assumed that since you were only saving the project, it was just saving the settings for what was to be done later.

Anywho, after I got home and realized this and let it finish processing, I no longer get that error in TMPGENC. Instead, I get a new one :)

"Unrecognized Exception: D:\movies\dvd\dvd2avi\test.avs, line 5"

Pretty much the same error message, just different line this time. My .avs file looks like this (and this time I tried using DGMPGDec).

LoadPlugin("dgdecode.dll")
LoadPlugin("SmoothDeinterlacer.dll")
MPEG2Source("D:\movies\dvd\dvd2avi\test.d2v")
SmoothDeinterlace(doublerate=true)
LanczosResize(720,480)
ChangeFPS(59.94) # or ConvertFPS(59.94)
SeparateFields()
SelectEvery(4,1,2)
Weave()
ConvertToRGB()

Where lanczosresize is obviously the command on line 5.

Also, just to give all details and look for the best way of doing this... My source is a PAL interlaced DVD which has one VTS containing lots of PGC's (a few for the menus, several slides(each being a PGC), and then the video).

Is there anyway to convert this DVD to NTSC without losing the menu functionality, or do I basically have to let TMPGENC/AVISynth convert everything, and then re-create the menu buttons, and re-author?

Thanks again for all of your help.

[Xesdeeni]

Originally posted by cyberbob25
"Unrecognized Exception: D:\movies\dvd\dvd2avi\test.avs, line 5"LoadPlugin("dgdecode.dll")
LoadPlugin("SmoothDeinterlacer.dll")
MPEG2Source("D:\movies\dvd\dvd2avi\test.d2v")
SmoothDeinterlace(doublerate=true)
LanczosResize(720,480)
ChangeFPS(59.94) # or ConvertFPS(59.94)
SeparateFields()
SelectEvery(4,1,2)
Weave()
ConvertToRGB()Well first, since you are using AVISynth 2.5.x, you don't have to have the LoadPlugin() calls any more. Just put the DLLs into the AVISynth plugin directory.

Second, you need to add a SeparateFields() and Weave() before SmoothDeinterlace() to work around a bug.

Next, break things down and see where the problem lies.
1. Does the D2V load correctly into TMPGEnc?
2. Does a script consisting only of the MPEG2Source() line load into VirtualDub? TMPGEnc?
3. Does a script with MPEG2Source() and SmoothDeinterlacer() (with SeparateFields() and Weave()) load into VirtualDub? TMPGEnc?
4. Do BilinearResize() or BicubicResize() make a difference instead of LanczosResize()?My source is a PAL interlaced DVD....Is there anyway to convert this DVD to NTSC without losing the menu functionality, or do I basically have to let TMPGENC/AVISynth convert everything, and then re-create the menu buttons, and re-author?Unfortunately, there isn't an automated way. You have to convert the content and re-author from scratch. Sorry.

Xesdeeni

[cyberbob25]

I'll try the other things you mentioned, I just wanted to add that I forgot to include in my last post that the D2V file does properly load into TMPGENC. I'll try the other things as soon as I get the chance.

[cyberbob25]

Ok, after playing around and trying different things, I think I finally found a script that works. Part of the problem was definitely the "LanczosResize(720,480)". As soon as I deleted this out of the .avs file, moved around the elements you described earlier, it loaded fine. My script now looks like this:


MPEG2Source("d:\movies\dvd\dvd2avi\test.d2v")
SeparateFields()
Weave()
ConvertToRGB()
SmoothDeinterlace(doublerate=true)
BicubicResize(720,480)
ChangeFPS(59.94) # or ConvertFPS(59.94)
SelectEvery(4,1,2)

I also had to move up the ConvertToRGB() command to get it to work properly. It loaded up fine, but after doing a test encode, the resulting video was just a black screen with red text across the top stating that it could only work in a specific color space (though I don't remember the exact message).

Does everything look OK to you Xesdeeni? Will this work for me?

Forgive me if this is a stupid question, but I just realized...since the source is already interlaced, why do I run smoothdeinterlacer()?

[Xesdeeni]

Originally posted by cyberbob25
Part of the problem was definitely the "LanczosResize(720,480)"I thought LanczosResize() was OK with the same inputs as BilinearResize() and BicubicResize(), but maybe not. See below...My script now looks like this:MPEG2Source("d:\movies\dvd\dvd2avi\test.d2v")
SeparateFields()
Weave()
ConvertToRGB()
SmoothDeinterlace(doublerate=true)
BicubicResize(720,480)
ChangeFPS(59.94) # or ConvertFPS(59.94)
SelectEvery(4,1,2)I also had to move up the ConvertToRGB() command to get it to work properly. It loaded up fine, but after doing a test encode, the resulting video was just a black screen with red text across the top stating that it could only work in a specific color space (though I don't remember the exact message).AVISynth and DGMPGDec can deal with YV12 (a.k.a. 4:2:0), which is the native format of MPEG, and this is what is output by MPEG2Source() in this case. SmoothDeinterlacer can't deal with this space, it can only handle YUY2 and RGB. But you'll get a bit better speed out of SmoothDeinterlacer if you use YV12toYUY2(interlaced=true) instead of ConvertToRGB(). You should also be able to put LanczosResize() back.Forgive me if this is a stupid question, but I just realized...since the source is already interlaced, why do I run smoothdeinterlacer()? The standards conversion process uses SmoothDeinterlacer. You get 50 fields/sec at 720x576 out of MPEG2Source(). You have to get this to 59.94 fields/sec at 720x480. There is a document at Snell and Wilcox's site (http://www.snellwilcox.com/knowledgecenter/books/books/estandard.pdf) that goes into the gory detail of doing this while interlaced. My eyes cross every time I re-read it (I was given a copy over 10 years ago at NAB by a guy with S&W).

But if you convert your 50 fields/sec to 50 frames/sec, it is much easier to deal with the concept of converting that to 59.94 frames/sec. And going from 59.94 frames/sec to 59.94 fields/sec is simply a matter of throwing out half of every frame.

So all you have to do is do a decent deinterlacing job to get to 50 frames/sec, a decent scaling job to get to 720x480, and then figure out how to convert the frame rate itself to get to 59.94 frames/sec. SmoothDeinterlacer handles the first, LanczosResize() handles the second, and for now ConvertFPS() or ChangeFPS() handles the third.

Xesdeeni

[scharfis_brain]

xesdeeni: I tried your smoothdeinterlacer and found its metric being as good as dgbob's.

smoothdeinterlacer simply does a pixel duplication on moving areas, correct?

plus, it isn't in phase with all other bobbers out there (it is one frame behind/future, sorry can't tell you now)

I like the special interpolation tecniques of kerneldeint & tomsmocomp/sangnom.

if you have time to implement choosable kernel or edgedirected interpolation, your smoothdeinterlace will definately go to the upper level of the bobbers, but with simple pixel-duplication (stairstepping is your everytime friend) it becomes unacceptable for my purposes...

[cyberbob25]

Xesdeeni:

I've made the changes that you recommended:

MPEG2Source("d:\movies\dvd\dvd2avi\test.d2v")
SeparateFields()
Weave()
YV12toYUY2(interlaced=true)
SmoothDeinterlace(doublerate=true)
LanczosResize(720,480)
ConvertFPS(59.94)
SelectEvery(4,0,3)

It loads fine into TMPGENC, however, the product is unwatchable. Nearly every frame is full of noise blocks (and I don't mean just a few...the entire picture), and the video seems to run quite a bit faster. So far, I've tried using both convertfps(), and changefps(), and also both SelectEvery(4,1,2) and SelectEvery(4,0,3). No matter the configuration, it still looks the same.


Any ideas?

[cyberbob25]

Nevermind my last post...I had used DVDReMake to strip everything out of the dvd with the exception of a 150Meg clip for testing, and apparently, that was my problem, as I just tried the original movie, and it worked great.

However, now, when I remux the sound back in, it gets out of sync. This of course makes sense to me, but how do I correct it?

Thanks again for all of your help Xesdeeni

[Xesdeeni]

Originally posted by scharfis_brain
smoothdeinterlacer simply does a pixel duplication on moving areas, correct?No, on moving areas it does a linear interpolation.plus, it isn't in phase with all other bobbers out there (it is one frame behind/future, sorry can't tell you now)You mean the frame output doesn't match? Have you compared to Bob()?I like the special interpolation tecniques of kerneldeint & tomsmocomp/sangnom.Any basic interpolation can't account for the missing lines, so stairsteps will happen. I've always wanted to do some experiments with a smarter interpolator that notices nearly-horizontal edges and tries to do a better job. Maybe these interlacers have done so. I'll have to find some time to check them out.if you have time to implement choosable kernel or edgedirected interpolation, your smoothdeinterlace will definately go to the upper level of the bobbers, but with simple pixel-duplication (stairstepping is your everytime friend) it becomes unacceptable for my purposes...You should understand that all I did was port Gunnar Thalin's VirtualDub filter to AVISynth. I did add the bob feature, but the algorithms are Gunnar's. Maybe he would like to take a look.Originally posted by cyberbob25
However, now, when I remux the sound back in, it gets out of sync. This of course makes sense to me, but how do I correct it?With this type of conversion, the resulting video is exactly the same length as the original, so the audio should not be out of sync. You shouldn't have to process the audio at all. Just use the AC3 extracted by DGIndex.

Xesdeeni

[cyberbob25]

Strange then. It is in sync in the beginning, but by the end it's maybe a full 2 seconds off.

[Xesdeeni]

Is the resulting file the same length as the original?

Xesdeeni

[sjc65]

Hi all,

I'm new to the forums but have learned much on my own by searching and reading. Using Xesdeeni's conversion guides and info from various forums, I tried converting Pal dvd to Ntsc dvd with only one reencode using TmpgEnc. The results looked fine on the TV, no jittering or other anomalies, but the simplicity of the procedure makes me think I'm missing something. Here's what I did:

loaded a demuxed pal 4:3 m2v into TmpgEncv2.521.58.169 with these settings:

Advanced:
interlace
top field first
4:3 625 line(pal)
Full Screen
Do Not Frame rate Conversion

Video:
MPEG-2
720x480
4:3 display
23.976 fps(internally 29.97 fps)
2-pass VBR
MP@ML
NTSC
3:2 pulldown when playback
4:2:0
10 bits
highest quality

I also slowed down the audio. As I said, the results looked very good, ~4% increase in running time and audio matched up perfectly when remuxed within Scenarist. So my question is, am I missing something? Can the dvd2avi/avisynth steps be bypassed and conversion be done using TmpgEnc alone? And, is any information lost in bringing the pal video back to 24fps? Thanks for any input/thoughts/advice you may have.

[cyberbob25]

Is the resulting file the same length as the original?

I checked the length of my ac3 file that DGMPGDec created. It was 2:03:37. I then checked the length of the m2v file that DGMPGDec created. It was 2:03:41, a clear 4 second difference.

To be completely honest, sync isn't that much of an issue in this movie, since it is in German, and I would only have to watch it with subtitles anyway, but it would still have the action moments sync up. How would I go about slowing down the audio to fill that 4 second gap?

[Kika]

@sjc65

Your methode only works on progressive source. If you try it with interlaced Video, you will get very strange looking results.
An other thing is the resizing engine of TMPGEnc, it isn't as good as AVISynth can handle this.

[sjc65]

Thanks for your response Kika. The 2 sources I've used have been from pal dvd, most of which is progressive I believe. I'm actually practicing for converting a pal digital cable sourced film recorded on a standalone dvdrecorder in 16x9, not sure if that would be progressive or interlaced(I haven't got the files yet, should arrive this week). The inferior resizing of TmpgEnc is reason enough to run through avisynth. If quality suffers from the shortcut, the extra steps will be worth it. Time to read up on avisynth. Thanks again.

[cyberbob25]

Anybody? What program would I use to slow down the .ac3 file enough to fill the 4 second gap so that I can synch it with my video? What is the easiest way to accomplish this?

[auenf]

Originally posted by cyberbob25
Anybody? What program would I use to slow down the .ac3 file enough to fill the 4 second gap so that I can synch it with my video? What is the easiest way to accomplish this?

besweet

Enf...

[jojo15]

Hi,
what's the best way to demux vobs, and mux the files after ntsc2pal conversion to vob again??
and do i have to demux all vob files and then it'll work or do i have to edit something in the other files also??
Thnx in advance..

[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

[scharfis_brain]

with yv12 the fields only have the halved vertical chroma resolution.

this means, looking at the U or V plane of an YV12 image show interlacing on moving objects!

a deinterlacer handles those chroma planes, like they were Y planes.
The only difference is that they are width and height reduced.

if you deinterlace and afterwards convert to yuy2 (progressively), the static and high detailed parts are retaining their best possible chroma detail.

but if you convert to yuy2 interlaced before the deinterlacer, high detailed vertical chroma immediatelly gets destroyed!

that's why I am hoping for a motion-adaptive YV12 -> YUY2 conversion plugin.

converttoyuy2(interalced=true) only does fieldbased upsampling, which means static areas are handled fieldseparated, too!

[Kika]

converttoyuy2(interlaced=true) only does fieldbased upsampling, which means static areas are handled fieldseparated, too!

I see, good point.
I really hate this YV12 interlaced stuff... ;)

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?

No, CCE or TMPGEnc aren't able to do a Field based or mixed Encoding. Same for variable GOP Pattern. Hard to belive, but there is no Consumer MPEG2-Encoder out which supports all Features of MPEG2.
To check this, you can use some Analysis Tools like Bitrateviewer or MPEG Repair.

[scharfis_brain]

@KiKa: I haven't read the whole thread (I am just checking in here occasionally...

Are there any software MPEG-2 encoders, that are able to decide theirselves whether they do progressvie or interlaced encoding like seen in DVB-Streams?

low motion=progressive frames (even if interlaced content!)
heigh motion = interlaced for interlaced content or proigressive for progressive content.

even fieldblended conversions have an alternating cyclic pattern of progressive and interlaced encoded frames.
As found in the DVB-S Stream of Sat.1's Fahrenheit 9/11 examining the preview of DGIndex/DVD2AVI.

[Zeul]

well it seems like everyone has a different opinion :D But i get the consensus that going from PAL(p) -> NTSC(p) is not recommended. PAL(p) -> NTSC(i) IS recommended. On my tests converttoyuy() appears to have no apparant effect on the output. On a HDTV this may be different, but here in the UK, we do not have access to HDTV and it doesn't seem likely we ever will :(

Zeul

[Kika]

Are there any software MPEG-2 encoders, that are able to decide theirselves whether they do progressvie or interlaced encoding like seen in DVB-Streams?

Um, hard to answer... Let's try. ProCoder is able to do a field based interlaced Encoding. This means, every field will be encoded separatly and not weaved, like most of the Encoders do. But ProCoder can't encode in mixed mode. Maybe this option was a little too hard for the programmers? ;)
In mixed mode, the Encoder has to decide which Part of the Video is interlaced and which part is progressive. But, and that's the problem, the mode (interlaced or progressive) can only change GOP by GOP. That's because varible GOP Pattern Encoding is necessary for encoding in mixed mode.
Variable GOP-Pattern is an other feature of MPEG2. It means, the Encoder can change the Structure of the GOP - ANY aspect of the Structure. GOP-Lenght, the Pattern (IBP instead of IBBP) and so on.
Like i wrote earlier: I don't know a consumer MPEG2 Encoder which supports all these Features, only mpeg2enc has all these modes.
Unfortunatly, mpeg2enc isn't a good Encoder... :(

low motion=progressive frames (even if interlaced content!)
heigh motion = interlaced for interlaced content or proigressive for progressive content.

That's how mixed Mode should work. But again, i don't know an Encoder which is able to do that. I don't even know a Muxer or DVD-Authoring-Program which accepts encodings like this (maybe Scenarist, but without am Encoder for this mode, i can't check this). Some of the Authoring Tools do have problems with field based interlaced Encodings...(TDA can handle it, also all Tools from Canopus, Ulead DVDPowerTools can't), and mixed mode is much more complicated.

I know, mixed mode is part of the Specs, but i've never seen a stream encoded this way.

[Xesdeeni]

Originally posted by scharfis_brain
with yv12 the fields only have the halved vertical chroma resolution.

this means, looking at the U or V plane of an YV12 image show interlacing on moving objects!

a deinterlacer handles those chroma planes, like they were Y planes.
The only difference is that they are width and height reduced.OK, I took a look at this page (http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html) has some information on DVD players that incorrectly decode the chroma. If you compare http://www.hometheaterhifi.com/volume_8_2/images/chroma-figure-3.jpg to http://www.hometheaterhifi.com/volume_8_2/images/chroma-figure-4.jpg, I think that may be where the key lies.

If we don't have a deinterlacer that can handle 4:2:0 natively, it seems the conversion should be done before the deinterlacing. At that point the 75:25 weighted conversion would be done. (I don't grok MMX, so I can't quite figure out whether ConvertToYUY2() does this correctly, by looking at the source. There is different code for interlace vs. non-interlaced, but I don't see this weighting.)that's why I am hoping for a motion-adaptive YV12 -> YUY2 conversion plugin.I assume this means it doesn't.

SmoothDeinterlacer doesn't support YV12, so this makes sense. But KernelDeint does. But does it handle this correctly? From what I see in the source, it looks like it does. It cycles through all three planes, and handles the U and V planes the same as the Y plane, with 1/4 the size, but deinterlacing as appropriate.

So now I think I see why you recommend deinterlacing first...at least with KernelDeint :)converttoyuy2(interalced=true) only does fieldbased upsampling, which means static areas are handled fieldseparated, too!I'm not sure what you mean by fieldbased, but I assume you mean it's being done wrong :) Have you let the AVISynth team know this?

Xesdeeni

[Wilbert]

assuming clip has combing:

I'm not sure what you mean by fieldbased, but I assume you mean it's being done wrong Have you let the AVISynth team know this?
It's not really done right or wrong, but there's improvement possible. What you want is that the upsampling in "static frames" is done progressively (and in "dynamic frames" field-based with alternating 3/4-1/4 weighting). This is possible (but not with ConvertToYUY2(interlaced=true/false)), and described here

http://www.avisynth.org/FieldBasedVideo (ConvertHybridToYUY2)

But what you actually want is that the upsampling in "static areas" is done progressively (and in "dynamic areas" interlaced-based). Such a filter doesn't exist yet.

[emdiem]

Wonder if this topic is active. I tested some script that was posted, smootdeinterlacer script i cant use in 2,5

i save the script and then make a fake avi with ffvfw and promt:
Plugin SmoothDeinterlacer.ddl is not an AviSynth 2,5 plugin

SCRIPT:
# NTSC (29.97fps) to PAL (25fps)
LoadPlugin("SmoothDeinterlacer.dll")
AVISource("juniorjack_d2v_vfapi.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


I tested at a friends work to open my NTSC vob file and save it to PAL with ProCoder 2, i get same jerky images on the video as when i tested another script i found in this thread in the first pages.

Smoothdeinterlacer only work on lower versions of AviSynth?

I also wonder how the resize is made? I mean, why not just add black borders to evenout the height? Why stretch the videostream when you can add black borders to fill the extra space. Is this possible to make instead of resize?

[Zeul]

@emdiem
There are different versions of SmoothDeinterlace for the different avisynth versions. However, useing kerneldeint seems to be a better plugin.

[emdiem]

I can only find one at http://biphome.spray.se/gunnart/video/AVSPorts/SmoothDeinterlacer/

i downloaded the latest one.

[Xesdeeni]

But what you actually want is that the upsampling in "static areas" is done progressively (and in "dynamic areas" interlaced-based). Such a filter doesn't exist yet.Isn't that just deinterlacing and then color space conversion (interlace=false)?I can only find one at http://biphome.spray.se/gunnart/vid...thDeinterlacer/Check out http://www.avisynth.org/warpenterprises/ for all your AVISynth plugin needs.

Xesdeeni

[scharfis_brain]

Isn't that just deinterlacing and then color space conversion (interlace=false)?

it is similar to deinterlacing the UV planes, but it is NOT the same.

deinterlacing the UV planes halves vertical resolution by two.

motion adaptive chroma upsampling uses exactly the same comb-mask like deinterlacers are using to decide whether interlaced (combs are detected) oder progressive (no combs) upsampling is used.

[Zeul]

I am interested to know your recommendations for a hybrid NTSC -> PAL conversion script, keeping the length the same. Is the std hybrid avs script used before the conversion to pipe a steady 29.97 stream? ie

import("C:\Build\new.avs\addaudio.avs")
LoadPlugin("C:\Build\new.dvd2avi\mpeg2dec3dg.dll")
Mpeg2Source("001.d2v" ,Idct=0)
LoadPlugin("decomb.dll")
Telecide()
Decimate(mode=1,threshold=3)
LoadPlugin("kerneldeint.dll")
Kernelbob(order=1, sharp=true, twoway=true, threshold=0)
LanczosResize(720,576)
ConvertToYUY2(interlaced=true)
ConvertFPS(50)
SeparateFields()
SelectEvery(4,0,3)
Weave()
AddAudio()

OR is this first bit unneccessary

LoadPlugin("decomb.dll")
Telecide()
Decimate(mode=1,threshold=3)

The same question applied to a telecide source.

[Mug Funky]

here's my latest plaything:

bob with Tdeint (very good quality - the best so far without going into absurdly slow motion-compensated methods... for that see "mvbob").

convertfps to 50

then scale up with lanczos4resize (need later version of avisynth to get this internal scaler), select fields, then weave.

script:


assumetff() # sanity check - change it for DV source
tdeint(1,1,cthresh=4) # 1,0 for bottom-first, like DV
converttoyuy2()
convertfps(50)
lanczos4resize(720,576)
separatefields().selectevery(4,1,2).weave() # 4,0,3 if order is bork
converttoyv12(interlaced=true) # because QuEnc takes yv12...

assumetff() # sanity check for field-order
#bob() # uncomment this to check field-order in Vdub.


tdeint can be found in the avisynth development forum ("another motion adaptive ..." should be near the top)

this does a field-blend conversion, so it's only good for high-bitrate stuff. note also that output will be interlaced, and hopefully top-first.

i find that any kind of smart-bob plus field-blend will look slightly better than a standalone converter box - they seem to work either by dumb-bob or field-separation, which gives very slight jaggyness. usually this is less than the inherent blur of the source, so it's not a big deal.

[scharfis_brain]

afer some analysis of fieldblended FILM->NTSC->PAL crap, I found, that mostly two methods are used.

the first applies very low thresholded kernelbobbing with blending to 50i
(was determineable, because there are kernelel-ghosts already in such sources)

for the 2nd I think, they are using some kind of mocomped deinterlace with mocomped framerate conversion for 60i-stuff.
with 24p telecined contents such converter falls back to traditional deinterlacing with an unknown non-kernel interpolation (no kernelghosts!). the framerate conversion is done via blending, because mocomped framerate conversion will produce terrible results motionwise with 3:2 stuff.

as you can see:
they are breaking a butterfly on a wheel
(mit Kanonen auf Spatzen schiessen ?!? in German)
with such overcomplex, for 60i tought converters...

this is, why I asked trictical for modding his in-developement TFM()

of course there are other methods doing a improperly conversion:
- do a stupid bob with pointsampling or bilinear and then knock out every 6th frame. then reinterlace.

- do a stupid bob with pointsampling or bilinear and then do fieldblending.

both methods suffer extremely wobbling static details and lacking resolution.

[spase]

In converting some PAL DVD (progressive I believe) sources to NTSC DVD I am using the following script:

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

which yields an interlaced NTSC stream at 29.970 fps which should sync up fine with the audio (i.e. no audio time shifting is necessary).

Am I correct in these assumptions?

Also, is this the best way to go from PAL (progressive) to NTSC (either progressive or interlaced... whichever yields better results)?

The only reason I ask is because there seems to be a lot of different ways to do this (even by only looking at this thread) and I am a little confused.

[Xesdeeni]

Originally posted by spase
In converting some PAL DVD (progressive I believe) sources to NTSC DVD I am using the following script:

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

which yields an interlaced NTSC stream at 29.970 fps which should sync up fine with the audio (i.e. no audio time shifting is necessary).

Am I correct in these assumptions?If the source is progressive, then this will work well. And yes, the audio will remain sync'd. But be careful that the source fields don't get out of sync. Pairs of fields in each frame should be from the same "instant of time," but rarely the fields can split across frames. The frames can still be reconstructed, but not as easily. Decomb works well for this.Also, is this the best way to go from PAL (progressive) to NTSC (either progressive or interlaced... whichever yields better results)?As with anything, "best" is in the eyes of the beholder. There are two basical ways to convert 25fps progressive PAL to NTSC:

1. As above.
Pros: No speed change; no audio manipulation necessary
Cons: Telecine-like artifacts; Interlaced NTSC (harder to compress); More difficult to deinterlace for progressive playback

2. Change the speed to 23.976 fps progressive.
Pros: Progressive NTSC (easier to compress); no telecine artifacts on PC playback (multiple of 24 Hz refresh; otherwise, there are still telecine artifacts)
Cons: Audio manipulation (slowed with pitch change, or slowed with pitch adjustment artifacts); Program runs slower; Program lengthens

Xesdeeni

[OutSiderSP]

Xesdeeni,
I tried all possible configurations with your scripts and others' without great success. I could always see the interlacing. My source was a PAL movie, which DGEdit pointed as interlaced, and I wanted to convert to NTSC. I gave up and loaded the .d2v project into TMPGEnc 2.524 and guess what ! No artifacts at all, perfect conversion ! So, unless I´ve got to do weird filtering, TMPGEnc is the way I will go.

Regards

[Xesdeeni]

Interlaced artifacts will be visible on a progressive PC screen. They are supposed to be there. The destination is an interlaced video, and should be viewed on an interlaced display (or one designed to take an interlaced intput and deinterlace it). To create a purely progressive destination, you must either:

a) slow down the video, or
b) replicate on a frame basis.

If you do a), you'll need to also process the audio to slow it down. A straight conversion will cause a pitch shift. BeSweet and AVISynth can convert while doing a pitch correction, but the techniques used can have mixed results, and might not be acceptable on audio with large frequency ranges (i.e. music).

If you do b), your video will be more jumpy. That's because you'll be extending the duration of a particular frame on the screen more than its neighbors. That same is true for the interlaced version, but the frame version will have a larger difference, which will be much more apparent.

Xesdeeni

[OutSiderSP]

Xesdeeni,
Thanks for the reply. I understand the two methods and my preferred onr is a), because I cannot tell the pitch is lower without comparing with the real pitch; and I do not care if the film becomes 2 minutes and 34 secs longer. The fun will last longer. :D

What really bugged me was the fact that after your script the film was not interlaced anymore in TMPGEnc. If I loaded the .d2v it was interlaced. I was using

<code>
SeparateFields()
LanczosResize(720, 240)
Weave()
ChangeFPS(59.94)
</code>

What is wrong with it ? I copied your geocities script and it also gave me non-interlaced results... I do not understand it...

[Xesdeeni]

Originally posted by OutSiderSP
Xesdeeni,

What really bugged me was the fact that after your script the film was not interlaced anymore in TMPGEnc. If I loaded the .d2v it was interlaced. I was using

<code>
SeparateFields()
LanczosResize(720, 240)
Weave()
ChangeFPS(59.94)
</code>

What is wrong with it ? I copied your geocities script and it also gave me non-interlaced results... I do not understand it... I'm not sure where you got that script, but I'm pretty sure it's not from me. There are just so many things wrong in those few lines ;)

To convert a progressive PAL to NTSC, you don't necessarily need AVISynth, but you'll have to process the audio separately. TMPGEnc can convert the frame rate from 25p to 23.976p. Counterintuitively, you must check the "Don't do framerate conversion" when you do the encode. This keeps TMPGEnc from dropping frames to get from 25p to 23.976p, but with the same duration. Instead, it encodes the frames 1:1, lengthening the duration due to the slower frame rate. Then you can use BeSweet to convert the audio.

Alternatively, you can use AVISynth to convert the video and audio simultaneously. I think the script would be something as simple as:

xxxSource("PAL_25p.xxx")
LanczosResize(720, 480)
AssumeFPS(23.976, true)

I believe you also must run Pulldown.exe on the result to insert the flags to make it DVD-compliant.

Xesdeeni

[Paulcat]

I have attempted to read through this entire post and make sense of it at the same time, but no luck. What I am doing to convert PAL to NTSC is as follows

(1) Use DVD Decrypter in IFO mode, decrypt and demux the individual streams, .m2v video and .ac3 audio (usually)

(2) Use TMPGEnc to process the .m2v file, under the DVD NTSC template to make a new .mpg file

(3) Use TMPGEnc DVD Author (or IFO Edit) to re-author the new mpg with the original ac3 and no problems. Everything remains in sync and the picture quality is good enough for me.

If you want better, buy a better DVD Player :-)

p.s. Is PAL DVD always progressive?

[Xesdeeni]

Originally posted by Paulcat
p.s. Is PAL DVD always progressive? No. PAL can be interlaced as well.

I don't know if there was a question in the rest of your post, but if it works for you, that's all that counts.

Xesdeeni

[Paulcat]

Originally posted by Xesdeeni
No. PAL can be interlaced as well.

I don't know if there was a question in the rest of your post, but if it works for you, that's all that counts.

Xesdeeni

There wasn't a direct question, but I will ask one now. With all the hundreds of people here who know a hell of a lot more than I do, why can't someone come up with a stand-alone piece of software that can extract the video, convert it and author it all on it's own?

It seems doing it in a script is iffy at best, especially after reading all the DIFFERENT scripts for doing the same thing!

Each piece of software seems to be good at one thing, and to get a decent result you have to have so many of them (only some of them free) it's almost not worth attempting...

[Xesdeeni]

I'd say there are four reasons:

1. There is a large group of tasks that need to be performed. As you say, there are separate tools that do each one. To create a stand-alone, all that functionality would need to be built into one tool. And it would require an understanding of every piece.

2. As you also said, there are many ways to perform this conversion. There are disagreements about what looks better. And even that depends on the format of the source. Converting progressive material is different than converting interlaced material. So once a stand-alone tool chose one method, many people would complain about the process.

3. There really isn't a large market for the product. Because of 1 above, it is unlikely that this would be a free application. But in spite of a number of us posting here and elsewhere on the subject, the number of people interested is quite low. We have just been lucky enough to find one another.

4. There is a much easier alternative. A cheap DVD player that will play and convert PAL and NTSC is easy to find.

I prefer to do the conversion myself, because I have control. I have always been fascinated by the challenge and the process. But if all you are after is a one-click solution, it's available at your local Wal-Mart. The quality may or may not be what you want, but it is easy.

Xesdeeni

[OutSiderSP]

Xesdeeni,
I did not put the whole script here and forgot to ask you one question. My PAL source was interlaced (visually) and DGIndex pointed that out, too. I got confused because after the script is loaded into TMPGEnc, it was not interlaced ! That's why I got all confused. Your script has Smoothdeinterlace, which I used, but I thought it became interlaced again after Weave.

Thanks a lot for your patience in answering my newbie dumb questions. I am still to learn the deinterlace and reinterlace methods. I thought that to apply any filter I should first deinterlace, apply the filters and only then reinterlace, but it seems I am wrong in my reasoning.

Regards

[vhelp]

I hope this is not considered t-jacking or OT ...

Hi Xesdeeni and others..

I've ben following this thread for a while now. Not for it's PAL to NTSC
or vise versa, but for ideas to incorporate in my 30p source files from
my DV cam. In short, it can shoot footage in 30p full frame with no
bad deinterlacing artifacts (in my past tipicle delinterlaced methods
through AVIsynth scripts, there were odd (normal) artifacts) But, I'm back
on the scripts wagon, to turn DV home footage into Film-like speed and
quality, as well as its respective fps.
.
I've ben checking out Xesdeeni's scripts throughout the pages and varied
a little of his (and others) code snips as experiments, but I'm not getting
smooth playback. What I am looking for is a 30p to 24p Film (minus the pal
to ntsc) but with more smooth (less strobing) from my 30p source.
.
I always thought that the reason for the strobing was because on TV's,
they are interlaced fields at 1/60th second, and when two fields are
split and displayed on TV, the result is smooth motion throughout.
But, when the source is 30p (every frame) and displayed on TV, the final
result at 1/60th is now strobing. Very good quality, but stobing. I know
that people refer to this as Film-effect, but this is IMO, close to 1/2
Film-effect, because Film is 3 (strobe) frames, plus 2 frames split and
displaced to give a smooth look, and the results is smooth, barely
un-noticable strobing, except for when panning, which is minimal.
.
I'm trying to take my 30p and turn it into 24p, but with a Film spec
of 23.976 fps w/ a pulldown effect. So far, it's been very tricky,
and wearing (if I can say that) on my mental brain.

Can anyone give me some hints (I don't mind the hard work) or nudge,
to bring me closer ??

Thanks,
-vhelp

[scharfis_brain]

30fps to 24fps (or more precisely 29.97 to 23.976)
will ALWAYS result (EDITED) in jerkyness when using blending. No way out.

You need to use a motion compensated framerate converter.
Like mvtools from manao.
be sure to get mvtools 0.9.6.2.

or try motionperfect. But this gives a very wobbly image, which looks like water sometimes.

[vhelp]

Thanks scharfis_brain :)

I have tried some more over last night, but still jerks (I new and
exptect that)

I will look into by manao's mvtools.
-vhelp

[Grafdude]

I have a PAL interlaced movie, which I wish to convert into an NTSC movie. I saved my project with DGindex within the vob's, and I also wish to not touch the audio, so I don't want to alter the movie's time. DGindex gave me this info about the stream:

-Frame type: Interlaced
-Frame structure: Frame
-Field order: Top

Here's my avisynth script:

MPEG2source("___.d2v")
AssumeFrameBased()
AssumeTFF()
LanczosResize(720,480)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4,0,3)
Weave()
ConvertToYUY2(interlaced=true)

After the encoding, I imported the untouched ac3 track and the encoded stream into DVD-lab, and the duration of both matched exactly! The problem is, the audio is out of sync, it plays a little bit earlier from start to finish. What did I do wrong?

[scharfis_brain]

@vhelp: I edited my post above. It now makes more sense.
(My attention was drawed of while writing my post, sorry)

@Grafdude:

your script WILL mess up everything, if you are processing laced contents with it.

The Info of DGindex must NOT be used for identifying interlacing/progressive.

Use your eyes instead! They are far more better in judging interlaced/progressive!

PAL-interlaced to ntsc-interlaced will always result in this sequence:

xxxsource("blah.xxx")
assume?ff()
motionadaptivebobber(paramters) #kernelbob, tdeint
converttoyuy2(interlaced=false)
lanczosresize(last.width, 480)
convertfps(59.94) #if you like stutter, go for changefps
separatefields().selectevery(4,0,3).weave()

replace the bold parts with your preferred thingies.

[Grafdude]

@scharfis_brain:

I proceded like you directed, but made small modifications since I realized my source was partly interlaced. Now the problem is, the audio is still not syncing, even though they both have the same duration! I even tried a small delay on the audio track, it did sync at the beginning but it doesn't take too long before it gets out of sync.

assumetff()
Telecide(order=1)
converttoyuy2(interlaced=false)
LanczosResize(720,480)
ConvertFPS(59.94)
selectevery(4,0,3).weave()

[a2j]

mp3dom asked a question and no reply since then... if any body there?

[Mug Funky]

// the video is by default in YUY2 since it's a 50 Mbps MPEG-2!

hot dang! where do you get those? are they i-frame only or regular? i think if they're not i-frame only you'll be getting pretty damn close to (maybe better than) digibeta quality. otherwise it's still a cut above DV50, which aint bad at all :)

[mp3dom]

The Mpeg-2 is an I-frame based coming from a Pinnacle ChromeHD system. This is a result from an acquisition from Digibeta. I prefer MPEG over DV50 or DVCPro 50 because MPEG is better in interlaced (at least, is better handled by Pinnacle) and doesn't require field change or chroma upsampling.

[Xesdeeni]

I think only PAL DV25 is inherently bad at interlacing. It's 4:2:0, but I believe the rest are all samples within a line. NTSC DV25 is 4:1:1, DV50 is 4:2:2, and DV100 is 4:4:4. Too bad about the Pinnacle's handling of it.

Xesdeeni

[bellyman]

I understand that during the PAL to NTSC method, that a DEMUX process (split audio from video then process the video then MUX back together) is required.

Can someone please suggest where I might find a few good apps for this?

My step is to take a VOB (one movie may have 4-5 VOBs); convert to MPG then DEMUX into their own pieces. Assumes keeping AC3.

Someone a page back, apparently uses DVD Decrypter in IFO mode. Was wondering if there were any other good ones. At one point I d/l and used an app that created mpv and mpa files - command line perhaps, and for the life of me can't determine the program/file/directory etc of the app.

thanks
belly

[Guest]

One option for VOBs -> M2V + audio is DGIndex, part of the DGMPGDec package.

[magic144]

just thinking out loud here,
please explain away my ignorance

from this thread of discussion
I understand that the 'bobber' (be it bob, tdeint, whatever) interpolates each source field into an entire frame and that you therefore end up with a stream of frames at twice the frame-rate of the original (since originally it took two fields to make a frame)

is this not progressive video? and if so, is there no value in trying to keep it progressive at this point instead of making it interlaced again (which I presume is what's happening with the SeparateFields().SelectEvery().Weave() combo?

one more question I have is that when using the SelectEvery() function (which is called after the ConvertFPS() call), how do we know at that point to use fields 1 and 2 (or 0 and 3), since the fields have presumably been altered by the ConvertFPS() routine and don't strictly relate to the source TOP or BOTTOM fields anymore???

any answers to help my understanding would be much appreciated

cheers for all the info in this thread about TDeint and converting NTSC to PAL interlaced video - it seems to give much better results than using Procoder!

[Xesdeeni]

is this not progressive video? and if so, is there no value in trying to keep it progressive at this point instead of making it interlaced again (which I presume is what's happening with the SeparateFields().SelectEvery().Weave() combo?PAL and NTSC are interlaced. The closest thing to progressive you could create would be 25 fps PAL or 30 fps NTSC. But this will show only 25 or 30 "instants of time" per second. 50 or 60 would be more fluid. Interlacing is a compromise between resolution and fluidity of motion. If the scene isn't moving, you get the higher resolution (480 or 576 lines). If the scene is moving, you get 50 or 60 "instants of time" for smoother motion.one more question I have is that when using the SelectEvery() function (which is called after the ConvertFPS() call), how do we know at that point to use fields 1 and 2 (or 0 and 3), since the fields have presumably been altered by the ConvertFPS() routine and don't strictly relate to the source TOP or BOTTOM fields anymore???It has to do with the ordering of your destination format. Most destination formats store frames. A frame is made of two fields. But which field came first in time? There isn't a standard across all formats. DVDs expect the top field to have come first. DV expects the bottom field to have come first. The choice of 1 & 2 means the upper field is first (1 is the upper field). 0 & 3 means the lower field is first (3 is the upper field).

Xesdeeni

[scharfis_brain]

The choice of 1 & 2 means the upper field is first (1 is the upper field). 0 & 3 means the lower field is first (3 is the upper field).

This is not entirely true!

This returns TFF
assumetff().separatefields().selectevery(4,0,3).weave()

This returns BFF
assumetff().separatefields().selectevery(4,1,2).weave()

This returns BFF
assumebff().separatefields().selectevery(4,0,3).weave()

This returns TFF
assumebff().separatefields().selectevery(4,1,2).weave()

this means:

4,0,3 leaves the previously assume fieldorder untouched, while
4,1,2 reverses the previously assumed fieldorder.

that's why I always suggest to use assumetff/bff() and to avoid 4,1,2!
also this method is much more intiutive and predictable (do you really exactly KNOW which Fieldorder AVISynth assumesnternally?)!

[magic144]

think I need to explain my questions more

thanks to both Xesdeeni and scharfis_brain for your responses - you two are the masters of this universe as far as I can work out, Xesdeeni started this whole pal<->ntsc avisynthing going I think, and scharfis_brain just seems to have a great breadth of knowledge!

I appreciate that , e.g., my NTSC source is interlaced (it was recorded from hockey on the TV)
what I was asking though was that if each FIELD is expanded to a full frame (by guessing/interpolating the other vertical half of the frame) by the 'bobber' (is this not true?) then don't you effectively end up with the output of the bobber as 60 FRAMES-per-second (couldn't this be called progressive?) - so rather than hacking this back up into fields (discarding 1/2) and weaving it back into an interlaced clip, couldn't you somehow keep it as progressive (and wouldn't that be more straightforward)???

I'm not sure how the video is denoted as progressive or interlaced - I presume there are flags. Is the immediate output of the bobber interlaced or progressive? I assume that since each field is now a full frame, this is progressive... (albeit at a non-standard 60 frames-per-second)

maybe someone can explain this to me first, before I try and expand on my second question again...???

cheers in advance guys

[scharfis_brain]

- after a bob-deinterlacer (boober) you got progressive video at full rate (50 or 59.94 fps) with a image quality depending on the bobber and settings used.

- for DVD (SDTV), one needs to re-interlace the full rate progressive video to interlaced, cause DVD (SDTV) only supports 23.976, 25.0, and 29.97 fps being progressive. higher framerates (50.0 and 59.94) can only be represented by using interlacing.

If you really want to preserve the progressive structur, you cansave it as 50 or 59.94 fps AVI with XViD, or as MPEG-2
or upscaled to 720p HDTV.

but expect the first both(AVI &the MPEG-2) being unusable in Standalone players.
720p HDTV will work in suited players.

also this stuff needs HUGE amounts of CPU time and a properly setted up system.

[magic144]

ok, so we're saying the output of a TDeint BOB is (with an interlaced NTSC source)
59.94 FRAMES per second progressive intermediary (where each frame in this intermediary directly corresponds to one of the source's fields)

now what exactly happens to these progressive frames in the ConvertFPS(50) command?

does this generate a 50 FRAMES per second progressive stream?
and if so, what is the relationship between each of these frames and the 59.94fps input frames?

sorry for the questions being in such small steps, I'm just trying to follow this through
because I then want to know how the SelectEvery() function knows which frames (or should I say fields?) to discard

I can understand how you could decide from the original 59.94fps set, because the FRAME sequence would be:

t1 b1 t2 b2 t3 b3 t4 b4

i.e. FRAME 1 is generated from top FIELD 1 from the source
frame 2 is generated from bottom field 1 from the source
frame 3 was generated from top field 2 from the source, etc...

SeparateFields would presumably then generate a 119.88 fields/sec stream

tt1 bt1 tb1 bb1 tt2 bt2 tb2 bb2, etc

i.e. the t1 FRAME has been split into 2 interlaced FIELDS tt1 & bt1, and so on)

then, with a cycle of 4 and choosing only elements 0 and 3, your outputs from SelectEvery() would be
tt1 bb1 tt2 bb2, etc, at 59.94 fields per second

thus the first field DIRECTLY corresponds to the first source frame's top field
the second field directly corresponds to the first source frame's bottom field, etc

and Weave would presumably give you something very much like the original source, denoting (or somehow flagging) that tt1 and bb1 together represent interlaced frame 1, tt2 and bb2 together represent interlaced frame 2, etc..., with an output stream that is now 29.97fps

OBVIOUSLY tt1 is NOT the same as the source's frame 1 top field, since it has gone through the Bobber!

but I'm wondering what the relationship between source (frames and fields) and output (frames and fields) is when the ConvertFPS() function is used, and how you can know to choose the 0th and 3rd elements as the output fields from this function?

[scharfis_brain]

after convertfps there is no direct relation between output and input anymore.
It is a completely NEW video.
also you need to resize for astandards conversion between480 and 576 lines.

convertfps and resize totallt alter the video so, you end up selecting totally different lines in sepfields().selevery().weave().

that's the reason, why we need to deinterlace the stuff in order to do a standards conversion.

[magic144]

Scharfis - thanks for your continued attention - I value your opinion:

do you agree with my points from the last post? particularly about the transitions in the process between fields and frames? am I talking sense?

I realize a new vertical res is req's to satisfy PAL, so I understand the reason for the LancsozResize
btw, what is Lancsoz4Resize - is that better in some way???

so then I guess my question becomes

why choose 0 and 3 (or 1 and 2) and not some other pairing for the SelectEvery call

it seems very arbitrary

and why all the concern about TFF or BFF at the point of choosing, if the fields/frames are so skewed from the original source by that time??? what is the difference?

like what would be the problem with choosing 0 and 1 for example???

After ConvertFPS(), is there still some top/bottom field ordering in the output - is it still a cycle of 4 then??

[Xesdeeni]

Think of it this way:

You get a 50 frame-per-second progressive video. Perhaps it's from an HD feed that you scale down to 576 lines.

How do you encode this for a standard PAL DVD?

1. You could discard every other frame and get 25 progressive frames. You can encode a DVD this way, although when it is played back, each frame will be separated into fields that are fed to a (normal) PAL TV (for a progressive player, things will be different, but let's keep focused on normal PAL TVs). But now you only have 25 individual positions of the objects in the video every second. Particularly for fast motion, like in sports, things will be jerky. This will be worse than if you had actually filmed with 25 frames per second, because the shutter speed will not have been designed for 25 fps, it will have been designed for the 50 fps, because that's what was filmed.

2. You can convert to 25 interlaced frames, which is the same as saying you create 50 fields from the 50 frames. You started with:T1 T2 T3 T4 T5
B1 B2 B3 B4 B5...So you could create your interlaced version in a variety of ways, the most obvious of which are:T1 T3 T5
B2 B4 ...or T2 T4
B1 B3 B5...As a result, you could have:T1 T3 T5
B2 B4 B6...which is top field first. This is because T1 is the top field of the first frame, and it comes from the first "instant of time" (i.e. the first progressive source frame), while B2 is the bottom field and comes from the second "instant of time." Alternatively, you could haveT2 T4 T6
B1 B3 B5...You should be able to see that this is bottom field first.

In this case, you'll get all 50 "instants of time" covered by your video, which is more fluid and matches the original shutter speed. And if things are not moving, you'll full vertical resolution. A good compromise

---

Now think of the source as a ConvertFPS(50)/ChangeFPS(50) result from a 59.94 fps progressive source. Then think of the 59.94 fps progressive source as coming from a 59.94 fps interlaced source that has been passed through a smart deinterlacer (something a bit better than a bobber).

Wait, I see something that might be confusing you. A bobber would interpolate between the lines of one field to create the lines of the other. And maybe you're wondering how you avoid using the interpolate lines instead of the actual source lines when you SelectEvery(). That's a good point for bobbers, but for smart deinterlacers, things are much better.

If there is no motion, then a smart deinterlacer will not interpolate to fill in the missing lines. It will instead borrow the lines from the fields before or after the supplied one. In this case, choosing any lines from this progressive frame with SelectEvery() will get genuine original lines.

OTOH, if things are in motion, there is interpolation. But it turns out that this interpolation isn't really all that bad. There are so many other artifacts floating around, and things are in motion after all, that the eye isn't as bothered by choosing interpolated things over originals in this case.

Maybe that's what you meant?

Xesdeeni

[magic144]

thanks guys

I think I get it!

you basically have to treat the output of the bobber/smart-deinterlacer as a whole new progressive stream - forget about the ORIGINAL fields and whether or not they were top or bottom

then interlace traditionally using the 0,3 selection (subsampling one from the top fieldset, one from the bottom fieldset to get the right field rate) for weaving into a TFF output interlaced stream

so is TDeint a smart deinterlacer? (in bob mode)
it does all the good things you said about borrowing lines where appropriate, Xesdeeni? hence the output looks so good?

and I'm hearing that we want to keep the output interlaced because we want to preserve the fluidity of motion from the original interlaced stream

thanks again guys - you helped my understanding out a lot

[Xesdeeni]

I think TDeint is a smart deinterlacer. Honestly I haven't used it. I ported Gunnar Thalin's Smoothdeinterlacer from VirtualDub to AVISynth and used that. Now I use LeakKernelBob, which is an MMX optimized version of KernelBob. There may be newer/faster/better ones, but I haven't had time (or the need) to work with this lately. Ideally, the motion compensated deinterlace work being experimented will get somewhere. But I didn't have much luck with it myself, so I gave up on it.

Xesdeeni

[a2j]

Xesdeeni, I've used yor script to convert NTSC DV to PAL DV from somewhere in this forum for quite a long time. The script is this:
=============================
loadPlugin ("c:\SmoothDeinterlacer.dll")
DirectShowSource("g:\03-04.avi",audio=false)
SeparateFields() # Correct for bug...
Weave() # ...in SmoothDeinterlacer
SmoothDeinterlace(doublerate=true)
ConvertFPS(50) # or ChangeFPS(50)
LanczosResize(720,576)
SeparateFields()
SelectEvery(4,0,3)
Weave()
=============================
And now all of the sudden on one of the files I need to process quite fast, the script gives me following: "Weave: Weave should be applied on field-based material: use AssumeFieldBased() beforehand (c:\ntsc_pal_script.avs, line 5)"

If I do it this way
=============================
loadPlugin ("c:\SmoothDeinterlacer.dll")
DirectShowSource("g:\03-04.avi",audio=false)
SeparateFields() # Correct for bug...
AssumeFieldBased()
Weave() # ...in SmoothDeinterlacer
SmoothDeinterlace(doublerate=true)
ConvertFPS(50) # or ChangeFPS(50)
LanczosResize(720,576)
SeparateFields()
SelectEvery(4,0,3)
Weave()
=============================
It gives me the same problem... Frankly speaking, I don't even know how the whole thing works - I just use it, so I can't fix it myself... Alas.

Please, give me some advice on how to get this working?.. Thank you.

[Wilbert]

@a2j,

Try this version: http://www.geocities.com/wilbertdijkhof/SmoothDeinterlacer_25.zip

[a2j]

Thank you - it did work!

[spanky123]

Thanks

I got a bit of a problem. I've just tried converting a 23.97 fps avi to 25fps PAL MPEG-2 with Procoder and the file length is different to the original by a few minutes

The output framerate is 25fps as I wanted and is dvd-compliant mpeg-2 pal but it seems like procoder has just used only the frames it had from the source, rather than blending them and adding an extra frame every second (I hope I've explained that clear)

How do I fix this in Procoder ? Is there an option anywhere ?

I know how to do it in the avisynth script with CCE, but I wanna do it in Procoder

[scharfis_brain]

procoders default setting is to speed up or slow down.

blending or duping whole frames will look terrible...

is you don't want to alter speed I recommend using dgpulldown to force a 23.976fps 720x576 MPEG file to 25 fps. fields getting duplicated during playback, then.

[manono]

How do I fix this in Procoder ?

If you're sure of what you said (the frame count is the same, just speeded up), then you can "reset" the speed by running the M2V through DGPulldown set for 23.976->25.000 as scharfi suggested. That way, the original speed will be retained, the video length will be the same as the original, you can use the same untouched audio (if already DVD compliant), you won't have a nasty blended or jerky playing result (not as jerky as having dupe frames inserted anyway), and it should be a nice and compliant PAL M2V, ready for authoring.

This has already been explained in your Videohelp.com thread. What, you didn't believe us? Needed a second opinion?

http://forum.videohelp.com/viewtopic.php?t=315461

[spanky123]

Thanks. All clear with the DGPulldown I think

This has already been explained in your Videohelp.com thread. What, you didn't believe us? Needed a second opinion?

http://forum.videohelp.com/viewtopic.php?t=315461

Well actually, if you check the times of my posts, you'll see that I made this post before the VideoHelp one.

:)

:thanks:

[manono]

Not the way I read them, you didn't. But that's OK, as long as you got it sorted out.

[spanky123]

Not the way I read them, you didn't. But that's OK, as long as you got it sorted out.

You might have the timezone set wrong in either videohelp or here.

Anyways. .. Yeah I think it's all sorted. I just gotta try a few
Thanks for the help

[Maiko Herajin]

I have a question about the normal standards conversion script that has been given on here, maybe someone can explain it to me.

I have this script currently running (in my case going from PAL to NTSC)


MPEG2Source("whatever.d2v", iPP=True)
AssumeTFF()

securebob()
lanczos4resize(width, 480)
convertFPS(59.94)
separatefields().selectevery(4,0,3).weave()

Now from what I gather, what we're doing is smart bobing the video so it's 50p, in order to preserve any "fast motion" that might occur. Then we resize it, change the FPS, and then... split and double the video again, weaving together every fourth and eigth frame?

What I'm not sure I understand is why the deinterlacing step is nessisary in the first place. Why wouldn't code like this work?


separateFields()
lanczos4resize(width, 240)
ConvertFPS(59.94)
selectevery(2,0,1).weave()

Since the first line basically creates a 720x288x50p, which is later weaved back, becoming half of a 720x480x29.97i video, I don't see where any loss of detail would occur. I tested the script on a DVD rip, and sure enough, I got a video that was 720x480x29.97. I didn't actually process the video, however, because I figured you guys were all smarter than me. :D

So what process does the first script preserve / improve over the second (much faster) script? Am I misunderstanding something in the process here?

[foxyshadis]

Well, the weave is wrong (should be 4,0,3 unless you want selecteven), but on trickier topics:

The pixels aren't centered. The resize assumes that the top and bottom are absolute, but when you weave that assumption is invalid. That means a picture that was perfectly stable before, will have a slight up-and-down jitter after resizing. (A correct subpixel crop might fix that.) There's also a little bleed between lines within fields that wasn't there before, that could cause combing in static areas where none was before.

Although that's the theory, I don't find it very visible. Give it a try and see if you notice.

[Brent212]

Why is it that in Xesdeeni's conversion scripts (here (http://www.geocities.com/xesdeeni2001/StandardsConversion/#PALVideoDVD2NTSCDVD)), the ConvertToRGB() doesn't contain "interlaced=true"? From what I've read, this parameter defaults to false, which seems bad because I thought the video is interlaced at the end of the script. I'm mainly looking at the "PAL video DVD (25i FPS) --> NTSC DVD (29i FPS)" script, since I want to try using that as input to TMPGEnc.

[Xesdeeni]

Probably because he screwed up and doesn't use TMPGEnc enough to have noticed himself. ;-)

Xesdeeni

[kOoL tHuG]

But how to convert Pal (25) Menus to
NTSC (29.97) huh frnds?

[cweb]

[QUOTE=kOoL tHuG;1119647]But how to convert Pal (25) Menus to
NTSC (29.97) huh frnds?[/QUOTE
Recreate a similar or different menu..