Standards Conversion Script (PAL<->NTSC)

[Xesdeeni]

######################################################################
#
# Poor man's video standards conversion (NTSC to PAL and PAL to NTSC)
#
# This script converts one INTERLACED video format to another
# INTERLACED video format.
#
# NOTE: This script is NOT meant to convert telecined films (that is,
# films that have been transferred to video). There are much better
# ways to convert that type of content (see the guides at
# www.doom9.net and www.vcdhelp.com). This script is best for
# INTERLACED content like HOME MOVIES shot with camcorders or live
# events. It is also good for mixed content (film + video).
#
#---------------------------------------------------------------------
#
# >>> Tools <<<
#
# This script is for use with AVISynth version 2.0.6 or above,
# available from http://www.avisynth.org.
#
# This script uses my AVISynth port of Gunnar Thalin's smooth
# deinterlacer, which is available at
# http://home.bip.net/gunnart/video/AVSPorts/SmoothDeinterlacer/.
# Place the plugin in an AVISynth plugin directory, so it can be
# accessed below.
#
#---------------------------------------------------------------------
#
# For comments/suggestions email me (Xesdeeni2001) at Yahoo dot com.
#
######################################################################
#
# >>> How It Works <<<
#
# This script works by first converting the input video from
# interlaced fields to progressive frames using an adaptive
# deinterlacer. Then the progressive frame rate is converted.
# Finally the progressive frames re-interlaced for output. Scaling
# is also performed where appropriate.
#
######################################################################
#
# >>> To Use <<<
#
# To use this script, first modify the lines below as specified.
# Then save the script with any name ending in .AVS.
#
#---------------------------------------------------------------------
#
# Set PluginPath equal to the path for your AVISynth plugins. Be sure
# to end the path with a backslash. Note that if you put the plugins
# in the system directory, you can leave this path completely empty.
# ex.:
# PluginPath = "C:\AVISynth\PlugIns\"
#

PluginPath = ""

#---------------------------------------------------------------------
#
# Set Input equal to the load directive for the input file. Also add
# any plugins necessary to load the video file. Note that if the clip
# contains audio, it is fed straight through without being modified,
# because the output video will have the same length as the input
# video.
# ex.:
# LoadPlugin(PluginPath + "MPEG2DEC.dll")
# Input = MPEG2Source("Input.mpg")
#

Input = AVISource("E:\temp\LiveTest.avi")

#---------------------------------------------------------------------
#
# Set InputTopFieldFirst to either true or false, depending on the
# format of your input file. DV files are normally bottom field
# first, so set this value to false. DVDs and most other sources are
# normally top field first, so set this value to true.
#

InputTopFieldFirst = false

#---------------------------------------------------------------------
#
# Set OutputFrameRate to the desired frame rate of your output video.
# For PAL, this is normally 25. For NTSC, this is normally 29.97.
# The input frame rate is derived directly from the input video.
#

OutputFrameRate = 25

#---------------------------------------------------------------------
#
# Set the OutputWidth and OutputHeight to the desired width and
# height of your output video. In most cases, the width of the
# output should match the width of the input. For PAL, the height
# is normally 576. For NTSC, the height is normally 480. The input
# width and height are derived from the input video.
#

OutputWidth = Input.width
OutputHeight = 576

#---------------------------------------------------------------------
#
# Set OutputTopFieldFirst to either true or false, depending on the
# desired format of your output file. See InputTopFieldFirst above.
#

OutputTopFieldFirst = true

#---------------------------------------------------------------------
#
# Set ConversionType to your desired type of frame rate conversion.
# The choices are:
# 0 - Replication/Decimation: Frames are repeated to increase the
# frame rate; frames are dropped to decrease the frame rate.
# This type of conversion is the fastest, but may show visible
# stuttering on motion when decreasing the frame rate (i.e.
# NTSC to PAL).
# 1 - Temporally Interpolate: Output frames are created by
# temporally interpolating between adjacent input frames. This
# type of conversion can show a "jutter" effect on motion, but
# is best when decreasing the framerate to ensure every input
# frame is at least partially shown in the output.
# 2 - Asynchronous: The conversion is done by showing the
# portions of the input frames that correspond to the time
# during which the output frame is visible. When decreasing
# the frame rate, this can cause some areas of some frames to
# never be seen, and can cause "broken" vertical edges on
# horizontal pans.
#

ConversionType = (OutputFrameRate <= Input.framerate) ? 1 : 0

#
######################################################################

LoadPlugin(PluginPath + "SmoothDeinterlacer.dll")

vpro = Input.SmoothDeinterlace(tff=InputTopFieldFirst, \
doublerate=true)
vinfps = Input.framerate < OutputFrameRate ? \
vpro.BilinearResize(OutputWidth, OutputHeight) : \
vpro
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)
# The ConvertToRGB() below is to work around a problem with the YUV to
# RGB conversion caused by a bug in one of the Microsoft DLLs. The
# bug makes the colors look bad. Your destination may bypass this
# conversion, so you may be able to remove this conversion in some
# cases.
vout = vlace.Weave().ConvertToRGB()
return(vout)


Xesdeeni

[Edit: Modified to fix the audio.]

[Guest]

Does Xesdeeni == Gunnar Thalin? :)

[Si]

Does Xesdeeni == Gunnar Thalin? :)

If it is then (looking at the Smooth Deinterlacer page) I think he/they have a serious split-personality problem :p :)

Simon

[Gribley]

Xesdeeni,

I`ve been using the simple example from the Avisynth help files (under convertFPS syntax).... this is working fine for me NTSC->PAL and seems much simpler.
This sounds bad, (but it is not intended that way), but does you script offer anything that would make it worth me re-encoding for?

Cheers
Grib

[Guest]

Originally posted by siwalters


If it is then (looking at the Smooth Deinterlacer page) I think he/they have a serious split-personality problem :p :)

Simon Well, xesdeeni apparently does, based on the comments in the script. :)

When I posted that I was at work where my proxy denied me access to the page, so I couldn't look at that time. Really, I'm not an idiot. :)

[Xesdeeni]

Gribley--
If you are satisfied with the results using Bob(), then there is no reason to take the extra time to use the above method. However, you will note on still scenes or static graphics that the image will...well, bob up and down. The above technique will look better overall, and it more nearly matches the professional conversion devices.

Xesdeeni

[Xesdeeni]

Here is an example of what I mean. This is from a the first season of a BBC sitcom called Porridge. The show takes place in prison, and this is a piece of a scene showing the mugshot of one of the main characters. The top half was converted using the Bob() method from the AVISynth documentation. The bottom half is exactly the same part of the same frames using the method outlined above.

Xesdeeni

[edit] All right. What's the trick to posting an attachment!? It showed up when I posted, and as I'm editing, it shows up below as well ("Keep current attachment"). Oh, it's a zip file that is less than 200K.

[sh0dan]

Your attachment has to be approved by a moderator, before it'll show up - relax - neuron will probably come back soon. :cool:

[Guest]

Sweet! It looks like I can stop my work on my Avisynth Smart Bob. :)

Xesdeeni, you should make a thread announcing your port of the Deinterlace Smooth. Or have you done that already and I missed it?

Great work, you and Gunnar.

[sh0dan]

Just tested.

You rock, Xesdeeni - what an excellent filter - really, really cool!

edit: Whoops - tested a bit more:

crop(16,16,-16,-16)
smoothdeinterlace(doublerate=true)

Does this result look familiar? ;) (If not, just ask Donald :D)

[sh0dan]

Another problem - when using "doublerate=true", my video is always jerky, regardless of using 'tff=true' or 'tff=false'. The source is 25fps PAL DV-source, so it should be ok using 'tff=false'.
I've uploaded a testclip - a pan, where the effect is very visible. Get it here. (http://cultact-server.novi.dk/kpo/avisynth/bob-prob.avi). I cropped the source, and it's XVID compressed (with latest interlace bug-fix), but the effect is still very visible. My script:

avisource("bob-prob.avi")
smoothdeinterlace(doublerate=true,tff=false)


Another thing is, that you can request default parity from Avisynth, by using clip.GetParity() - it will in most cases return the correct field order. Otherwise assumetff() or assumebff() can be used in the script.

[Guest]

@sh0dan

The latest Xvid binary from Koepi's page won't play your file. It goes macroblock crazy and disintegrates into garbage. Please, where do I get the Xvid version that will play it? Thank you.

[sh0dan]

I can see Interlacing still has problems in XVID (the I cannot get the latest filters to make a properly interlaced clip, or at least have them decompress them correctly again).

I put up a quant 2 interlaced clip, encoded as non-interlaced - just redownload. It still displays the artifacts very good. I almost think I'm doing something wrong?

[Gribley]

Xesdeeni,

Thanks for taking the time to explain it so well.... next standards conversion I try I`ll use your script and see the difference for myself :)

Thanks
Grib

[Guest]

Originally posted by sh0dan
Another problem - when using "doublerate=true", my video is always jerky, regardless of using 'tff=true' or 'tff=false'. The source is 25fps PAL DV-source, so it should be ok using 'tff=false'.I don't know why the tff option isn't working as described in the help file, but you can make it work by putting ComplementParity() before the call to the filter.

[sh0dan]

ok - thanks - tried swapfields(), but that didn't help either.

[Xesdeeni]

Hmmm. That was an interesting one. The clip in question misreports its polarity (it says it's bottom field first, but it's actually top field first--notice that Bob() also has a problem with it that is fixed with AssumeTFF()). I wouldn't have thought that this would matter, since I had an explicit "tff" parameter. But unbeknownst to me, the internal DoubleWeave() filter uses the reported polarity. So regardless of what I did with the data, I was getting bad DoubleWeave()d frames.

It took me a while to figure that one out. And it took even longer to figure out how to smoothly fix it. But anyway, I've combined the fix with the suggestion from sh0dan, and now the filter can use the reported polarity instead of requiring it explicitly.

Of course, for the clip above, sh0dan would still have to explicitly give the tff=true argument. :rolleyes:

[Since I'm relying on the kindness of Gunnar Thalin to host the filter, and I've sent the update to him literally seconds ago, it may be a bit before version 1.2 shows up. BTW, thank Gunnar!]

Xesdeeni

[Xesdeeni]

I've updated the script above to fix a problem with the audio.

Xesdeeni

[sh0dan]

Did you fix the crop (pitch) problem?

[Wilbert]

@Sh0dan,

About the audio ...

I saw that you added a new function called AssumeSampleRate. Isn't it possible to convert the audio in the following way:

# source: the wav-file (48 kHz):
# 48000*25/23.976 = 50050 (similar as SSRC.exe):
ResampleAudio(50500)

# "change the header back" (similar as Wavefix.exe ?):
AssumeSampleRate(48000)

Is that the "best" way for converting the audio (it should work, although I haven't tried it yet)?

[sh0dan]

Should work ok, just try it :)

[Xesdeeni]

sh0dan, I hope you beta test for a living :D When Gunnar gets the time, version 1.3 will be up.

Xesdeeni

[sh0dan]

No - I'm just very unlucky :D

[Wilbert]

Regarding to the audio part of PAL(25)-->FILM(24) conversions. I tried the following:
_____
video = AviSource("F:\Nieuw3\atomic_kitten-the_tide_is_high.avi", false).ConvertToYUY2.Telecide
audio = WavSource("F:\Nieuw3\atomic_kitten-the_tide_is_high.avi")

# source: 44.1 kHz
# slowed down to 44100 * 25/24 = 45937.50000 = 45938

audio = audio.ResampleAudio(45938).AssumeSampleRate(44100)
video = video.AssumeFps(24)

AudioDub(video, audio)
_____

