PAL to NTSC Conversion [Archive]

Aurelius

2nd May 2007, 14:43

Thanks,
I did read that but it left out some explanation.
If I understand this right, here is what I have gleaned off the net:
1. Encode in progressive @ 25fps
a. Pal is 25fps, but might be interlaced, so use decomb plugin with avisynth script.
2. In avisynth:
a. Run ConvertToYUY2 before resize.
3. In Cinema Craft Encoder v2.70.02.12 I am unchecking DVD so I can encode in 25fps and am using these settings:
a. http://www.eggshellskull.com/pal2ntsc/
4. Run DGPulldown.exe and change from 25 to 29.97 FPS
a. Check Top Field First
b. Set Timecodes
c. Set Drop Frames
5. Import demuxed AC3 file from dgmpgdec149rc1 and video from pulldown into encore to author.

Problem is encore doesn't display the darn video after pulldown runs? Its just green?

I am also having issues with the final video file being a different length then the audio?

Thanks so much!

~bT~

2nd May 2007, 16:21

^ to correct audio (only if its 2.0) check this: http://forum.videohelp.com/viewtopic.php?t=327890

for muxing, look here: http://forum.doom9.org/showthread.php?t=125363

Awatef

2nd May 2007, 18:55

Not so fast my friend.
Doing a pulldown from 25 to 29.97 is no good!
You'll have to encode directly in 29.97fps in CCE.

Here's how the avisynth script should basically look like:

AVIsource("filename.avi")
ConvertToYUY2()
ConvertFPS(59.94)
SeparateFields()
SelectEvery(4,0,3)
Weave()
BicubicResize(720,480)

This method is the simplest, since you won't have to change the duration of the audio track.

Aurelius

2nd May 2007, 19:16

Thanks Awatef,
Can you explain what each step does that way I can understand this better? Why do you suggest to change frame rate before the encode? I thought it was best to encode at 25fps (film) as the telecine process makes the mangled new frames dont resize well during the encode as the scan lines get blended together?

Thank you!

Awatef

2nd May 2007, 21:49

Well, the telecine you're talking about can't be made from 25fps but from 24.975fps (25 frames per 1001ms as 29.97fps is 30 frames per 1001ms).

If you're going to go through this, you'll have to adjust the audio so that it stays in synch, which leads us to a better solution, which is go straight back to 23.976fps, encode in this framerate and apply 3:2 pulldown.

The solution I gave you may not be best for video quality (introduces blending), but it's the less tricky of all.
Here a basic explanation of the script (changed to adapt to videos that do not have 480 vertical resolution / assumes the video is in progressive form)

BicubicResize(720,480) => Resize to NTSC DVD resolution
ConvertToYUY2() => necessary for ConvertFPS to work
ConvertFPS(59.94) => framerate conversion using blending
SeparateFields() => split every frame into 2 fields
SelectEvery(4,0,3) => Pick one field out of every frame
Weave() => Interlace the video

Good luck

Aurelius

2nd May 2007, 22:21

Thanks for the info!
It is needed then to interlace after in your example?

...which leads us to a better solution, which is go straight back to 23.976fps, encode in this framerate and apply 3:2 pulldown...

Can you elaborate on this?

Thank you very much!

Aurelius

3rd May 2007, 01:05

Awatef,
You hit the mail on the head. The audio was perfectly in sync. Problem is the quality is bad though, where ever there is motion you get those funny interlaced effects on the edges of the people/things moving. What can I do, whether or not its slower to make the quality perfect?

Thank you!

45tripp

3rd May 2007, 03:20

Doing a pulldown from 25 to 29.97 is no good!

Why ever not?
It's my understanding dgpulldown was designed to do exactly that.
Handles 1000/1001
I don't see how doing unnecessary colour space conversions and blending is better.

Slowdown to 23.976 is done with avisynth either using
assumefps, changefps, or convertfps.
http://avisynth.org/index.php?page=FPS
Audio processing needed.

