720x480 NTSC ---to---> 720x576 PAL

[provato]

Hi video Gurus, I need a little help converting/encoding a VOB file (DVD 20 min episode) which is 720x480 NTSC (DAR=4:3)

1. I want to use megui or handbrake with the x264 encoder, to make it an mp4 file in 1200 kbps (I prefer megui which gives me the option to use avisynth scripts, but handbrake would be awesome if x264 codec could do the resizing!)
2. I already have chosen the preferred method for 25 fps ("changeFPS (25.00)" either in avisynth script or inside the encoder - no blending)
3. I need to cut (crop) 8 pixels right and 8 pixels left (to get rid of black borders on the sides)
4. I want the final SAR outcome of the PAL mp4 video to be 720x576 (exactly like the PAL DVD).
5. I don't care what the PAR will be, as long as the picture doesn't come out stretched!!!
6. I want the the DAR of the final PAL mp4 video to be 4:3 (again, I don't want the picture to be stretched)

...7. I need the final mp4 video to be progressive, but I have already solved that with Yadif!!! It does a perfect 100% job for me in the ntsc video

Ideas? (Or even better a final solution or script to use?)

[DB83]

The first question really is why ?. Most PAL equipment can play NTSC source without the need for conversion.

From your points.

3. By all means crop away the black bars but if you play the final vid at the correct AR, your player will add bars anyway.
4. Not neccessary. The mp4 does not require a SAR of 720*576 because its pixels will be sqaure whereas the VOB's pixels are non-square
5. PAR must be 1:1 AFAIK and even if your codec supports non-square the DAR will override it.
6. For 4:3 DAR just crop (if you insist) and resize to 640*480

[hello_hello]

Almost everything in your post seems "wrong" to me, or at least I'd do it differently, unless there's a specific need in your case.

Why do you need to convert to PAL? Given you're converting to MP4 I can't see any reason for it myself. There's no NTSC or PAL once you convert to MP4. If a player can play x264 encoded video in an MP4 file it'll play it regardless of the resolution, however....
Not all players support anamorphic video in MP4 files, so while you can resize it to 720x576 and set a 4:3 aspect ratio, it mightn't display correctly. I always resize DVDs to square pixels when encoding so they do. For 4:3, whether it be NTSC or PAL, I generally resize to 640x480, but if you don't want to resize down (even though it'll make virtually no difference) you could resize to something like 720x540.

When resizing 4:3 DVDs with MeGUI, that generally involves applying the desired cropping, setting the desired 4:3 resizing (ie 640x480), then adjusting the cropping as required until the aspect ratio distortion is very close to 0%. If you have to crop some extra video too that's perfectly normal if you want an exact 4:3 aspect ratio. The last PAL 4:3 video I encoded required cropping around 18 pixels from each side to remove all the crud. If memory serves me correctly, to resize to 4:3 dimensions without distorting the picture it also required cropping 8 pixels of video from both the top and bottom.
To convert to square pixels with MeGUI, don't enable anamorphic encoding. For Handbrake, use "Anamorphic None". If you don't care what the pixel aspect ratio will be, I'd resize to 4:3 dimensions and use square pixels.

The way I understand it, ChangeFPS adds or drops frames to achieve a new framerate, which means the output mightn't be perfectly smooth. When converting 24fps to 25fps, one frame will be repeated every second. AssumeFPS should simply speed it up. However as you said the video is interlaced, that means for NTSC it can only be 29.970fps, which means the conversion to 25fps by dropping frames mightn't be pretty. At least not when it comes to smooth motion.

If you want the final MP4 to be progressive, try the option "Yadif (with Bob)" from MeGUI's choice of de-interlacers. It'll de-interlace to 59.940/50fps progressive rather than 29.970/25fps progressive. 59.940fps progressive isn't NTSC and 50fps progressive isn't PAL, but I can assure you motion will look much smoother. If you think Yadif does a perfect job of de-interlacing check out the comparison encodes here. Yadif at 25fps easily looks the worst. If you compare your video card/TV's de-interlacing of the original video to Yadif at 50fps, you'll probably find they're pretty similar. QTGMC at 50fp is even better.

Why do you want to make the bitrate 1200kbps? x264 has a quality based encoding method where you pick the quality and the bitrate will be whatever it needs to be. CRF18 is roughly where the x264 encoder is considered to be "transparent". Choosing a bitrate generally also involves 2 pass encoding and you don't know what the quality will be. CRF encoding only requires a single pass, so it's also faster.

[provato]

The first question really is why ?. Most PAL equipment can play NTSC source without the need for conversion.

From your points.

3. By all means crop away the black bars but if you play the final vid at the correct AR, your player will add bars anyway.
4. Not neccessary. The mp4 does not require a SAR of 720*576 because its pixels will be sqaure whereas the VOB's pixels are non-square
5. PAR must be 1:1 AFAIK and even if your codec supports non-square the DAR will override it.
6. For 4:3 DAR just crop (if you insist) and resize to 640*480

To answer your questions:

why? ---> For educational purposes. I want to compare two anamorphic encodings of the same video: Both will be 720x576 PAL 4:3. But one will be "born" from a PAL DVD, and the other from the NTSC DVD.

3. ---> The videos are going to be viewed in windowed mode. Not in fullscreen. So I don't want black bars to be shown anywhere in this window.

4. ---> I think I covered this with the "why?" answer

5. ---> Why is there an "anamorphic encoding" option in the x264 then??

6. ---> Up until now, the 640x480 way was the one I chose for NTSC DVDs --> PAL MP4 conversions. This is the "downscale" solution as I call it. I just need to try the "upscale" solution (if there is one)

Almost everything in your post seems "wrong" to me, or at least I'd do it differently, unless there's a specific need in your case.

Why do you need to convert to PAL? Given you're converting to MP4 I can't see any reason for it myself. There's no NTSC or PAL once you convert to MP4. If a player can play x264 encoded video in an MP4 file it'll play it regardless of the resolution, however....
Not all players support anamorphic video in MP4 files, so while you can resize it to 720x576 and set a 4:3 aspect ratio, it mightn't display correctly. I always resize DVDs to square pixels when encoding so they do. For 4:3, whether it be NTSC or PAL, I generally resize to 640x480, but if you don't want to resize down (even though it'll make virtually no difference) you could resize to something like 720x540.

When resizing 4:3 DVDs with MeGUI, that generally involves applying the desired cropping, setting the desired 4:3 resizing (ie 640x480), then adjusting the cropping as required until the aspect ratio distortion is very close to 0%. If you have to crop some extra video too that's perfectly normal if you want an exact 4:3 aspect ratio. The last PAL 4:3 video I encoded required cropping around 18 pixels from each side to remove all the crud. If memory serves me correctly, to resize to 4:3 dimensions without distorting the picture it also required cropping 8 pixels of video from both the top and bottom.
To convert to square pixels with MeGUI, don't enable anamorphic encoding. For Handbrake, use "Anamorphic None". If you don't care what the pixel aspect ratio will be, I'd resize to 4:3 dimensions and use square pixels.

The way I understand it, ChangeFPS adds or drops frames to achieve a new framerate, which means the output mightn't be perfectly smooth. When converting 24fps to 25fps, one frame will be repeated every second. AssumeFPS should simply speed it up. However as you said the video is interlaced, that means for NTSC it can only be 29.970fps, which means the conversion to 25fps by dropping frames mightn't be pretty. At least not when it comes to smooth motion.

If you want the final MP4 to be progressive, try the option "Yadif (with Bob)" from MeGUI's choice of de-interlacers. It'll de-interlace to 59.940/50fps progressive rather than 29.970/25fps progressive. 59.940fps progressive isn't NTSC and 50fps progressive isn't PAL, but I can assure you motion will look much smoother. If you think Yadif does a perfect job of de-interlacing wait till you've used QTGMC. Check out the comparison encodes here. Yadif at 25fps easily looks the worst.

Why do you want to make the bitrate 1200kbps? x264 has a quality based encoding method where you pick the quality and the bitrate will be whatever it needs to be. CRF18 is roughly where the x264 encoder is considered to be "transparent". Choosing a bitrate generally also involves 2 pass encoding and you don't know what the quality will be. CRF encoding only requires a single pass, so it's also faster.

Thanks for the QTGMC deinterlacing solution, I didn't know of this one.

But I need the video (mp4) to be 25fps, in order to apply a second 25fps audio-language dub (the final-final-final video will be dualdub --> both english and another language)

Also, from my personal experience (in animation content-cartoon that this video is) I get better results (closer to DVD) from 2 pass encoding in 1200 kbps.

Also I would like to know more about the "AssumeFPS" way... Is that what handbrake does when you change the FPS to 25?

[filmboss80]

I want to compare two anamorphic encodings of the same video...

But you will have degraded the NTSC video during the re-encode to PAL. If you start off without a level playing-field, how do you expect to make any sort of valid assessment?

[DB83]

5. I would NEVER consider an encoding to 4:3 from any source to be anamorphic. You need to look up the term. (Hint 16:9)

[provato]

Ok, thanks guys. I seem to understand better now that (640x480 + square pixels) for NTSC to PAL conversions is better.
Any hint on how to use "AssumeFPS" for 29,97 to 25 fps conversion? (in megui preferably)
Also, is that what handbrake does when I change the "FPS" setting to 25?

And last but not least, I saw from handbrake's log that it uses yadif deinterlacer. Any way to make it use QTGMC instead?

[jagabo]

NTSC to PAL (or vice versa) conversions can be rather complex if you want the best results. There isn't one single method that works best for all sources. And to some extent personal preferences come into play. There are many many threads here dealing with the issues. Search through the forums and you'll find them. For the most part, simple GUIs like Handbrake don't give good conversions. You need to learn how to use AviSynth and how to process different sources.

It would be best if you uploaded a sample of your NTSC source (not reencoded).

[FulciLives]

Converting 29.970fps NTSC to 25fps PAL is like the hardest of all the possible PAL <---> NTSC conversions.

If you are lucky the NTSC source can be restored to 23.976fps and then you can simply speed it up to 25fps but if the NTSC source is true interlaced, meaning it can't be made progressive 23.976fps, then you'll get a pretty ugly conversion regardless of how you do it.


- John "FulciLives" Coleman

[provato]

Ok jagabo and FulviLives, here is a sample of the vob file (without re-encoding):

http://www.mediafire.com/watch/81l6aoll7e2r5em/VTS_01_1.VOB.12.VOB

I think that handbrake does a fine job (close to the DTVRips of the cartoon I have captured from TV) when I set it to change the FPS to 25. But please see if you make smth better out of the VOB video, with NTSC to PAL conversion (with avisynth or whatever GUI...)

[manono]

2. I already have chosen the preferred method for 25 fps ("changeFPS (25.00)" either in avisynth script or inside the encoder - no blending)

No, it's not the preferred method at all. It's one step above blending. Ordinarily you speed up NTSC to go to PAL. It's also the better bet to match with the PAL audio source you have (no guarantees on that, though).

Any hint on how to use "AssumeFPS" for 29,97 to 25 fps conversion? (in megui preferably)

You don't go from 29.97->25fps. You IVTC it to 23.976fps first and then speed it up using AssumeFPS(25).

I think that handbrake does a fine job (close to the DTVRips of the cartoon I have captured from TV) when I set it to change the FPS to 25.

I doubt it.

[jagabo]

Ok jagabo and FulviLives, here is a sample of the vob file (without re-encoding):

http://www.mediafire.com/watch/81l6aoll7e2r5em/VTS_01_1.VOB.12.VOB

Your lucky, this is the simplest case. The source is telecined film. It should be inverse telecined to restore the 23.976 fps progressive frames. Then sped up to 25 fps for PAL. That will require that the audio be sped up proportionally. If you're making a DVD you can just resize the 720x480 frame to 720x576. This is the way most commercial PAL movie DVDs are made.

Another way to encode the video is to leave the frame rate at 23.976 and add 2:2:2:2:2:2:2:2:2:2:2:3 pulldown flags (ie, one field in every 12 frame is duplicated, 12 frames becomes 25 fields, 24 frames becomes 50 fields, ie 24 fps becomes 25 fps. Every 500 fields you have to add one more to make up for the difference between 23.976 and 24 fps. Use DgPulldown for this, it's easy). That will result in two tiny jerks every second but doesn't require changing the audio.

Attached is an example of the first method (IVTC, speedup, AVC in MKV), no audio. I did a little other cleanup too. It could use more.

[hello_hello]

jagabo,
what did you use for the "cleanup"? I thought it did a reasonable job.

For provato:
To change the frame rate as jagabo did using MeGUI.
Open the video and let MeGUI index it. When the Script Creator window opens, switch to the Filters tab. You could let MeGUI analyse the video, but in this case it gets it wrong. MeGUI decides it's "hybrid film/interlaced, mostly interlaced". That'll try to convert the video to 29.970fps progressive which will result in lots of frame blending. Instead you should change it to either "hybrid film/interlaced, mostly film" or simply to "Film". Both will take it back to a 23.976fps frame rate. Use TIVTC as the deinterlacing method.
If you add AssumeFPS(25) to the end of the script, that'll speed it up to 25fps.

[jagabo]

what did you use for the "cleanup"? I thought it did a reasonable job.

I didn't spend much time on it. Annotated for provato:

Mpeg2Source("VTS_01_1.VOB.12.d2v", CPU=2, Info=3)  # get the source

# IVTC
TFM(d2v="VTS_01_1.VOB.12.d2v") # progressive frames (29.97 fps)
TDecimate() # remove duplicates (23.976 fps)

Crop(14,0,-6,-0) # remove borders/noise
ColorYUV(off_y=-4) # levels a little lower
UnDot() # remove some dots
RemoveSpots() # remove some spots that appear on only one frame
BicubicResize(480,480) # blur away some of the vertical line noise
MergeChroma(aWarpSharp2(depth=5),aWarpSharp2(depth=20)) # sharpen edges and colors a bit
McTemporalDenoise(settings="low") # denoise, could have used more but leaving a little noise reduces posterization
Sharpen(0.5,0.2) # sharpen vertical edges a bit more than  horizontal edges
Toon(0.5) # clean up lines
nnedi3_rpow2(2,cshift="Spline64Resize", fwidth=704, fheight=576) # resize, slight AR error
aWarpSharp2(depth=5) # sharpen/thin edges again
Sharpen(0.2,0.0) # sharpen horizontal edges a bit
Toon(0.5) # clean up lines some more
AddBorders(8,0,8,0) # could have left this out
AssumeFPS(25) # speed up to 25 fps

[provato]

First of all, thank you all for your time and work. This really means a lot to me.
Especially thank you jagabo, for your great great great work on the vertical lines and the "artifacts" (this is really unique and amazing to me!) and also thank you for the avs comments - they are really helpful
And thank you hello_hello, for the 29,97--->23,97 in megui explanation (and the "assumeFPS" speeding up)

So.... it is possible to convert 720x480 NTSC to 720x576 PAL 4:3 !!!! (as long as the ntsc source is telecined)

But, don't forget I am a newbie, so I need some explaining:

1.How do you know when a vob (NTSC DVD-video) is telecined?
2.I know what TDecimate does... But what does "TFM" exactly do if you put it before TDecimate?
3.Why did you "addborders" in the end? Was that in order to maintain 720x576? Or could it be left out and stretch a bit to achieve 720x576? (assuming that you had spline resize to 720x... instead of 704x... earlier in the script)


Don't worry about the audio. I demux both language-tracks that I have and I synchronize them in audacity, so that they match the 25fps PAL video almost flawlessly (without changing tone-key, only speeding up the rythm in the NTSC audio)

[hello_hello]

ColorYUV(off_y=-4) # levels a little lower

Ahh..... I thought it was a little darker, but I wasn't sure if I was imagining it.

[hello_hello]

1.How do you know when a vob (NTSC DVD-video) is telecined?

There's instructions on how to tell after opening the video using VirtualDub at the bottom of this page, however you can do exactly the same thing after indexing the video using MeGUI and stepping through frames using the preview. The pattern where you see obvious "interlacing" artefacts (or not) helps to determine if the video is progressive, interlaced, or telecine.

Your particular sample doesn't follow the usual rule/pattern of 3 progressive frames followed by two interlaced frames though. It is telecine, but the pattern is more like four progressive frames and one interlaced frame. Originally I thought that was because the video is actually 12fps (as opposed to 24fps) because after IVTC (get MeGUI's script creator to add "Film/TIVTC" de-interlacing and use the preview button), if you step through the video one frame at a time you'll see that almost every frame is repeated. However I just realised it's "almost" as opposed to "every". The sample jagabo uploaded is the same. I'll defer to jagabo's wisdom on this one as to whether it means the usual IVTC isn't quite right, but I suspect it's actually not.

So...... half an hour or so of messing around later (because I live in PAL land and really don't know what I'm doing when it comes to IVTC either) I came up with this, which I think is actually more correct than the usual 3:2 pulldown removal, because the original frame rate is 11.988fps with every frame repeated to produce 23.976fps.
I'll defer to his wisdom, but, can you try this out jagabo?

TFM.TDecimate(cycle=10, cycleR=6) #takes it back to 11.988fps progressive
SelectEvery(1,0,0) # duplicates every frame for 23.976
AssumeFPS(25) # speed it up for PAL

The above seems better than standard IVTC as it results in more fluid motion, and the interlacing lines around his mouth in frame 593 are finally gone (it's the little things which annoy me), but....
What I can't seem to do is find a TDecimate cycle which takes it straight to 23.976fps with every single frame repeated once. Hence going to 11.988fps first and then adding the repeated frames back manually.

I know what TDecimate does... But what does "TFM" exactly do if you put it before TDecimate?

It matches up the telecined fields to produce progressive frames again. TDecimate then removes the duplicate frames. Or something like that.

[manono]

Your particular sample doesn't follow the usual rule/pattern of 3 progressive frames followed by two interlaced frames though.

Because that sample was drawn at 12fps. But you can bet the entire thing won't be that way. Some might be 8fps or even less, and there are surely some 24fps portions. It's meant to be viewed at 24fps so a standard IVTC is what you want. TIVTC has one for anime that keeps the 12fps stuff as 2 2 2 2, rather than 1 3 1 3 - more jerky when not being decimated correctly.

TFM().TDecimate(Mode=1)

The sample didn't need it but it's usually a good idea when working with anime.

[hello_hello]

Your particular sample doesn't follow the usual rule/pattern of 3 progressive frames followed by two interlaced frames though.

Because that sample was drawn at 12fps. But you can bet the entire thing won't be that way. Some might be 8fps or even less, and there are surely some 24fps portions. It's meant to be viewed at 24fps so a standard IVTC is what you want. TIVTC has one for anime that keeps the 12fps stuff as 2 2 2 2, rather than 1 3 1 3 - more jerky when not being decimated correctly.

TFM().TDecimate(Mode=1)

The sample didn't need it but it's usually a good idea when working with anime.

So that's what the checkbox in MeGUI's script creator labelled "Source is Anime" does!! I'd sometimes wondered but as I never encode animation......

[provato]

Your particular sample doesn't follow the usual rule/pattern of 3 progressive frames followed by two interlaced frames though.

Because that sample was drawn at 12fps. But you can bet the entire thing won't be that way. Some might be 8fps or even less, and there are surely some 24fps portions. It's meant to be viewed at 24fps so a standard IVTC is what you want. TIVTC has one for anime that keeps the 12fps stuff as 2 2 2 2, rather than 1 3 1 3 - more jerky when not being decimated correctly.

TFM().TDecimate(Mode=1)

The sample didn't need it but it's usually a good idea when working with anime.

So what did you change manono in jagabo's script? Only the (mode=1) part?

Sorry for asking but I read here:

http://avisynth.org.ru/docs/english/externalfilters/tivtc.htm

that "mode=1" is for anime or cartoon.

I am curious too. Is that really what MeGUI does when you check the box "Source is anime"?

[jagabo]

Yes, there are probably panning shots that are at 23.976 fps. It's very common for the character animations to be done at 12 fps to reduce the number of cells that have to be painted; each cell becomes two 24 fps film frames. Then the panning shots are at 24 fps to get smoother motion; the cell are moved for each film frame.

By the way, this is also why the video doesn't show the typical 3:2 progress:interlaced frame pattern when viewing frames. One of the interlaced frames is a field from two film frames but those two frames are identical -- so the frame looks progressive rather than interlaced.

[provato]

Ok I have another problem with DAR this time...

In the MeGUI avisynth script, I have everything like jagabo (except for the crop/resize because I don't have nnedi3_rpow2):

DGDecode_mpeg2source("VTS_01_1.d2v", info=3)
ColorMatrix(hints=true, interlaced=true, threads=0)
tfm(order=-1).tdecimate(mode=1)
crop(8, 0, -8, 0) 
Spline64Resize(720,576) # Spline64 (Sharp)
Undot() # Minimal Noise
AssumeFPS(25)

Why does the final video come out 5:4, and not 4:3 like the jagabo's video????

[jagabo]

Ok I have another problem with DAR this time...

In the MeGUI avisynth script, I have everything like jagabo (except for the crop/resize because I don't have nnedi3_rpow2):

DGDecode_mpeg2source("VTS_01_1.d2v", info=3)
ColorMatrix(hints=true, interlaced=true, threads=0)
tfm(order=-1).tdecimate(mode=1)
crop(8, 0, -8, 0) 
Spline64Resize(720,576) # Spline64 (Sharp)
Undot() # Minimal Noise
AssumeFPS(25)

Why does the final video come out 5:4, and not 4:3 like the jagabo's video????

Since you didn't set a SAR the encoder assumed square pixel -- 720:576 = 5:4. In my encoding I set the SAR to 12:11.

[provato]

Hahaha... Thank you jagabo, it wasn't that I didn't set the sar in the x264 encoder...
I just had set it to force 4:3 because I didn't know the correct aspect ratio of 720x576 video
Lol

[manono]

So what did you change manono in jagabo's script? Only the (mode=1) part?

Yes. As I mentioned, the sample didn't need it, but I've seen anime that definitely did need it.

Sorry for asking but I read here:

http://avisynth.org.ru/docs/english/externalfilters/tivtc.htm

that "mode=1" is for anime or cartoon.

Yes, and? Was there a question? Isn't anime or cartoon what you have and it might benefit from that Mode=1?

Is that really what MeGUI does when you check the box "Source is anime"?

I don't use MeGUI. You could always check the final script to see.

[provato]

Thanks Manono, everything is solved for me now
I managed to get a 720x576 4:3 PAL 25fps mp4 video file @1200 Kbps 2-pass, (just like pal DVD but progressive)

...From an NTSC DVD 720x480 4:3 29,97 fps

"Mode 1" wasn't at all needed in the end, because if I use it, I get 1 interlaced frame every 3 frames!
I just used tdecimate() instead, and now every frame of all the 20 min episodes are progressive (and very smooth )

This has been a very educational experience for me, thank you all

[manono]

... because if I use it, I get 1 interlaced frame every 3 frames!

I don't believe you. That's impossible as the 'Mode=1' only fine-tunes the decimation and has nothing to do with the field matching and post-processing. That is, even before TDecimate(Mode=1), there's no interlacing remaining. You did something wrong. Did you forget to use 'TFM' in your test script, perhaps?

An IVTC consists of two parts, the field matching (and possible post-processing) and the decimation. You need them both when working with hard telecined material.

[provato]

This really simple avs script is what I used:

DGDecode_mpeg2source("VTS_01_1.d2v", info=3)
ColorMatrix(hints=true, interlaced=true, threads=0)
tfm(order=-1).tdecimate()
crop(8, 0, -10, 0)
Spline64Resize(720,576) # Spline64 (Sharp)
Undot() # Minimal Noise
AssumeFPS(25)

If I change "tdecimate()" to "tdecimate(Mode=1)" then I get one interlaced frame (horizontal lines, duplicate) every 3 good ones in MeGUI's preview window (when I press "preview AVS Script"). I checked this again

[jagabo]

TFM() takes one field from each frame, then looks through surrounding frames looking for a complementary field to complete the frame, to make each frames progressive. With telecined film (23.976 fps film frames telecined to 29.97 fps interlaced video) the result will be 29.97 fps progressive frames. Since the original film only had 23.976 frames per second the 29.97 fps output of TFM() has one duplicate frame out of every 5 frames. TDecimate() removes that duplicate frame, leaving you with 23.976 fps. So you need TFM() and TDecimate() together to restore the original film frames at the original frame rate.

[provato]

TFM() takes one field from each frame, then looks through surround frames looking for a complementary field to complete the frame, to restore the original film frames. With telecined film (23.976 fps film frames telecined to 29.97 fps interlaced video) the result will be 29.97 fps progressive frames. Since the original film only had 23.976 frames per second the 29.97 fps output of TFM() has one duplicate frame out of every 5 frames. TDecimate() removes that duplicate frame, leaving you with 23.976 fps. So you need TFM() and TDecimate() together to restore the original film frames at the original frame rate.

Confused...

Are you saying that in the script I have posted above, I don't have "TFM() and TDecimate() together"?