That worked, and sounded good! But a warning: If you open this AVS in VDub and your recompress the video and audio at the same time it doesn't work (video comes out with a framerate of say 15). It worked when saving video and audio as uncompressed. If you don't want to, you will have to recompress the video and audio separately and remux them.

Of course when going for mpeg1/mpeg2 you shouldn't have this problem.

[sh0dan]

Originally posted by Wilbert
But a warning: If you open this AVS in VDub and your recompress the video and audio at the same time it doesn't work (video comes out with a framerate of say 15). It worked when saving video and audio as uncompressed. If you don't want to, you will have to recompress the video and audio separately and remux them.

I'm not sure I understand the probelm you mention - how could this be a problem?

Note to all: You need 2.06+ for assumesamplerate to work, download from the URL below.

[Wilbert]

I don't know exactly what the problem is. Maybe you could try it too and see what happens.

If I load the avs file in VDub, set the video to Huffyuv and the audio to full processing (also tried direct stream copy) and save it as an avi. The resulting avi doesn't play smooth (it skippes frames), WMP6.4 plays it with a framerate between 10 and 15 fps instead of 24.

Maybe it has something to do with the interleave settings (although I didn't change that). Maybe something else. I have no idea. Let me know if you need more info.

[sh0dan]

Could it be your computer having a hard time following up?

How does it play if you compress to XVid for instance?

[Wilbert]

Could it be your computer having a hard time following up?
Could be. I have an Athlon 1.2 GHz. Maybe other people can try this and report here?
How does it play if you compress to XVid for instance?
I will try that if I have some time this weekend. (Never used Xvid, but I have to learn that anyway some day :))

[Wilbert]

Little update. It worked fine when encoding to Xvid or DivX. I don't understand. Does it take much more CPU power to encode with Huffyuv?

[sh0dan]

The main problem is, that HuffYUV isn't a DirectShow filter, and therefore is doesn't use overlay as good as Xvid for instance.

En/Decoding in Vdub will most probably be much faster when using huffyuv, but playback most often isn't.

[Boulder]

Based on my experiences, Huffy is rather slow when decoding. I suppose that it chokes the HD pretty easily. For example, when encoding a Huffyuv capture to MPEG-2 with CCE, the speed is from 0.5 to 0.6 real time on my machine (TB1400) whereas an MJPEG capture goes at about 0.95RT.

[Aktan]

If you use ffdshow and set it to play "Raw video", huffyuv decoding goes a LOT faster cause then its in yuy2 mode. (I dunno why this happens it just works for me :) ) (Also might be cause i encode to yuy2 mode in huff too, dunno...)

[cbwarz]

Hi,

i little late but maybe can help me :D

I'm looking for a pure NTSC 29.97 -> FILM 23.976 convertion process.

Can this be used for?
Or can help me find a "better" method?

Thanks

[Guest]

Tell me two things:

1. You've read all the FAQs and done appropriate searches.

2. Your NTSC footage is telecined progressive material (you can't usefully convert it to "FILM" if it isn't).

if (!1) read_faqs_and_search;
else if (!2) forget_it;
else use_Decomb;

[scmccarthy]

@Wilbert

video=video.ResampleAudio(44100).AssumeFPS(24,true) You know that true will automatically adjust the samplerate of the audio to keep it in sync?

Once the samplerate has been changed, it will not compress to mp3 using VirtualDub. The samplerate must be 32 or 44.1 or 48. Maybe this was the problem you were experiencing.

Stephen

[Wilbert]

You know that true will automatically adjust the samplerate of the audio to keep it in sync?
Yes, I know. Where did I say the line you quoted ?

[cbwarz]

@neuron2

yes, i have read the FAQ and many forums looking for pure NTSC to FILM.

Think your algorithm is wrong
>if (!1) read_faqs_and_search;
>else if (!2) forget_it;
>else use_Decomb;

if (ask==2) forget_it; (:D don't get mad)

That's why i asked here, i read somewhere that pure NSTC "can" be converted to FILM if you don't care with some interlaced artifacts appear IN ACTION PARTS. Of course i'm not an expert, but have some read. If NSTC->PAL is 59.94->50 why not NTSC->FILM = 59.94->47.952, is just 3 fps less, of course is interlaced but is a start i think :). Can you explain me why 3fps makes a different please.

I have tried decomb and in slow action parts is very good, but in moved is jumpy (like drop frame), then i search and search and still looking for a plugin that can do this.

Thanks
And keep the good work :)

[Xesdeeni]

See what you think. If you use ChangeFPS(), you can just use something like this:LoadPlugin("SmoothDeinterlacer.dll")
AVISource("NTSC.avi")
SmoothDeinterlace(doublerate=true)
ChangeFPS(24)But if you think you need ConvertFPS(), you'll need to break it into two pieces because of a limit in ConvertFPS() and do something like this:LoadPlugin("SmoothDeinterlacer.dll")
AVISource("NTSC.avi")
SmoothDeinterlace(doublerate=true)
ChangeFPS(48)
ConvertFPS(24)Let us know what you think of the results.
Xesdeeni

[scmccarthy]

Yes, I know. Where did I say the line you quoted ? That is not a quote, it is my own code. To be used on place of:

audio = audio.ResampleAudio(45938).AssumeSampleRate(44100)
video = video.AssumeFps(24)

My code is not quite right, though. If AssumFPS is used after AudioDub, it can be used to calculate what the new samplerate needs to be.

Then resample the audio back to a standard sample rate. That is what ResampleAudio does is it not?

Stephen

[MrBunny]

@cbwarz

In a pure NTSC -> PAL transfer, generally (on a good transfer), they don't drop frames to change the framerate from 29.97 to 25 fps, they just slow it down so there's the same number of frames, but at the slower fps (and thus longer runtime).

You can convert from 29.97fps to 23.976 fps in the same way without a problem, execpt maybe things seeming slower, I'm not sure how noticeable it would be. You could just do it with changefps(23.976). There is no real advantage to this, as you're encoding the exact same number of frames.

However with your original post, it seemed like you wanted to convert your NTSC material to FILM using IVTC, so keeping the runtime the same and dropping 1/5 frames. This of course will cause jerkiness since you're missing every fifth frame. 29.97fps -> 23.976fps in that manner has been discussed many times, and neuron2 is right that you'd be able to find the infomation by searching.

Mr. B

[cbwarz]

@MrBunny

Hi :D

From SmoothDeinterlace.txt
--------------------------------------------
NOTE 1: These scripts are meant to convert truly interlaced (or hybrid) video.
***************** Example
# NTSC DVD (59.94 fps) to PAL DVD (50 fps)
LoadPlugin("SmoothDeinterlacer.dll")
LoadPlugin(PluginPath + "MPEG2DEC.dll")
InputVideo = MPEG2Source("NTSCDVD.d2v")
SmoothDeinterlace(tff=true, doublerate=true)
BilinearResize(720, 576)
ConvertFPS(50)
SeparateFields()
SelectEvery(4, 1, 2)
--------------------------------------------

Maybe i'm wrong, but this script does drop frames or not?.


@Xesdeeni

Thanks, will try that.
I see your examples from SmoothDeinterlace.txt
To do a NTSC->FILM what to put on SelectEvery(4, 1, 2)?
Or is the same like ChangeFPS(48) ConvertFPS(24)?
>ConvertFPS(48)
>SeparateFields()
>SelectEvery(4, 1, 2)

Thanks

[MrBunny]

Originally posted by cbwarz


From SmoothDeinterlace.txt
--------------------------------------------
NOTE 1: These scripts are meant to convert truly interlaced (or hybrid) video.
***************** Example
# NTSC DVD (59.94 fps) to PAL DVD (50 fps)
LoadPlugin("SmoothDeinterlacer.dll")
LoadPlugin(PluginPath + "MPEG2DEC.dll")
InputVideo = MPEG2Source("NTSCDVD.d2v")
SmoothDeinterlace(tff=true, doublerate=true)
BilinearResize(720, 576)
ConvertFPS(50)
SeparateFields()
SelectEvery(4, 1, 2)
--------------------------------------------

Maybe i'm wrong, but this script does drop frames or not?.


From what I understand of that code, you're depending on convertfps() to do most of the work. From the avisynth docs on that function:
"The filter attempts to convert the frame rate of clip to new_rate without dropping or inserting frames, providing a smooth conversion with results similar to those of standalone converter boxes. The output will have (almost) the same duration as clip, but the number of frames will change proportional to the ratio of target and source frame rates."

I can't say I understand exactly how that works, but instead of dropped frames, you'd have blended frames. It seems to me that changefps will attempt to cover up the fact that there are less frames by blurring motion, in order to make it look smooth. This should do what you want, but it isn't perfect. Neuron2 was working on a similar method in his mode=3 decimate (in one of the TNG DVD threads), and the result was far from perfect, but decent enough. Feel free to try, if you're happy with it, then I'm happy :)

Mr. B

[cbwarz]

@MrBunny

Hi, like i said in a previous post, i can live with some intelaced artifacts, that's ok.

From your post, now i think I wasn't fair saying decomb was "jumpy" (frame dropping) cause i didn't know about mode=3, i use avisynth 2.0.7. But i guess is time to upgrade :)

Will try all of them hehe :D

[MrBunny]

@cbwarz

You shouldn't have to live with interlacing, even if you're willing to ;) If there is some, just throw another deinterlacer on it.
As for saying decomb is jumpy, if telecide and decimate are working properly, it SHOULD be jumpy when it tries to IVTC a pure NTSC stream since there are no "correct" frames for decimate to be dropping.

Mr. B

[scmccarthy]

@cbwarz

MrBunny is correct, it should be jumpy when you try to IVTC and non-telecined source. (And I am not forgetting that neuron2 already said the same thing.) Telecining adds duplicate fields that later need to be decimated in IVTC. IVTC stands for inverse telecine you know. PAL and NTSC video are not telecined and cannot be IVTC'd. An attempt to do it will drop non-duplicate frames and thereby cause jumpiness. On the other hand, there is an argument for applying IVTC to everything if you don't mind dropping non-duplicate frames. By doing so, you are reducing the size of your video and making it easier to compress.

That is what confuses me about what you are saying. At first I thought you meant you intended to use IVTC just to have less frames to compress. That would make what you have been saying seem almost reasonable, except then you cannot then complain that you get frame dropping. That complaint reveals that you don't know what IVTC really is. A PAL or video source cannot have one duplicate frame in every five as you have with a telecined source after it is deinterlaced. (Technically, you have 2 duplicate *fields* in every ten before deinterlacing.)

It is frustrating to have you champion the use of IVTC for everything without really understanding it.

Stephen

[Wilbert]

That is not a quote, it is my own code. To be used on place of:

audio = audio.ResampleAudio(45938).AssumeSampleRate(44100)
video = video.AssumeFps(24)

My code is not quite right, though. If AssumFPS is used after AudioDub, it can be used to calculate what the new samplerate needs to be.

Then resample the audio back to a standard sample rate. That is what ResampleAudio does is it not?

iow:

AudioDub(video,audio).AssumeFPS(24,sync_audio=true).ResampleAudio(44100)

Sorry I misunderstood you. Yes you are right. However we experienced problems with both scripts.

[Xesdeeni]

@MrBunnyIn a pure NTSC -> PAL transfer, generally (on a good transfer), they don't drop frames to change the framerate from 29.97 to 25 fps, they just slow it down so there's the same number of frames, but at the slower fps (and thus longer runtime).I think you have confused conversion of telecined film with conversion of native interlaced video. When converting film that has been telecined for NTSC, the process is normally to reconstruct the original frames via an inverse telecine (IVTC) process, resulting in 23.976 Fps (note that this is not the same thing as deinterlacing; in deinterlacing the extra lines have to be made up; in IVTC the extra lines are actually reclaimed from video). Then this is sped up to 25 Fps to convert the "NTSC film" to PAL. When converting from PAL video that started as film, the pairs of fields in the 25 interlaced Fps is reconstructed to 25 progressive Fps. This is then slowed to 23.976 and telecined to NTSC.