Can't comment on encore. I don't use it.
It really should work!
Perhaps something went wrong.

Anyway worst case scenario, you use another tool to author.
If you want encore menus, i suppose author a mock dvd with menus and use vobs from other authoring program, fixing with something like vobblanker, pgcedit.

Don't have to do any of this myself.
Pal land, where pal stays pal and ntsc stays ntsc.

gl

manono

3rd May 2007, 10:48

Not so fast my friend.
Doing a pulldown from 25 to 29.97 is no good!
You'll have to encode directly in 29.97fps in CCE.

Eh? Awatef is a bit behind the times, or isn't familiar with DGPulldown, or something. Many hundreds (thousands?) of people use DGPulldown set for 25->29.97fps.

Here's a short CCE PAL2NTSC guide I wrote the other day. It was for a 25fps AVI being converted to NTSC DVD, but will work for you:

http://forum.videohelp.com/viewtopic.php?p=1695973&highlight=cce#1695973

Start reading below that AviSynth script which is for that guy's AVI. Make yourself your 25fps, 720x480 script and test it first in VDub(Mod) before sending to CCE. That guide to which you linked is OK, but has some glaring mistakes. He seems to recommend deinterlacing just for the heck of it, which is an awful suggestion. You don't need to close the GOPs. He's using some old version of CCE which doesn't have the same settings set up the same way as yours (and mine).

a. Pal is 25fps, but might be interlaced, so use decomb plugin with avisynth script.

If it's really interlaced, some version of Awatef's script will be needed, and you'll encode for 29.97fps interlaced. If the video isn't interlaced, don't deinterlace it. Look at the frames. If you don't see interlacing, it's not interlaced.

I am also having issues with the final video file being a different length then the audio?

Based on what? How are you determining the video length? Don't rely on a player to give you the correct length. And if some authoring program doesn't like the result of the DGPulldown, use a different one.

Awatef

3rd May 2007, 11:13