For actual interlaced video, these techniques don't look good at all. There is not basic frame from which to reconstruct, so a different process is normally used.


For these simple converters, the first step is usually to create a set of progressive frames. This is because the vertical resolution of PAL and NTSC are different, so some scaling must be done. If you've ever done any scaling of interlaced video, you will have seen that it just doesn't seem to look very good. But if you start with a progressive frame, scale it, and then interlace it, it looks much much better.

Using NTSC as a source, one way would be to create 29.97 progressive Fps from the initial 29.97 interlaced Fps. But this will lose some temporal information, because every other field may be disregarded completely, depending on the amount of motion and the deinterlacing algorithm. If you then convert the 29.97 progressive Fps to 25 progressive Fps, you'll have to throw out (or interpolate out...see below) one full frame every 6 frames (yes, you could slow the video down to 25 Fps, but if you try this you'll see it looks absolutely ridiculous). This causes a 1/25 sec glitch, which most people will notice.

On the other hand, if you instead convert your 29.97 interlaced Fps to 59.94 progressive Fps, you don't lose any temporal information. You are making up some info in some cases, but if your deinterlacer is smart, for shots will little motion, the information can come from adjacent fields, so the missing lines are restored from actual information rather than made up.

So now we convert from 59.94 progressive Fps to 50 progressive Fps. Again, we are throwing out one full frame every 6 frames, but now we will cause only 1/50 sec glitch, because we have twice as many frames at this intermediate point of the conversion. After scaling, we select the even lines from one frame and the odd lines from the next to convert to 25 interlaced Fps.

It turns out that this 1/50 sec glitch is nowhere near as visible as the 1/25 sec glitch above. Plus we don't throw out half of our temporal information in the first step, so this is almost the only conversion artifact (the deinterlacing and scaling introduce some more subtle ones as well).

Throwing out the frame is accomplished via ChangeFPS() in my script. If you instead use ConvertFPS(), AVISynth will interpolate the frames in an attempt to smooth out the video better than just dropping the frame. But this causes some "jutter" artifacts. For PAL to NTSC, I find that I prefer the ChangeFPS() frame dropping. I seldom if ever notice the stutter caused by a replicated "instant of time" (replicated as a frame during processing, but spread across two fields in the output), while I almost always see the interpolation jutter. Unfortunately, I don't have access to PAL equipment, so I can't speak for the frame/field dropping when going NTSC to PAL. That's why I always give both choices.

Xesdeeni

[scmccarthy]

@wilbertAudioDub(video,audio).AssumeFPS(24,sync_audio=true).ResampleAudio(44100) Instead of testing whether that works in VirtualDub, I used besweet to resample the audio after I realized that 48.048 can't be compressed into mp3. Meanwhile, I assumed that was the solution. So I really should try it.

Stephen

P.S., the 48.048 is from 23.976->24 to restore my movies to exactly the right frame rate while retaining audio sync.

[scmccarthy]

@XesdeeniFor these simple converters, the first step is usually to create a set of progressive frames. This is because the vertical resolution of PAL and NTSC are different, so some scaling must be done. If you've ever done any scaling of interlaced video, you will have seen that it just doesn't seem to look very good. But if you start with a progressive frame, scale it, and then interlace it, it looks much much better. This is very complicated, but separating this one part of it, you don't have to convert to true progressive frames to resize. You can instead use Simon Walters ViewFields, then resize, and use UnViewFields. Stacking the fields on top of one another is enough to let you process the frames as progressive.

This avoids having to choose between converting to 29.97 or 59.94 progressive; neither option is acceptable. Either way, frames will have to be dropped to convert to PAL anyway. Or dropping one field from a frame and the opposite field from the next frame might reduce the jitter a little. That is, after the resize, you have the same choice between ChangeFPS and ConvertFPS as before.

Stephen

[Xesdeeni]

@scmccarthy

Well, I'm going to go through why using ViewFields (or Deinterlace in VirtualDub or SeparateFields() in AVISynth, which are all the same thing) and then scaling won't look as good as the technique using a deinterlacer that I describe, but without actual images, it might be hard to convince you. I'm afraid I don't have the time right this minute to create a comparison video for you, but if you have the opportunity yourself, I would recommend that you test it on your end using the same test video. Use video with motion and video with none (or better yet, maybe a static shot with someone running through it). If I can find some time in the next week or so, I'll try to find some test video and create the comparison myself, but you'll probably believe it better if you see the process yourself.

The Long Involved Explanation

When you separate the fields using ViewFields, you have effectively created 59.94 half-height progressive Fps. The one caveat is that each of these "frames" is actually shifted from the ones before and after it by 1/2 line vertically. This is most obvious if you use AVISynth's SeparateFields() filter and view the half-height fields. But if you were to view the side-by-side or stacked fields in VirtualDub sequentially, viewing first the top/left and then the bottom/right before moving to the next frame, you'd see that the image appears to "bob" up and down.

I shouldn't have to go much further with this method for you to see that if you then scale these fields, the "bobbing" doesn't go away. And the effect will still be visible after you've finished your conversion. In fact, it will be really strange because the relationship between the original fields and their bob rate will be out of sync with the fields in the destination, causing a 5 or 6 Hz cycle of Bob that will really be annoying.

To help with this "bobbing" phenomena, a technique called "Bob" (probably should have been called anti-Bob) was introduced (I first heard about this from Microsoft in 1995 with regards to DirectDraw display on a progressive PC of interlaced video, but I wouldn't want to credit them, since I'm not sure whether they invented the idea or "borrowed" it. ;) Oh, and don't confuse this with that other thing Microsoft had called "Bob." It was already pretty much dead by that time. ). It attempted to correct for the "bobbing." And in an added bit of bad pun, the process of just putting two successive fields together and viewing them at the same time (showing interlacing lines on a progressive PC) was called Weave, so that the whole thing could be referred to as "Bob and Weave" (ugh!).

VirtualDub and AVISynth both have something called "Bob," but although these filters have the same name, they don't operate in the same way. In fact, I'm not sure what VirtualDub's "field bob" actually does, since VirtualDub cannot adjust the frame rate with a filter.

The reason is that to do anything useful, basic Bob() actually creates 59.94 progressive frames from the interlaced source. But instead of stopping at what SeparateFields() does, they do two more things. First, they scale the image back up to full height, so that everything doesn't look short and squashed. Second, they adjust the method they use for scaling to alternately shift the resulting images and remove the "bobbing."

This works remarkably well on a PC in most instances. And most important, PCs, even in 1995, could do this operation using the hardware scalers in the VGA chips, so it could be done in real time. So when you viewed live TV, which was the reason for "Bob" in the first place, you didn't have to look at the interlacing lines.

The only problem with Bob is that it's still not quite there. For video that isn't moving, Bob adds its own artifact. In this case, I'll try to use a diagram. Here are a few lines from an interlaced video frame of a scene that is not moving at all in Weave and Bob representation (remember, although the lines in Weave are drawn together, the even and odd lines actually occur at different times): Weave Bob 0 Bob 1

B B B B G G
B B G G G G B B
B B B B G GG G
BB G G BBB = black, G = gray, and nothing = white

Bob creates Bob 0 and Bob 1 by interpolation of the current field, in this case I've simulated binlinear interpolation, but bicubic interpolation will only help minimally. The thing to note is that on a completely static scene, the viewer will see the display alternate between Bob 0 and Bob 1. There will definitely be visible flickering. In this case, the Weave version would look much better.

But then if the image starts to move, Weave won't look good and the Bob versions would be better.

So in comes "Smart Bob" and a whole host of other "smart" deinterlacers. They basically all use some type of algorithm to try to figure out whether there is any motion between fields. If there is not, then they use the Weave method for that area. If there is, then they use the Bob method. The algorithms vary, but that's basically what all of them are trying to do.

All of this is done to squeezed out as much information as we possibly can from the original video. We've effectively doubled the vertical resolution for each field or doubled the temporal resolution for each frame (depending on your perspective). In the worst case, we're never any worse than Bob or Weave, and hopefully we're better than both. All of that information can now be used to do a better job of converting between standards. We have a full height frame to scale, giving us better quality than if we only used one field. And we have twice as many frames to work with, giving us a potentially smoother motion in the result.

Whew! Maybe I'd have taken less time to create the test video instead :), but I hope this explanation helps.

Xesdeeni

[scmccarthy]

@Xesdeeni

Two things:Well, I'm going to go through why using ViewFields (or Deinterlace in VirtualDub or SeparateFields() in AVISynth, which are all the same thing) Try using ViewFields. I does not do the same thing as SeparateFields.

2) Using the method I suggested will let you resize the frames without deinterlacing. You stated that you need to deinterlace in order to resize and I am offering a way around that restriction.

It does not have to be deinterlaced if you reencode it back to DVD and watch it on a TV.

I know what bobbing is already, but it converts the video to progressive.The thing to note is that on a completely static scene, the viewer will see the display alternate between Bob 0 and Bob 1. There will definitely be visible flickering. The correct word for this is shimmering, not flickering. I know this because I speak english as my primary language.

Stephen

[scmccarthy]

@Xexdeeni

I went back to the top of the thread in case I was off base in my 'just leave it interlaced' assumption and this is what I found:# This script converts one INTERLACED video format to another. So that's clear.When you separate the fields using ViewFields, you have effectively created 59.94 half-height progressive Fps. When you use ViewFields you get frames that are the same size at the same speed, but they are no longer interlaced. UnViewFields effectively reinterlaces them. If between the two you resized from 720x480 to 720x576, you'd end up with PAL at 30fps.Whew! Maybe I'd have taken less time to create the test video instead , but I hope this explanation helps. That would be fine, except I don't understand what BOB has to do with NTSC<->PAL conversions.

Stephen

P.S., I copied the avs script while I was at it. Thank-you.

[Xesdeeni]

@scmccarthy Try using ViewFields. I does not do the same thing as SeparateFields.From the perspective of scaling, it does. ViewFields separates the two fields, putting one at the top and one at the bottom. The built in Deinterlace filter in VirtualDub does the same thing, except it places the two fields side-by-side. But both of these operate this way because you can't change the frame rate using a filter in VirtualDub. AVISynth can do so, so SeparateFields() is an equivalent function.

Set your VirtualDub filter chain for a 720x480 input to:ViewFields
Resize (360 x 240, Bicubic)
UnViewFieldsCompare this to in VirtualDub:Deinterlace (unfold)
Resize (720 x 120, Bicubic)
Deinterlace (fold)Then compare to an AVIScript with the following:SeparateFields()
BicubicResize(360,120,b=0,c=0.75)
Weave()You'll see that the results are all the same.2) Using the method I suggested will let you resize the frames without deinterlacing. You stated that you need to deinterlace in order to resize and I am offering a way around that restriction.However, rescaling isn't the only operation that is going on in standards conversion. You are also making temporal changes. You can certainly scale within a field if your destination uses the same field order as your source. But since that relationship between PAL and NTSC fields does not exist, there will be a artifacts due to the lack of field synchronization. Deinterlacing attempts to reclaim the lines missing from a given field so that something approaching both fields is available for the destination.The thing to note is that on a completely static scene, the viewer will see the display alternate between Bob 0 and Bob 1. There will definitely be visible flickering.The correct word for this is shimmering, not flickering. I know this because I speak english as my primary language.I'm not sure why you decided to attack my use of the English language here. If you are indeed a native English speaker, then you are aware that there are synomyms for a number of words. You can call it shimmer, while I call it flicker. Others may say it flashes or pulses. So long as we are communicating, I'm not sure why it is necessary to play games with semantics.When you use ViewFields you get frames that are the same size at the same speed, but they are no longer interlaced. UnViewFields effectively reinterlaces them. If between the two you resized from 720x480 to 720x576, you'd end up with PAL at 30fps.True enough, but now what do you do? If you show this on a PAL system, it will run 83.3% as fast as it should, and the audio will be out of sync.

After you've gotten the scaling done, now you have to deal with the frame rate. You somehow have to convert this 30i Fps to 25i Fps. If you do this to the frames, things will really get jumpy. This is because you are throwing out a pair of fields every 6 frames, representing 1/30 sec. Better would be to throw out one field every 6 fields, representing 1/60 sec. But this introduces field polarity issues.That would be fine, except I don't understand what BOB has to do with NTSC<->PAL conversions.Deinterlacing helps minimize "jumpiness" and avoids field synchronizaiton issues. Bob is the simplest method of deinterlacing, but exhibits the "shimmering" effect mentioned before. Since a smart deinterlacer normally avoids this effect, it is a good choice.

Xesdeeni

[scmccarthy]

You'll see that the results are all the same. True enough; I was thrown by the emphasis on doubling the frame rate. That would only be temporary, unless you really did bob.You can call it shimmer, while I call it flicker. Others may say it flashes or pulses. So long as we are communicating, I'm not sure why it is necessary to play games with semantics. Not only are flicker and shimmer not synonymous, flicker is already used to describe something else in video. I am only playing a 'game' with you because I already know exactly what bobbing is, what it does, and what its drawback is. Otherwise, I would not know what you meant. It is an important semantic distinction.True enough, but now what do you do? If you show this on a PAL system, it will run 83.3% as fast as it should, and the audio will be out of sync. Some DVD players can play in both PAL 25fps and PAL 30fps. It is non-standard, but better than dropping every sixth field.

Stephen

[Xesdeeni]

Some DVD players can play in both PAL 25fps and PAL 30fps. It is non-standard, but better than dropping every sixth field.I didn't realize that we were talking about converting to a non-standard format. If your TV handles this hybrid format, then go for it. But if your TV won't (like mine), then you'll need to complete the conversion and actually do something to adjust the fields. Unfortunately, dropping fields (or interpolating between them to simulate intermediate "instants of time") is the most practical (and cheap) approach we can take at present. The results can be quite good using the above technique, at least until we can get motion estimation/compensation software (and sufficient processing power) in place.

Xesdeeni

[Guest]

I agree with Xesdeeni that the terminology is not rigidly defined. For example, a single pixel wide feature (or appropriately spaced set of them) will appear only in alternate fields after separating fields into frames. That is more appropiately called flicker than shimmer. A two pixel wide line will appear to jump up and down and that is often called flutter. Maybe we should stick with the user friendly term "field alternation artifacts". :)

[scmccarthy]

Flickering affects the entire frame and shimmering affects the individual pixels. What do you think is meant when some says their avi is flickering?

Stephen

[Guest]

You're just being dogmatic if you say an object cannot flicker. Xesdeeni now seems even more justified to me. :)

[scmccarthy]

What's with the use of 'object' generically for everything? You mean pixels. If pixels 'flash' that makes the video shimmer. I hope people don't honestly believe that 'words don't matter' as long as we supposedly understand each other. I am not personally sanguine that we can understand one another when we are sloppy with our language. Misunderstandings periodically crop up without our being aware of them. We tend to believe we understood what he 'really meant', but often the miscommunication is entirely one of semantics: the branch of philology concerned with meanings, from the Greek semantikos: significant. Alwayw keep a dictionary at your desk!

Stephen

[Guest]

Originally posted by scmccarthy
You mean pixels. No, I meant and clearly stated "objects". One would think that someone so afflicted by petty pedanticism as yourself would be able to parse simple English words.

My dictionary defines "shimmer" as a "flickering light". Now go crawl into your hole.

[wotef]

afflicted by petty pedanticism

excuse the pun, but that should be pedantry :p

[scmccarthy]

WELL, crawl in my hole?

It means multiple sources of light flickering on and off independantly of one another. Difficult to define, but we know it when we see it. You wrote a filter to get rid of flickering. Is it meant to handle random fluctuations of intensity of individual pixels? No, it fixes random fluctuations of intensity from frame to frame. My interpretation of what the filter does is based on my interpretation of that one word. Otherwise, you might have called it Anti-Shimmer.

YOU are being stubburn, not me.

Stephen

[primusmp]

Please apologize me for my english cause it might not be the best one out there since I´m not a native speaker and you seem very concerned about the proper usage of the language.

I´ve been using a modified version of your script to convert Interlaced DV-PAL material (Captured from original VHS source through a Canopus ADVC-100 A/D converter) into interlaced NTSC Material.

The reason to do this is because most of the DVD desktop players sold here are PAL-B/NTSC and the TV`s are PAL-N/NTSC so it causes the PAL DVDs to be shown in B&W unless you have an external PAL-B to PAL-N converter that produces extreme quality loss (and are expensive) so it´s easier to use NTSC material.

I said I´m using a modified version cause I´m feeding the material to avisynth from Premiere; and then to Cinemacraft (2.50 or 2.66)

The issue here is I am always using BottomFieldFirst material so I originally set both parameters (OutputTopFieldFirst & InputTopFieldFirst) to false and then cleared CCE´s top field first selection box but this produced an interlaced MPEG 2 video stream with the wrong parity.

After doing some testing (I applyed more than 10 diferent script-CCE combinations to the same video)I found out that no matter what i specified in the OutputTopFieldFirst variable, the script was feeding a TFF video (I suspect that this comes from this line: "Input.SmoothDeinterlace(tff=InputTopFieldFirst,doublerate=true)"; wich I also tried with both ttf= False & True)

I solved the problem now by adding AssumeBFF at the end of the script and keeping the "OutputTopFieldFirst = True" in the script. I did this cause since I´m choosing fields 0 and 3. Considering that my original video was BFF this would mean that field 0 (actually frame at this point before the "weave()") would be the bottom one and I think that SmoothDeinterlace just informs the wrong parity but doesn´t actually Complement it (By the way when using ComplementParity() instead of AssumeBFF() it ended up with low video quality).

Finally I´m leaving the Top Field First chekcbox in CCE UNCHEKED

I hope this helps someone else, and if someone wants to hunt down the problem let me know if I can help you.

[Xesdeeni]

I'm really going to have to put the following on my http://www.geocities.com/xesdeeni2001/StandardsConversion]Standards Conversion web page:

Sometimes the correct parity doesn't make it from the input codec to SmoothDeinterlacer. I'm not sure where the problem lies, but there isn't much I can do about it in SmoothDeinterlacer, since the parity comes from what AVISynth passes to me.

Anyway, the first thing you should do is ensure that SmoothDeinterlacer is getting the correct parity. To do this, it's easiest to use a script like this:LoadPlugin("SmoothDeinterlacer.dll")
xxxSource("xxx.xxx")
SmoothDeinterlace(doublerate=true)Load the script into VirtualDub and step through the frames one by one (using the ">>" button). Make sure that motion is correct. E.g. if something is moving from left to right across the screen, it should not step back and forth as it does so. If the parity is wrong, adding ComplementParity() before SmoothDeinterlace() should fix the problem.

Next you want to ensure the output has the correct parity. This parity is chosen by which pair of fields you use in the SelectEvery() line at the end of the script. Since the frames are in sequence, which was ensured by the step above, SelectEvery(4, 0, 3) will always give you top field first, while SelectEvery(4, 1, 2) will always give you bottom field first.

Unfortunately, the only way to ensure that the resulting interlaced video has the correct parity for your interlaced display is to process a bit of test video and actually view it on the destination. In general, DVDs are top field first, while DV is bottom field first. But the MPEG encoder (or other codec) can alter this, so do a short test before you commit to a long conversion. Once you have things figured out, you won't have to change the input parity unless you change the input codec, and you won't have to change the output parity unless you change the output codec.

Xesdeeni

[primusmp]

I´ve been doing some testing. I think I´ve solved the field order issue but I have some other issues to work on.
I am getting a Strobe efect on my videos that I thing they migh be because of th time convertion (25 fps to 29.97 fps) specially noticeable in pan shots or shots with motion on them (i.e. people dancing)
The other thing that bothers me is that when i have a pan shot or some shot with motion, the edges visible on the shots become striped (Don´t know if it´s the correct word but see it for yourself).
This is caused after the interlace has been done (Actually it´s caused between the separateFields() and Weave()). I don´t understand where does this come from since the only thing done at this point is separate a full frame (Progressive??) into 2 half size Frames and them interleaving them into a 2-field frame.
I know the stripes come form the temporal diference between the upper an lower fields and I understand that this can be seen at VDub becaus it just puts the upper en lower field together but this effect is also noticeable in the TV and also it doesn´t show up when watching directly what SmoothDeinterlace() returns. (although image is a little bit blurry on moving pictures -See Script 1.1).
So I don´t see where is this effect coming from and therefore how to get rid of it.
I also don´t quite untherstand what kind of picture does SmoothDeinterlace returns, is it A progresive frame image? I guess by its name it should be (It´s suposed to Deinterlace, isn´t it) but then again everything else that´s after it is there just to interlace it again so I don´t understand how this temporal diference between fields is achieved (or by wich line).

I will try to post different Scripts with corresponding images to show the process and help to undertand what I am saying.
Script 1.1 is just Smooth Deinterlace output
Script Comp1 is there to show that parity is ok in the others (This script has it wrong because of the complement parity)
Scripts 1-6 are step by step of the full script used.
I just left the relevant lines and took all coments and selection steps away to make it clearer to fix.

[primusmp]

Here goes the Scripts (I hope)

[primusmp]

This are the corresponding pictures

By the way, this link:

I'm really going to have to put the following on my http://www.geocities.com/xesdeeni20...ersion web page:

Didn´t worked

And something else, If the output of SmoothDeinterlacer is a Progressive Frame Video. Can I just change the FPS and then feed it to CCE to get a progressive MPEG2 out of an interlaced DV AVI
With what CCE settings??

[Xesdeeni]

primusmpI am getting a Strobe efect on my videos that I thing they migh be because of th time convertion (25 fps to 29.97 fps) specially noticeable in pan shots or shots with motion on them (i.e. people dancing)Try using ConvertFPS() instead of ChangeFPS(). This will be about the best you can do without using a very expensive motion adaptive standards converter. The other thing that bothers me is that when i have a pan shot or some shot with motion, the edges visible on the shots become striped (Don´t know if it´s the correct word but see it for yourself).Your images show interlacing lines. These lines are correct in the destination, since your TV is interlaced. This will not look right on your PC, but then again neither will your original PAL video, but you know that it is OK....but this effect is also noticeable in the TV...Yes, contrary to what many believe, interlacing IS visible on most larger TVs. But it shouldn't be any more visible than with any other video. If it is, then one of the settings is probably wrong. For example, if you scale a Weave()ed pair of fields vertically, parts of the two fields will appear in one-another, which will look horrible on a TV....it doesn´t show up when watching directly what SmoothDeinterlace() returns.I also don´t quite untherstand what kind of picture does SmoothDeinterlace returns, is it A progresive frame image?Yes, the output of SmoothDeinterlacer is a progressive video. But for your TV, you need an interlaced one.By the way, this link:I'm really going to have to put the following on my http://www.geocities.com/xesdeeni20...ersion web page:Didn´t workedSorry, try this: Standards Conversion web page (http://www.geocities.com/xesdeeni2001/StandardsConversion).

Xesdeeni

[primusmp]

OK I see but you say:Yes, the output of SmoothDeinterlacer is a progressive video. But for your TV, you need an interlaced one.
Why do I NEED it?
If I load a progressive DVD into a DVD player I can watch it on my TV so that means that if I produce a progressive frame video, I would also be able to watch it on my TV and also I wouldn´t have to worry about fields or Stripes, right??

The strobe effect is not noticeable on the PC neither is it noticeable on MY DVD set top player (Panavox) but it shows up on other players/TV´s (i.e. Pioneer 343) so here is what I guess is happening:

The Panavox Player has an internal "Decoder/Converter" so I can select the output format (Between PAL-B,PAL-N or NTSC)and the player autamtically outputs the desired format regardless of what the DVD disc format is.
I`m guessing that my MPEG2 video is lower field first (Because that´s what it was before CCE) but somehow the other DVD players handle Interlaced video as TFF so they are reading it wrongly as TFF, causing this Strobe effect.