@ Aurelius
Yes, the output is interlaced and ment to be shown on TV. It should look pretty good on TV, but of course not very good on your PC monitor (Even though choosing "Bob" in PowerDVD and putting 60Hz as refresh rate should produce a very similiar result to what you'll get on TV)

The progressive way will have a script like this:

AssumeFPS(23.976) => slowdown to NTSC Film framerate
BicubicResize(720,480)

You encode progressive in CCE and then apply DGpulldown. The video quality will be then perfect both on TV and on PC.

For the audio, you'll have to perform a slowdown so that the new duration is 104,271% of the original PAL duration.
BeSweet (via the BeLight GUI) can do this, but quality won't be perfect. Perfect conversion can be done with commercial software like Prosoniq TimeFactory or WaveLab 6 (using the DIRAC engine), since their pitch correction is flawless.
Here is how you do it in BeLight:
- "File \ Add Files" to add the audio track
- If your audio is not already in 48KHz, check "Output Sampling Rate" and put 48000
- Click on "Advanced Settings"
- Check "Convert frame rate from" and put 25000 to 23976 fps
- Choose "AC3" or "WAV/PCM" (depends on your preferences)
And then you start processing.

@ manono/immersion
May be I'm a bit behind the times, but pulldown from round 25fps sounds tricky. He'll have to drop fields somewhere, making the pulldown irregular. That's probably why his software rejected the input.

Boulder

3rd May 2007, 11:25

@Awatef: read the DGPulldown thread and you'll see that a 25->29.97fps pulldown will work just fine :) No need to fiddle with the audio or do any slowdown operations for the video.

manono

3rd May 2007, 11:26

He'll have to drop fields somewhere, making the pulldown irregular.

I came back 20 minutes later to amend my post so it didn't sound so harsh. I figured you meant that script for a true interlaced source, where this is (I think) a progressive source encoded for PAL as interlaced. I apologize, my friend, for sounding rude.

About dropping fields; I'm afraid I don't understand. If you mean dropping unique fields that were part of the original video, then no. Nothing gets dropped. Fewer fields are added for playback, and in a different pattern, as compared to standard 2:3 pulldown. But even 2:3 (or 3:2 if you prefer) pulldown isn't so regular to begin with. As PAL people know better than even us NTSC people, playing the fields in a 3 2 3 2 3 2 pattern introduces a slight stutter. the 25->29.97fps pulldown goes 3 2 3 2 2 3 2 3 2 2 (or something like that, I forget exactly), and it's just a different irregular playback.

But the whole idea (or one of them, anyway) is that by applying that pulldown, you can use the untouched audio and subtitles (if any). Yes, slowing the video to 23.976fps is another and perhaps better way to do it, but does necessitate reencoding the audio.

Awatef

3rd May 2007, 12:11

@ Boulder
Fact is that it doesn't always work as you can see with this guy (this kind of pulldown is just not standard).

@ manono
Sorry, I didn't express myself well. I wasn't talking about the general irregularity, I was talking about the irregularity of the pulldown pattern.
For 23.976 to 29.97, it will be 3:2 all the way through. But for something like 25 to 29.97, he'll have to change the pattern regularly.
I'll try to explain:
For 25p to 30i, I'll just apply ABCDE => AA-BB-BC-CD-DE-EE (2:3:2:2:3?!).
But for 25p to 29.97i, I'll begin with the 30i 2:3:2:2:3 pattern but after 1001 fields I'll have to break the pattern by skipping one field to get 29.97fps and not 30. This field that will be skipped will put the video upside down, introducing a field shifting until the next 1001st field is dropped.
As you can see this is a pretty sophisticated pattern.

Boulder

3rd May 2007, 12:30

Question is, does the resulting dgPulldowned m2v file open fine in DGIndex or in VirtualDubMod?

manono

3rd May 2007, 13:08

This field that will be skipped will put the video upside down, introducing a field shifting until the next 1001st field is dropped.

You've lost me again. I know you don't mean that the video literally becomes upside down. And I know you don't mean that you get the wrong field order every 1001 frames, so that it begins to play with a stutter. No, what you're suggesting is, in effect, meaningless, except for the probably not noticeable brief pattern change every 1001 frames because of the missing field. A standard interlaced CRT television will have no problem playing it. And a good progressive scan DVD player outputting to an HDTV will have no problem with the shifted fields. A bad flag reading DVD player sending to an HDTV might have trouble playing it well, but it'll still look no worse than what your script produces. And flag readers even have trouble with hard telecine, which is much more common.

In any event, surely you're not suggesting that your script above, which creates blended fields, and interlaces a previously progressive video, and encodes nearly 20% more frames (29.97/25=1.1988) frames for the same file size (a single DVDR probably), thus degrading the video quality significantly, is a better solution? Maybe you could play around with some PAL2NTSC conversions as an experiment to see how easy and useful using DGPulldown for 25->29.97fps truly is.

Guest

3rd May 2007, 13:36

@Awatef

Your arguments are just plain wrong. Having irregular pulldown is very common, especially in anime. It is fully supported by the MPEG2 standard. DGPulldown just capitalizes on the idea. There is no problem with field inversion that you claim, because there is a top field first flag that toggles along with the repeat first field flag. You're spreading disinformation.

Awatef

3rd May 2007, 14:12

OK guys, you got me wrong again.
It is a beautiful idea to have direct 25 to 29.97fps pulldown and is truly the fastest way to get decent quality, and the video quality WILL be better than the blending method, there is absolutely no doubt about that.
The point is, this pulldown method is very tricky and as you can see not 100% compatible with existing software and/or hardware, that's all there is to it.
I'm not saying there is a problem with the field inversion or whatever is involved in the pulldown process ;)

Guest

3rd May 2007, 14:33

The point is, this pulldown method is very tricky It's not "tricky" at all. It is fully supported by the MPEG2 specification and is in common use.

as you can see not 100% compatible with existing software and/or hardware, that's all there is to it. No I don't see that. One person is having an issue convincing his encoder to accept the input (a problem that is known and for which a solution is available). That's it; that's your only point so far. Simply put, you are grossly overstating your case.
I'm not saying there is a problem with the field inversion or whatever is involved in the pulldown process ;) But you did say that:

This field that will be skipped will put the video upside down, introducing a field shifting until the next 1001st field is dropped.

Awatef

3rd May 2007, 14:48

If there is a solution to that, it would be nice if you would post it, because I don't know any, and you would save the guy a lot of trouble.

As for the field inversion thing, I think manono got me right on this point, you're considering me as a 1-0 computer donald, I'm not ;)
I was just pointing out how this "tricky" thing works and how complicated it is compared to normal 3:2 pulldown.