The other possible cause is that somewhere I am switching field order without knowing. I don´t think so because I checked it with VirtualDub and also because if I use complementParity() the video gets really destroyed (you can see it in picture Comp1.jpg) but, I fed the originally captured AVI DV (using DirectShowSource() followed by a SeparateFields()) into VirtualDub and it seems to be UpperFieldFirst (When watching the bobbing effect frame 0 is a little bit above frame 1 (wich correspond to fields 0 and 1 respectively)).

I changed Premiere´s setting to TFF and then watched the output in Vdub and it´s OK (Shows Top field First when played frame by frame). But if I set Premiere to BFF it´s also OK (Shows Bottom Field First when played Frame by Frame).

I will do some more testing to find out the hole truth about this but my problem is that my player doesn´t read DVD-RW so I need to burn DVD-R´s to test it (Wich is expensive for me if I have to do lots of test). And besides if my DVD player is processing the video like I think it does this won´t even show up on my TV. So it´s rather complicated.
Anyway, thanks for everything, you´re being patient and helpful.

[Xesdeeni]

Why do I NEED it?
If I load a progressive DVD into a DVD player I can watch it on my TV so that means that if I produce a progressive frame video, I would also be able to watch it on my TV and also I wouldn´t have to worry about fields or Stripes, right??Well, obviously you don't NEED anything you don't want. I'm sorry if my phrasing seems to say that there is an absolutely correct method. All the methods and choices I share are what I have found to be the completely subjective, most satisfactory output for my conversions. The whole process is a series of tradeoffs, and there certainly is no black or white. By all means, experiment and see what you prefer.

With that said, I still want to defend my approach :)

In this case, we are talking about going to an interlaced display device (unless you have a more expensive television with progressive display capability, but even then I'd suggest interlacing the result...more info below). All the video you see on this device, regardless of whether it is progressive or not, is interlaced on display. Yes, even movies exhibit interlaced artifacts on a TV, although they happen half as often on PAL TVs and about 40% of the time on NTSC TVs. So no matter what you do, the "stripes" won't go away.

However, if you encode this type of conversion progressively, you are limiting yourself to one image every 1/30 sec. But you are starting with video that has images every 1/50 of a sec. First, this means you are throwing out 20 pieces of information ("instants of time") every second. Second, this means that the deviation between the original time and the destination time is higher (13ms vs. 3ms). Third, that deviation causes the missing "instants of time" to be much more noticable (to me) as "jutter" or jumping. This means motion is much less smooth than it might be. And fourth, the original video was taken with a shutter speed adjusted for 1/50 sec. 1/30 sec is far enough away that the motion blur introduced at 1/50 sec for things in motion isn't enough to fill in the visible gaps at 1/30 sec. The result is video that appears (to me) to "strobe."

When you convert to interlace, you have destination images that are 1/60 sec apart. You actually have to duplicate rather than throw out data. This is actually bad (compared to motion adaptive techniques that actually generate new frames that are guesses at the approximate position things would have been if the video were shot at the destination rate), but in my tests (and to me) it's not nearly as bad as throwing away data. I suspect this is because the deviation is not as greate as it is at 1/30 sec, so the replicated fields are not nearly as obvious (to me). Motion is a bit smoother, although certainly not perfect. Some people have told me that they find using ConvertFPS() provides a smoother conversion than ChangeFPS(). For me, I prefer ChangeFPS() because the strobing caused by ConvertFPS() (which, incidently is an effect visible in most commercial, non-motion adaptive PAL->NTSC conversions) drives me crazy compared to the slight skip with ChangeFPS().

BTW, the reason I suggest an interlaced destination above, even with a progressive-capable TV has to do with the same smoothness of motion noted above. A progressive TV will attempt to deinterlace the incoming video. This means that 60 interlaced fields will become 60 progressive frames. But if you only feed the TV 30 progressive frames, there is no data there to reconstruct intermediate frames, so the TV will just repeat each frame, giving you only 30 progressive frames of display. The motion will be a bit less smooth. Obviously it'd be even better to convert to a 60 progressive frame output, but this isn't an option for DVDs at the current time, so the 60 interlaced frames plus the TV's deinterlacing is a good backup.

Xesdeeni

[primusmp]

Ok first:
When I asked why did I NEED to convert it to interlaced I didn´t mean to question your convertion method, I just thought that you were stating a technical need (Maybe because Encoders don´t handle progressive frames or something) and wanted to check that out.

My issue with interlaced footage is that I´m using different programs to process the video, each of them with independant settings and I just can´t seem to set all of them rigth, so I keep fighting them once and again.

I just want to find one combination that works and that´s it. Also, as i do most of the processing in my PC I just can´t see the interlace related issues until the DVD is burned and everytime I think I´ve solved it, something else shows up.

I found out that the strobing was because of a wrong parity setting, I´m not sure yet where am I setting it wrong (Premiere, Avisynth, SmoothDeinterlacer or CCE). I didn´t figured this one out because My player just converts the footage internally (Don´t know why or how) and just shows it correctly :confused:.
I hope I will find it out tomorrow, I prepared different combinations of settings and will test them.

I also tryed using ConvertFPS() instead of ChangeFPS() but it seems to have some issues with the premiere plug-in because scripts using this function hang up the video server and I have to close everything and start all over again (I didn´t have time to check this yet).

I really appretiate your help on this, I´ve learned a lot so far and I know sometimes I migth have solved some issues by myself with some testing but unfortunatelly testing is expensive for me right now (expensive in time, effort and money) so I just can´t do as much as I would like to.

Thanks a lot

[FredThompson]

Well, looks like I missed quite a bit of stuff in this thread lately...

FWIW, I've been in contact with the author of WinDV. We're working on a way to read/write PAL/NTSC DV regardless of camera type. There's really no difference between the tape drive portions.

This might end up being a very good way to move data between the standards (unless you're dealing with DVD, VHS, or another video freak.)

[morsa]

It would be nice if WinDV author and you could give some source code to VdubMod team to add a DV capture module to VdubMod.
I use WinDV all the time and it is really good.

[FredThompson]

No secrets, it's all available on the web with a couple of simple searches.

All WinDV does right now is calls through Windows. I've asked for a new function to read a complete tape. The author suggested a function to read until nothing is returned for 10 seconds which makes sense. That's what will probably happen next.

He's doing all the coding, I'm just supplying an NTSC tape and testing the result with a PAL from him when the software is done (in about a month or so.)

There's Linux source that extracts either format from a DV stream:

http://libdv.sourceforge.net/
http://kino.schirmacher.de/

Which format is your equipment?

[morsa]

talking to me?

[FredThompson]

yup.

I'm also researching Digital8. Could be that's also just a tape stream. Most likely is, just need more documentation.

Anybody have the little demo clip that was in this thread? It's gone.

Server's hungry lately.

(edit: fixed the format type.)

[morsa]

AFAIK there is no problem about recording a NTSC signal into a PAL DV machine via Firewire.The only problem takes place if you try to playback that stream.
If you connect a NTSC machine to a PAL machine via Firewire, you can transfer from one to another with no problems.

-My equipment is DVCAM.

-Are you talking about HI8 or Digital8?
If you are talking about Digital8 there is no problem cause DVCAM, DV, MiniDV,DVCPRO25 and Digital8 are all the same, they only differ on medium type.They look exactly the same thru Firewire.

In case I didn't understand very well: Are you talking about making a standards conversion on the fly inside WinDV?

[FredThompson]

Oh, yeah, you're right, Digital8.

The idea is to use a PAL camcorder to read/write and NTSC tape and vice versa.

I don't know if it can be done. I don't have any PAL source to try. It's fairly easy and inexpensive to sample VHS but quickly gets rather expensive for other formats and the quality is horrible.

The idea is to use whatever native camcorders are available to share high-quality video across continents without having to buy both type of camcorders.

If this works, I'm willing to buy a Digital8 camcorder and would then know I could work with almost any format. $300 or so is less than a plane ticket overseas, know what I mean?

I sell industrial equipment. The companies I represent are European. I'm trying to find an easy way to get high-quality copies of whatever they shoot or produce. Seems to me it's not that difficult for a non-video type to hook a digital camcorder to their playback device and send me a taped copy of something, or just shoot video and send me the tape. Most people don't understand how quickly quality drops when they copy with average equipment or try to use standalone converters.

Nuts. I was really hoping you had miniDV. Still, what you said is very encouraging. If they DO all look the same over firewire, the only "trick" is to specify the format type.

No, wasn't planning on format conversion on-the-fly. Need a way to get the data. My analog capture equipment works with composite and S-video for both PAL and NTSC but a VHS copy of camcorder source is horrible. At least, it is for my purposes.

Granted, PAL camcorders are available in the States but they're quite expensive.

[morsa]

I think this is getting a little out of topic.
Please, I ask any Moderator to move these posts to the DV section.I guess that is the correct place for this.Thank you.


Regarding what you say.The answer is yes.
You can backup any DV material to digital8 with "exactly" the original quality if you make it thru Firewire.
And yes, in most cases you can record a NTSC signal into a Pal equipment and viceversa.The only problem is that you cannot reproduce a different standard than the equipment's thru its analog output.
I don't understand why you specify "MiniDV".All this consumer grade video formats are the same thing.The kind of information stored on tapes is the same, they only differ on how the tape is recorded.
Even if you record material in LP mode instead of SP, the image quality will remain exactly the same.The only drawback is that a LP tape has a better chance of having drops.
I have worked with every digital video equipment from DV to Cinealta.
And nowadays I really believe HD-CAM is an expensive lie, digibeta isn't better than DVCPRO50, and the best cost-effective solution for HighDef video is Panasonic's.
Hope this helps.

[FredThompson]

yes, this has moved way OT from the original thread. That wasn't the intent.

miniDV because the carriers vary. I can't stick a DV tape in because it's larger.

on-the-fly conversion would be very difficult without a lot of horsepower.

[Biggles]

Ok I am new at altering script. I am editign chapters from various dvds and wish to make one dvd. I have been using dvd2svcd to make get the mpv and ac3 files separately - using this as find it a quick and useful medium to see and extract my chapters and the incorporate fixed subs only the mpv file. I can use either cce or tmpg as have both for the encoding however am putting the dvd together with tmpgdvd author program

Now i have a dvd i wish to extract which is in pal format and I wish to convert it to ntsc format - both anamorphic and retaining the ac3 sound.

I have tried your short form editing of avsynth script with both tmpg and cce but find that the output in the frames give me horizontal lines on movement similar to me using a poor delacing filter.

I am trying to use your script here. Now I would be gratful if you woudl correct the script; for as i see it i am not sure in the script i am supposed to input values of my own making or not. I have attempted to write the script as I see it below (having inputted the values I am supposed to) but i am sure it is not quite correct as it did not work when I tried it. I woudld be grateful if you would highlight the parts i am supposed to completemyself - eg am i supposed to put the whoel file path instead of 'input' every time 'input' comes up.

Also which would you recommend TMPG or cce as the encoder for this and will multipass still have a clear advantage?

Import("D:\MOVIEF~1\RESAMP~1.AVS")
LoadPlugin("C:\PROGRA~1\DVD2SVCD\DVD2SVCD\AVISYN~1\Mpeg2dec\mpeg2dec.dll")
LoadPlugin("C:\PROGRA~1\DVD2SVCD\DVD2SVCD\AVISYN~1\AVISYN~2.DLL")
LoadPlugin("C:\Program Files\DVD2SVCD\DVD2SVCD\Avisynth2 Plugins\SmoothDeinterlacer.dll")
Input = mpeg2source("D:\MOVIEF~1\DVD2AV~1.D2V")
InputTopFieldFirst = true
OutputFrameRate = 29.97
OutputWidth = Input.width
OutputHeight = 480
OutputTopFieldFirst = true
ConversionType = (OutputFrameRate <= Input.framerate) ? 1 : 0
LoadPlugin("C:\PROGRA~1\DVD2SVCD\DVD2SVCD\AVISYN~1\Mpeg2dec\mpeg2dec.dll")
LoadPlugin("C:\PROGRA~1\DVD2SVCD\DVD2SVCD\AVISYN~1\AVISYN~2.DLL")
LoadPlugin("C:\Program Files\DVD2SVCD\DVD2SVCD\Avisynth2 Plugins\SmoothDeinterlacer.dll")
vpro = Input.SmoothDeinterlace(tff=InputTopFieldFirst, \
doublerate=true)
vinfps = Input.framerate < OutputFrameRate ? \
vpro.BilinearResize(OutputWidth, OutputHeight) : \
vpro
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)
vout = vlace.Weave().ConvertToRGB()
return(vout)
AvisynthSubtitler("D:\MOVIEF~1\Subs\","permsubs.txt")

Thanks
A real novice I confess

[Xesdeeni]

Well, that original script is complex only because it was designed NOT to be modified :) The short version for PAL DVD to NTSC DVD would be:LoadPlugin("C:\PROGRA~1\DVD2SVCD\DVD2SVCD\AVISYN~1\Mpeg2dec\mpeg2dec.dll")
LoadPlugin("C:\PROGRA~1\DVD2SVCD\DVD2SVCD\AVISYN~1\AVISYN~2.DLL")
LoadPlugin("C:\Program Files\DVD2SVCD\DVD2SVCD\Avisynth2 Plugins\SmoothDeinterlacer.dll")
MPEG2Source("D:\MOVIEF~1\DVD2AV~1.D2V")
SmoothDeinterlace(doublerate=true)
LanczosResize(720, 480)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4, 1, 2)
Weave()If your video is a movie (i.e. not interlaced), try this:LoadPlugin("C:\PROGRA~1\DVD2SVCD\DVD2SVCD\AVISYN~1\Mpeg2dec\mpeg2dec.dll")
LoadPlugin("C:\PROGRA~1\DVD2SVCD\DVD2SVCD\AVISYN~1\AVISYN~2.DLL")
MPEG2Source("D:\MOVIEF~1\DVD2AV~1.D2V")
LanczosResize(720, 480)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4, 1, 2)
Weave()Both of these will result in interlacing lines when viewed on the PC, which has a progressive display. But TVs are interlaced, so this is correct for TV viewing.

Xesdeeni

[Biggles]

Thanks much better

You were right I was watching the movie on a pc hence the interlacing lines.

Regards

[Bruce Leroy]

I've tried this and many other methods, can encode fine, no interlace lines to speak of... I'm running the same script using Xesdeeni's standard conversion guide. Loading into TMPG... ect.
It plays ok, with no audio delay problems on my set top.... but the problem is, video is kind of jerky, either back and forth if I use (4,0,3) or robotic if i use (4,1,2) for 'select every .... Any help would be apreciated.

Thanks guys

[Xesdeeni]

You didn't say which type of input you had (interlaced or progressive), and I'm not sure what you mean by "robotic." But you have to ensure that both input and output polarities are correct in either case.

For the input, the easiest way to do so is to comment out (use the '#' character) all the lines from the top script above script after SmoothDeinterlace() or after MPEG2Source() in the bottom script. Then load the script into VirtualDub and single step (for some reason the '>>' button single steps) through a moving portion of the video (examine at least 20 frames). If the video steps back and forth, then the input polarity is wrong. Add ComplementParity() after the MPEG2Source() in either script and check the video again in VirtualDub.

[If you continue to see problems in the top script, add SeparateFields() and Weave() before SmoothDeinterlace() and check the polarity again.]

For the output, the above scripts should work for DVD production, as long as you are using TMPGEnc or CCE. For other encoders, the setting may be different. Also, you can change the polarity in TMPGEnc and CCE themselves in a variety of ways, so I'm assuming default settings. To test the output, just encode a sample of moving video and check it out on the TV. You won't be able to tell on the PC. Once you have the output right, you won't have to change your output settings unless you change your encoding process.

Xesdeeni

[Kika]

The Script does work for progressive AND interlaced Video. But i suggest not to use ChangeFPS() because it drops and/or doubles Frames.
Try ConvertFPS(). That worked absolutly fine for me (Interlaced NTSC-DVD to interlaced PAL DVD).

[Xesdeeni]

The use of ChangeFPS() vs. ConvertFPS() is really a matter of taste. I've been trying to come up with a little clip that I can convert using both and post (probably as a looping animated GIF) as an example of the artifacts each has. If you have a candidate, let me know.

Xesdeeni

[FredThompson]

First off: If you've read this note shortly after it was posted, it's probably edited.

Secondly: I've re-rea the entire thread but might have missed something. Most of what I saw had to do with refresh rate issues.

I've been browsing the Snell white paper: http://www.snellwilcox.com/reference/pdfs/estandard.pdf

Lots of stuff there and maybe I'm blind but I can't seen to find anything that deals with the actual geometry of PAL vs. NTSC displays.

Do both PAL and NTSC have the same height/width ratio for the displayed area? If not, what is the difference?

This article: http://www.btinternet.com/~perrybits/pages/AspectRatios.htm says the visible area ratio is the same, 4:3.

this page says otherwise: http://www.video2cd.co.uk/ntsc2pal1.html
It claims the NTSC height/width ratio is 1.46 and for PAL it is 1.22.

(Oh, I'm trying to convert NTSC DV footage so the resizing and color issues will be handled by AviSyth with MotionPerfect creating the 25fps video stream because motion integrity is critical for this video.)

If they are not the same, how best to convert the two and maintain aspect ratio as closely as possible? If the screens truly are different geometries with NTSC being more rectangular, what formulas might be used to know how to crop or letterbox to maintain proper ratio when moving between them?

Also, what about colorspace? I understand PAL is wider but how does that affect translation? Does it mean NTSC colors -> PAL colorspace without a hitch but something needs to be done to do PAL -> NTSC? It would seem so to me. All the tapes I've had converted come out looking like cartoons, like a saturation problem. Even if there isn't a clipping issue, how should the ranges be converted using AviSynth filters so the target market has the "look" they're used to? (Meaning, PAL viewers aren't looking at washed-out color and NTSC viewers aren't seeing circus colors.)

[Xesdeeni]

I've been browsing the Snell white paper: http://www.snellwilcox.com/reference/pdfs/estandard.pdfI was given a hard-copy of that document about 10 years ago at a NAB convention by a guy at S&W. He showed me their line of converters, including HD and the new (at that time) motion compensated conversion devices. He really educated me a lot, including showing me how to pick out the flaws in their best converters!Do both PAL and NTSC have the same height/width ratio for the displayed area? If not, what is the difference?

This article: http://www.btinternet.com/~perrybit...spectRatios.htm says the visible area ratio is the same, 4:3.

this page says otherwise: http://www.video2cd.co.uk/ntsc2pal1.html
It claims the NTSC height/width ratio is 1.46 and for PAL it is 1.22.
The confusion comes from mixing analog and digital terminology. The screen for both NTSC and PAL is 4:3. That means if the screen is 4 inches wide, it's 3 inches high (actually, much PAL is now being broadcast in 16:9, and over half of the TVs in places like the UK are already 16:9, but for our discussion here, we'll stick with what has been in place for 75 years or so). If it's 8 inches wide, it's 6 inches tall. You get the point.

In the digital world, we've introduced the concept of pixels. They didn't exist in the analog world. The shape of a pixel is not standard. It is almost always rectangular, and often square, but not always. So you could have one pixel the width of your TV screen by the height of one scanline. The aspect ratio of your TV screen didn't change, it's still 4:3. However, if you refer to the ratio of horizontal to vertical pixels, you get something like 1:576. You could also create really tall thin pixels and have a ratio like 1280:576. But again, your TV screen aspect ratio didn't change, only the shape of the pixels. The thing that decides the shape of the pixel is the rate at which you sample. If you sample once per scan line (about 1/15650 second), you get the 1:576 ratio. If you sample 1280 times in the same scanline (about 1/(15650 * 1280) ~= 20MHz), you get the 1280:576 (note the analog scanlines determine the digital vertical resolution).

When they began digitizing video, they decided to standardize the shape of the pixels. Actually, they really just wanted to standardize the sample rate, and they used 13.5MHz. Coupled with the other parameters that go into an NTSC and PAL signal, that worked out to about 720 pixels per scan line. There are 525 lines in NTSC and 625 in PAL, but only about 486 are available to hold an image in NTSC, and only about 580 of the PAL ones are available. Round to the nearest 16 (nearest 8 in each field) and you get 720x480 and 720x576. But THESE PIXELS ARE NOT SQUARE. In fact, the NTSC pixels are tall and thin, and the PAL pixels are short and fat.

The importance of the shape of the pixels comes into play when you introduce the computer. Most computer screens are 4:3 as well. But most computer digital resolutions utilize square pixels (1280x1024 is one notable exception). So for the pixels to be square on a 4:3 display, the ratio of horizontal to vertical pixels must also be 4:3. Hence the 640x480, 800x600, 1024x768, etc. resolutions.

Whew! All of that is to try to explain why the resolutions given on the page you reference above for NTSC (352x240) and PAL (352x288) can both be 4:3. The ratio of pixels isn't 4:3, in fact for NTSC it's 22:15 and for NTSC it's 11:9. But when displayed correctly on a TV, both will be 4:3. On a computer screen, both will have to be scaled--the NTSC one made taller or thinner, and the PAL one made shorter or fatter, to compensate for the difference in shape between the video pixels and the computer pixels. If they are not the same, how best to convert the two and maintain aspect ratio as closely as possible? If the screens truly are different geometries with NTSC being more rectangular, what formulas might be used to know how to crop or letterbox to maintain proper ratio when moving between them?
If you are going from DV to DV, you will have to scale the image. From NTSC DV to PAL DV, you simply scale from 720x480 to 720x576. The resulting aspect ratio will be the same. Also, what about colorspace? I understand PAL is wider but how does that affect translation? Does it mean NTSC colors -> PAL colorspace without a hitch but something needs to be done to do PAL -> NTSC? It would seem so to me. All the tapes I've had converted come out looking like cartoons, like a saturation problem. Even if there isn't a clipping issue, how should the ranges be converted using AviSynth filters so the target market has the "look" they're used to? (Meaning, PAL viewers aren't looking at washed-out color and NTSC viewers aren't seeing circus colors.)The differences in color ranges are only in the analog domain. Once everything is digital, the range is the same. I suspect the codec you are using is causing the problem. Some DV codecs handle the color range differently than others. I recommend the MainConcept DV codec (http://www.mainconcept.com/downloads.shtml), although it's $50 if you want to encode without the logo. There is also a problem with the YUV->RGB conversion in some versions of Windows that causes the colors to look bad. If you see this, you can add ConvertToRGB() to your AVISynth to use AVISynth's conversion instead of the one in Windows.