Guest

3rd May 2007, 15:11

If there is a solution to that, it would be nice if you would post it, because I don't know any, and you would save the guy a lot of trouble. He also wrote:

I am also having issues with the final video file being a different length then the audio? That tells me he didn't follow the process correctly. If he is motivated to follow through with it, I'll be happy to help.

I was just pointing out how this "tricky" thing works and how complicated it is compared to normal 3:2 pulldown. But you're wrong. It is not tricky or complicated. It uses exactly the same MPEG2 syntax elements. And don't forget you said this:

Doing a pulldown from 25 to 29.97 is no good!

Awatef

3rd May 2007, 16:23

I guess we'll have to blame NTSC engineers for standardizing "no good" framerates like that :D

delacroixp

4th May 2007, 07:58

I guess we'll have to blame NTSC engineers for standardizing "no good" framerates like that :D
You have to blame someone... they're probably as good as any else...

:):D:eek:
Pascal

btw
I'm from PAL land and PAL heaven... but NTSC rocks for fast-paced, action movies... 5 FPS do make a difference...
Since I've got Superman vision... I'm waiting for 100 FPS... bring it on IMAX...

PhillipWyllie

11th May 2007, 08:06

How about this script from the avisynth manual:
# Take a 24fps progressive input clip and apply 3:2 pulldown,
# yielding a 30fps interlaced output clip
AssumeFrameBased
SeparateFields
SelectEvery(8, 0,1, 2,3,2, 5,4, 7,6,7)
Weave

Make sure rate conv isn't selected in CCE. You could also let CCE do the pulldown( I don't know if it's any good). If CCE is then enoding will be more efficient.

Guest

11th May 2007, 13:44

How about this script from the avisynth manual:
# Take a 24fps progressive input clip and apply 3:2 pulldown,
# yielding a 30fps interlaced output clip
But PAL is 25 fps, not 24 fps (or 23.976 fps).

PhillipWyllie

11th May 2007, 15:42

Missed a line:
# Take a 24fps(or 23.976fps) progressive input clip and apply 3:2 pulldown,
# yielding a 30fps(or 29.970fps) interlaced output clip
assumefps(24)#or assumefps(23.976)
AssumeFrameBased
SeparateFields
SelectEvery(8, 0,1, 2,3,2, 5,4, 7,6,7)
Weave

delacroixp

11th May 2007, 18:18

# Take a 24fps(or 23.976fps) progressive input clip and apply 3:2 pulldown,
# yielding a 30fps(or 29.970fps) interlaced output clip
assumefps(24)#or assumefps(23.976)
AssumeFrameBased
SeparateFields
SelectEvery(8, 0,1, 2,3,2, 5,4, 7,6,7)
Weave
Are you saying that this works by trickery and deception... that is so low... almost as kewl as Rec (http://en.wikipedia.org/wiki/Recursion)urs (http://www.csi.uottawa.ca/~holte/T26/rec-foreword.html)ion (http://www-128.ibm.com/developerworks/linux/library/l-recurs.html).

:):D:eek:
Pascal