Xesdeeni

[FredThompson]

ok, got it.

The color change was in NTSC tapes made from PAL source converted using a standalone converter at a service bureau. A lot of stuff looks overly garish which, I suspect, comes from the force-fit conversion.

Yup, I'm using the MainConcept codec. They've recently switched to a serial number install but the internal function hasn't changed. Stupid logo started showing up so I went back to the older version they'd sent out.

Thanks, I was really scratching my head on this one.

One more question: As I understand what you saw about colorspace, converting my NTSC to 25fps and 720x576 then pumping it out to a PAL VCR over analog cables there should be no color corruption, correct?

[Xesdeeni]

If you have access to a PAL DV camcorder, then you'll be golden. I've gone the other way and taken a PAL DV clip (downloaded) and converted it to NTSC and shown it on my TV via analog out (didn't tape it, just viewed it). The resulting color was absolutely fine.

Xesdeeni

[FredThompson]

Originally posted by Xesdeeni
If you have access to a PAL DV camcorder, then you'll be golden.

Xesdeeni I'm working on that. Sent an NTSC tape to the author of WinDV so he can test reading it on his PAL equipment. At the firewire level, it's just a data stream, the camera is irrelevant. The challenge seems to be the headers assigned by Windows so he's looking into it a little deeper with code from the Linux DV site. There's already dual-format reading in the Linux world. Same thing should work for Digital8.

Yup, this is my ultimate goal, just exchange digitial tapes. Everyone has VHS, though, so it's what I'm stuck with. PAL tapes show up here so they've got to be converted and stuff I shoot they want...

[Xesdeeni]

Yup, this is my ultimate goal, just exchange digitial tapes. Everyone has VHS, though, so it's what I'm stuck with. PAL tapes show up here so they've got to be converted and stuff I shoot they want...It sounds like you should just order a PAL camcorder or one of the DV converter boxes for the digital tapes. There is one device I've heard of (http://www.gthelectronics.co.uk/) that might handle most of what you need in the analog world.

Xesdeeni

[FredThompson]

I think you missed what I was trying to communicate.

The tape machanism of a DV or Digital8 device is just a streaming data recorder. Your camcorder includes the ability to format a particular type of data stream that is stored on the tape.

It is possible to read the raw data off the tape and write raw data to it. If you do that, you can decrypt the data and extract PAL or NTSC or whatever is stored on the tape.

http://www.linux1394.org/index.html
http://members.tripod.com/~liaor/

DVTransfer is dead but I have the site
DVStreamer is packing data into the DV frames then going through DirectShow...I think.

[Xesdeeni]

I thought I understood what you said. You saidmy ultimate goal, just exchange digitial tapeswhich I took to mean that someone would send you DV/Digital8 tapes of either PAL or NTSC and you wanted to deal with both. But the links you provide are for putting any random data into a format that makes the camcorder think it's dealing with video. This is useful for archiving data. But the video you are simulating to make the camcorder happy will be either NTSC or PAL. And I'm pretty sure few camcorders will actually deal with both. So I'm pretty sure you won't be able to take a PAL DV/Digital8 tape and just read it in an NTSC DV/Digital8 camcorder. Either you or your customers will have to have the same standard of camcorder as the other, regardless of what the data inside the NTSC or PAL framing may be.

OTOH, if you do find a program that will allow an NTSC DV/Digital8 camcorder to read a PAL DV/Digital8 tape, please let me know! :)

Xesdeeni

[FredThompson]

Packet-level IEEE 1394 access of the drive, bypassing the format-specific stuff. This page shows an ID byte defining PAL/NTSC content: http://www.linux1394.org/dv1394.html I don't have access to the IEEE documents so can't get any further than that. DV is also a few hundred dollars to get the specs. It seems logical that low-level access is available. It would certainly be the cheapest way to do quality testing on camcorders at the factory.

Here's an excerpt from an email I got from Michael Carr (DVIO):

Yes, I have another packaged called DVIO Pro which handles low-level
access, and I'm about to release a complete rewrite of that program that also handles low-level access but in the context of Microsoft DirectShow API, which makes the application more universally compatible and extensible
in the long run.

Here's another:

> Can dv1394 be used, for example, to READ a PAL DV tape from an NTSC
> camcorder?

I kind of doubt that would work, but you can try. It all depends on
whether or not the camera is willing to send the PAL data out via
FireWire. (DV video equipment is sometimes very picky about its data
stream - it might see the PAL flag and freak out). But if the camera
sends it, dv1394 will definitely be able to record it.

Maybe we'll get lucky.

[Xesdeeni]

Yeah, he's saying the same thing. If you could get direct access to the DV/Digital8 data, then you could do what you want. But the camera is in the way, and it expects NTSC or PAL data. I suspect if you get it to work, you may have a very limited number of cameras that will support it. Hence my recommendation above just to purchase a cheap DV/Digital8 camcorder from a PAL country and be done with it :)

Xesdeeni

[FredThompson]

I'm trying to avoid buying both DV and Digital8 in PAL. U.S. prices are quite low for basic camcorders. I've found some sources for PAL stuff here that aren't too exorbitant (but PAL DV is still $600, yuck). Every time I'm over there they seem to be $200 more than in the U.S. In any event, an NTSC DV tape is on it's way over there for testing. Hope it works.

[FredThompson]

I've moved the tape topic to the DV area. If you have ANY interest in this, go take a look at what just happened: http://forum.doom9.org/showthread.php?s=&threadid=55686

[numlock]

what would the script look like if I needed to convert 320x240 25p to 352x240 29.97p ?

[Xesdeeni]

what would the script look like if I needed to convert 320x240 25p to 352x240 29.97p ?EitherDirectShowSource("320x240@25p")
ChangeFPS(29.97)
LanczosResize(352, 240)orDirectShowSource("320x240@25p")
ConvertFPS(29.97)
LanczosResize(352, 240)depending on your taste. But neither of these will look as good as going to 59.94i. ChangeFPS() will repeat every 5th frame. That means 5 out of 6 frames will show for 1/30 second, while 1 out of 6 will show for 1/15 second. That difference is very noticeable, and it occurs so rarely that it is pretty displeasing (especially on slow pans).

If you converted to 59.94p (and then to 59.94i), you would be showing a pattern of 2, 2, 3, 2, 3. That means 3 out of 5 frames would be shown for 1/30 of a second, and the other 2 out of 5 frames would be shown for 1/20 of a second. The fact that the difference isn't as great, and that the different durations occur more often (we're used to seeing 2, 3, 2, 3, ...) means the results will be more pleasing.

ConvertFPS() will use interpolation, but I've never been happy with this, because the fractional NTSC rate means you get blending on 1000 out of 1001 frames (0.0, 0.033, 0.067, 0.100, 0.133, 0.167, 0.200,...0.801, 0.834, 0.868, 0.901, 0.934, 0.968, 1.001,...). I've done some experiments to round the fractions so frames that are close are not interpolated, but I haven't come up with a decent script for this.

Xesdeeni

[Didée]

ConvertFPS() will use interpolation, but I've never been happy with this, because the fractional NTSC rate means you get blending on 1000 out of 1001 frames [...]
I've done some experiments to round the fractions so frames that are close are not interpolated, but I haven't come up with a decent script for this.

You don't need to write a custom script for that, there's a plugin that does it for you.

In Motion.dll by mg262/Clouded, there are not only functions for motion search/compensation. It also contains "BlendFPS()", which has a parameter "aperture". BlendFPS Behaves like ConvertFPS, only that you can set the amount of blending by aperture. aperture=1.0 will use full blending like ConvertFPS, aperture=0.0 will use no blending at all like ChangeFPS, and values between 0.0~1.0 will use blending only for frames where blend weightings above that respective value are needed.
Just try it, it's easier than I can explain it. ;)

[a2j]

2Xesdeeni I've been using the scipt from the web-page you've put up few years ago "Standards Conversion", but I was using the script for AVI - now I've got to convert DVDs in NTSC to Pal and tryed to google up that page - and couldn't find it. Could you, please, help?

[Alex_ander]

From my bookmarks:
http://www.geocities.com/xesdeeni2001/StandardsConversion/
http://www.geocities.com/xesdeeni2001/StandardsConversion-Preview-0.html
(sorry for not being Xesdeeni :) )

[Xesdeeni]

Wow! Someone actually looked at the preview page? I never got one bit of feedback on it.

Xesdeeni

[laserfan]

Wow! Someone actually looked at the preview page? I never got one bit of feedback on it.I remember examining that page, but what completely solved my problem (and has made me VERY HAPPY) is DGPulldown which of course your idea inspired. I've converted a couple of PAL DVDs for playback on my media players and it's worked fantastically well. In fact, even the "non-standard" DVDs I've made with it (no re-encoding of either audio or video) work on my non-PAL DVD players!

So thanks, dude. I'd have your baby, but DG has first dibs on that! Oh wait, I think you have to be female...sigh. ;) :D

[Xesdeeni]

Yeah. They were discussing pulldown flags in the DGPulldown thread one day, and I had been messing with the cadence of a PAL video converted to NTSC in AVISynth. It occurred to me that if the flags were flexible enough to do all the weird combinations that DVDs use to telecine 24 fps film, they would be flexible enough to handle my preferred PAL cadence (3:2:3:2:2:3:2:3:2:2...) without actually encoding the fields that way. DG was nice enough to try it, and the result was no more screwing with audio stretching!

But in all this time, there's still not a nice package to allow converting an entire DVD from one standard to another, retaining all the menus and extras. But as you experienced, a number of DVD players can handle both and do their own standards conversion, so the need must never have hit critical mass.

Xesdeeni

[laserfan]

...the need must never have hit critical mass.Indeed, I have done only 3 or 4 myself. I suppose if there were alot of PAL discs I wanted to play here in the US I'd simply buy a special player. But in the meantime that DGPulldown works so well (and so easy) is truly magic! :)

[a2j]

From my bookmarks:
http://www.geocities.com/xesdeeni2001/StandardsConversion/
http://www.geocities.com/xesdeeni2001/StandardsConversion-Preview-0.html
(sorry for not being Xesdeeni :) )

I haven't been back to this page for half an year!
Huge thanks to Alex_ander! And to Xesdeeni!
Xesdeeni, Are you here? I have a question that you might have idea on how to go about it (related to standards conversion)...

[Xesdeeni]

Sure, I'll help if I can.

Xesdeeni

[a2j]

Right now I am at the point, where I have to work through this:
1. I have NTSC_DVDs
2. Decode for (believe it or not!) NLE (Adobe PremierePro) and add titles and logos and stuff...
3. Convert to PAL
4. Authorize for PAL_DVD
The whole mess is because (a) Some crook designed those units, that ruin the camera signal into DVD without saving the original DV signal; (b) I have to work with low-budget organizations that thought that those units andre (a) are great for them...
So, the question that I have is: I do know that with all I have to do with the video, the quality of picture will be far from anything good. But still, do you have any suggestions on how to save the most of quality possible?

And, another question: The conversion table has been posted about 7 years ago - may be there are some better ways by now? Do you know? Thanks!

[Fizick]

a2j,
too many words :) but not many info.
what is your NTSC_DVDs consist of: is it progressive FILM or interlaced (DV) video?

EDIT: sorry, now I see "DV" word in your message. :)

[Ulf]

aj2,

I have made a batch file that converts PAL->NTSC or NTSC->PAL depending on the frame rate. It might be of use for you (if you are running Windows). It is meant for true interlaced (not telecined) video conversion. Save the batch file with ".bat" suffix. Drop your Avisynth script (with audio) in the ".bat" file and another Avisynth file is created in PAL or NTSC format, depending on your original format. It also works for HDV video files.
This is roughly how it works:

NTSC->PAL: 10 out of 12 fields are kept. This means that some fields have to be converted from bottom field to upper field or vice versa (depending on if the source was BFF or TFF) and scaled at the same time to 720x480 pixels (or to 1440x1080 pixels if in HDV). The audio is adjusted to 48000 Hz.

PAL->NTSC: 10 fields will be 12 fields by duplication. Otherwise similar procedure as above.

The script:

echo off
cls
@REM The input NTSC or PAL content can be cropped in the
@REM resulting AVS file before conversion to PAL or NTSC.
@REM
echo ---NTSC interlaced (480i or HDV) to PAL interlaced---
echo ---PAL interlaced (576i or HDV) to NTSC interlaced---
@REM ------------------------------------------------------------
set WAVI_EXE=C:\Program Files\Audio\Wavi\Wavi.exe
@REM ------------------------------------------------------------
set TFF=true
set /P ANS=Is input TFF? (Y/N):
IF %ANS%==N set TFF=false
IF %ANS%==n set TFF=false
@REM ------------------------------------------------------------
set TMP1_FILE=c:\tmp1.txt
set TMP2_FILE=c:\tmp2.txt
set TMP_AVS=%~dp1tmp_%~n1.avs
set TMP_WAV=%~dp1tmp_%~n1.wav
@REM ---Determine PAL or NTSC---
echo Import("%~f1") > "%TMP_AVS%"
echo AudioDub(last.KillAudio(),Tone()) >> "%TMP_AVS%"
echo PAL = (Framerate()==25) ? 1 : 0 >> "%TMP_AVS%"
echo INP = (Width() ^> 720) ? 1 : 0 >> "%TMP_AVS%"
echo INP = 10*INP+PAL >> "%TMP_AVS%"
echo WriteFileStart("%TMP1_FILE%",String(PAL)) >> "%TMP_AVS%"
echo WriteFileStart("%TMP2_FILE%",String(INP)) >> "%TMP_AVS%"
echo trim(0,1) >> "%TMP_AVS%"
start "WAVI" /belownormal /b /w "%WAVI_EXE%" "%TMP_AVS%" "%TMP_WAV%"
del /q "%TMP_AVS%"
del /q "%TMP_WAV%"
set /P PAL= <"%TMP1_FILE%"
set /P INP= <"%TMP2_FILE%"
del /q "%TMP1_FILE%"
del /q "%TMP2_FILE%"
@REM ------------------------------------------------------------
IF %INP%==0 set AVS_FILE=%~dp1576i_%~n1.avs
IF %INP%==1 set AVS_FILE=%~dp1480i_%~n1.avs
IF %INP%==10 set AVS_FILE=%~dp1HDV_PAL_%~n1.avs
IF %INP%==11 set AVS_FILE=%~dp1HDV_NTSC_%~n1.avs
copy /Y "%~f1" "%AVS_FILE%"
@REM ------------------------------------------------------------
IF %PAL%==0 echo #--NTSC interlaced (480i or HDV) to PAL interlaced-- >> "%AVS_FILE%"
IF %PAL%==1 echo #--PAL interlaced (576i or HDV) to NTSC interlaced-- >> "%AVS_FILE%"
echo #-------- >> "%AVS_FILE%"
echo #Inspect aspect error due to cropping by uncommenting "Subtitle" (last line) >> "%AVS_FILE%"
echo # and check the avs file in VirtualDub (F2 reopens avs file) >> "%AVS_FILE%"
echo #Cropping: >> "%AVS_FILE%"
echo #-------- >> "%AVS_FILE%"
echo Left= 0 >> "%AVS_FILE%"
echo Right= 0 >> "%AVS_FILE%"
echo Top= 0 >> "%AVS_FILE%"
echo Bottom= 0 >> "%AVS_FILE%"
echo #-------- >> "%AVS_FILE%"
echo TFF = %TFF% # Set to true if input stream is TFF, false for BFF >> "%AVS_FILE%"
echo HDV = (Width() ^> 720) >> "%AVS_FILE%"
IF %PAL%==0 echo NewHeight= HDV ? 1080 : 576 >> "%AVS_FILE%"
IF %PAL%==1 echo NewHeight= HDV ? 1080 : 480 >> "%AVS_FILE%"
echo NewWidth= HDV ? 1440 : 720 >> "%AVS_FILE%"
echo TFF ? AssumeTFF() : AssumeBFF() >> "%AVS_FILE%"
echo Left=2*Round(Left/2.0) >> "%AVS_FILE%"
echo Right=2*Round(Right/2.0) >> "%AVS_FILE%"
echo Top=2*Round(Top/2.0) >> "%AVS_FILE%"
echo Bottom=2*Round(Bottom/2.0) >> "%AVS_FILE%"
echo Conv= (Left+Right+Top+Bottom)^>0 ^&^& IsYV12() >> "%AVS_FILE%"
echo WasYV12=IsYV12() >> "%AVS_FILE%"
echo Conv ? ConvertToYUY2(interlaced=true) : last >> "%AVS_FILE%"
echo Crop(Left,Top,-Right,-Bottom) >> "%AVS_FILE%"
echo HA=Height() >> "%AVS_FILE%"
echo WA=Width() >> "%AVS_FILE%"
IF %PAL%==0 echo W_H= HDV ? 1440.0/1080.0 : 720.0/480.0 >> "%AVS_FILE%"
IF %PAL%==1 echo W_H= HDV ? 1440.0/1080.0 : 720.0/576.0 >> "%AVS_FILE%"
echo tmpH = 2*Round((HA - WA/W_H)/2.0) >> "%AVS_FILE%"
echo tmpW = 2*Round((WA - HA*W_H)/2.0) >> "%AVS_FILE%"
echo tmpH = (tmpH ^> 0) ? tmpH : 0 >> "%AVS_FILE%"
echo tmpW = (tmpW ^> 0) ? tmpW : 0 >> "%AVS_FILE%"
echo dWL= 2*Round(tmpW/4.0) >> "%AVS_FILE%"
echo dWR= tmpW-dWL >> "%AVS_FILE%"
echo dHT= 2*Round(tmpH/4.0) >> "%AVS_FILE%"
echo dHB= tmpH-dHT >> "%AVS_FILE%"
echo AddBorders(dWL,dHT,dWR,dHB) >> "%AVS_FILE%"
echo ERR=1.0-(WA+tmpW)/(W_H*(HA+tmpH)) >> "%AVS_FILE%"
echo ERR=Round(1000.0*ERR)/10.0 >> "%AVS_FILE%"
echo info_ERR="Aspect error: "+String(ERR,"%%1.1f")+"%%" >> "%AVS_FILE%"
echo SeparateFields() >> "%AVS_FILE%"
echo Ht=Height() >> "%AVS_FILE%"
echo Wt=Width() >> "%AVS_FILE%"
echo sh1=0.25*(2*Ht-NewHeight)/Float(NewHeight-1) # Field shift correction >> "%AVS_FILE%"
echo sh2=sh1+0.5 # Correction for top field->bottom field and the opposite >> "%AVS_FILE%"
echo sh1 = TFF ? sh1 : -sh1 >> "%AVS_FILE%"
echo sh2 = TFF ? sh2 : -sh2 >> "%AVS_FILE%"
IF %PAL%==0 echo n0=SelectEvery(12,0).Spline36Resize(NewWidth,NewHeight/2,0,-sh1,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==0 echo n1=SelectEvery(12,1).Spline36Resize(NewWidth,NewHeight/2,0,sh1,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==0 echo n2=SelectEvery(12,2).Spline36Resize(NewWidth,NewHeight/2,0,-sh1,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==0 echo n3=SelectEvery(12,3).Spline36Resize(NewWidth,NewHeight/2,0,sh1,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==0 echo n4=SelectEvery(12,4).Spline36Resize(NewWidth,NewHeight/2,0,-sh1,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==0 echo n6=SelectEvery(12,6).ComplementParity().Spline36Resize(NewWidth,NewHeight/2,0,sh2,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==0 echo n7=SelectEvery(12,7).ComplementParity().Spline36Resize(NewWidth,NewHeight/2,0,-sh2,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==0 echo n8=SelectEvery(12,8).ComplementParity().Spline36Resize(NewWidth,NewHeight/2,0,sh2,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==0 echo n9=SelectEvery(12,9).ComplementParity().Spline36Resize(NewWidth,NewHeight/2,0,-sh2,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==0 echo n10=SelectEvery(12,10).ComplementParity().Spline36Resize(NewWidth,NewHeight/2,0,sh2,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==0 echo Interleave(n0,n1,n2,n3,n4,n6,n7,n8,n9,n10) >> "%AVS_FILE%"
IF %PAL%==0 echo Weave() >> "%AVS_FILE%"
IF %PAL%==0 echo AssumeFPS(25,1, true) >> "%AVS_FILE%"
IF %PAL%==1 echo n0=SelectEvery(10,0).Spline36Resize(NewWidth,NewHeight/2,0,-sh1,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==1 echo n1=SelectEvery(10,1).Spline36Resize(NewWidth,NewHeight/2,0,sh1,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==1 echo n2=SelectEvery(10,2).Spline36Resize(NewWidth,NewHeight/2,0,-sh1,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==1 echo n3=SelectEvery(10,3).Spline36Resize(NewWidth,NewHeight/2,0,sh1,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==1 echo n4=SelectEvery(10,4).Spline36Resize(NewWidth,NewHeight/2,0,-sh1,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==1 echo n5=SelectEvery(10,4).ComplementParity().Spline36Resize(NewWidth,NewHeight/2,0,sh2,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==1 echo n6=SelectEvery(10,5).ComplementParity().Spline36Resize(NewWidth,NewHeight/2,0,-sh2,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==1 echo n7=SelectEvery(10,6).ComplementParity().Spline36Resize(NewWidth,NewHeight/2,0,sh2,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==1 echo n8=SelectEvery(10,7).ComplementParity().Spline36Resize(NewWidth,NewHeight/2,0,-sh2,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==1 echo n9=SelectEvery(10,8).ComplementParity().Spline36Resize(NewWidth,NewHeight/2,0,sh2,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==1 echo n10=SelectEvery(10,9).ComplementParity().Spline36Resize(NewWidth,NewHeight/2,0,-sh2,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==1 echo n11=SelectEvery(10,9).Spline36Resize(NewWidth,NewHeight/2,0,sh1,Wt,Ht) >> "%AVS_FILE%"
IF %PAL%==1 echo Interleave(n0,n1,n2,n3,n4,n5,n6,n7,n8,n9,n10,n11) >> "%AVS_FILE%"
IF %PAL%==1 echo Weave() >> "%AVS_FILE%"
IF %PAL%==1 echo AssumeFPS(30000,1001, true) >> "%AVS_FILE%"
echo SSRC(48000) >> "%AVS_FILE%"
echo (Conv ^&^& WasYV12) ? ConvertToYV12(interlaced=true) : last >> "%AVS_FILE%"
echo trim(0,0) >> "%AVS_FILE%"
echo #Subtitle(info_ERR,align=2) >> "%AVS_FILE%"
@REM ------------------------------------------------------------


The script uses wavi.exe to determine the original content (PAL/NTSC and SD/HDV). You have to correct the path to wavi.exe to point to where you have stored wavi (the line that begins as: set WAVI_EXE=C:\...)

You can download Wavi from:
http://sourceforge.net/project/showfiles.php?group_id=196137

Note that DV content is BFF, HDV content is TFF and content from a DVD is usually TFF.

Hope this will help.