Convering FILM to PAL without 4% speed-up (frame/field blending?)

[az_bont]

I've been digging through a lot of old posts on the forums searching for a way of converting FILM (23.976fps) content to PAL (25fps) without having to adjust the audio in any way. I know it's preferable to do the 4% speed-up, but I would definately prefer to leave the audio untouched if I can - either you end up with an annoying pitch shift, or the sound comes out too distorted for my liking.

I tried watching the first season of Family Guy (R2) in slow motion, and just about every flame looks blended together, but when it's playing back at full rate it seems to look fine. Is there a way I can replicate that with AviSynth?

I was fiddling with scharfis_brain's automated NTSC -> PAL conversion for hybrid clips (http://forum.doom9.org/showthread.php?t=67161&page=1&pp=20), and I tried the following line on my 23.976fps source:

assumefps(50,true).separatefields.selectevery(4,0,3).weave

I know this is normally used for 29.97fps sources, but it seemed to produce pretty decent looking video with nice, smooth motion that looked as if it was filmed at 25fps - although it was hard to tell, what with all the interlace lines running through it, so I know I could be wrong on that one.

I've tried using AviSynth's ConvertFPS() function in "blend" mode and "switch" mode, but the results didn't look all too smart. I gave scharfis_brain's mvconvertfps script a go as well, but it introduced far too many artifacts, and took a hell of a long time.

Is the above line any good, or is it only suitable for 29.97fps sources? And is there anything else anyone can suggest?

Thank you in advance, and I'm sorry about the lengthly post :).

[IanB]

AviSource("Film_24.avi")
ChangeFPS(50) # 222222222223...
SeparateFields()
SelectEvery(4, 0, 3) # TFF
Weave()This is about as good as you will get. I think you may find the motion hic twice a second is far more annoying than reclocking the audio. Otherwise buy motionperfect.

IanB

[Mug Funky]

also, convertfps'ing isn't all that noticable on a TV if it's film to PAL.

motion compensation is slow and the results are often poor, and timestretching audio (so the pitch stays the same) can't help against increased tempo.

speedup is the best way to go. of course, HDTV allows us to use 24p modes...

[scharfis_brain]

or encode as

704x576@23.976 fps Progressive and let dgpulldown do the Telecine to 50i.

I've done already some NTSC2PAL DVD conversions this way.

[LogicDeLuxe]

AssumeFPS, as you did, will speedup a 23,976 fps source. What you need to do is this:
Lanczos4Resize(704,576) #or (720,576), if your source has digital overscan
ConvertFPS(50)
SeparateFields.SelectEvery(4,1,2) #or (4,0,3) depending on encoder settings
WeaveThough make sure, your source IS progressive frames. If not, use a deinterlacer first!
If you get any artifacts other than blendings, there's probably something wrong with the field order. Check your encoder settings for that or try to change it in the avs script!
It's the best you will get without speedup and in fact, many TV stations do this blending way in order to maintain their schedule.

[Mug Funky]

actually, resizing straight to 576 will give a (very slightly) incorrect aspect ratio.

bear in mind that NTSC isn't really 480, but 525, and PAL is 625. you'll have to use the resizer's internal cropping to fix this (if you care enough... nobody will notice the difference).

i had a nice script to do this conversion, but it's at work right now... if you've got the maths you can figure it out pretty easy.

[scharfis_brain]

resizing directly between 704x480 <-> 704x576 or
between 720x576 <-> 720x480 does NOT introduce an AR error!

NTSC - PAR: 0.911
702x480 -> exact 4:3

PAL - PAR: 1.094
702x576 -> exact 4:3

[az_bont]

AviSource("Film_24.avi")
ChangeFPS(50) # 222222222223...
SeparateFields()
SelectEvery(4, 0, 3) # TFF
Weave()This is about as good as you will get. I think you may find the motion hic twice a second is far more annoying than reclocking the audio. Otherwise buy motionperfect.

IanB

I've given that a go, and it might be my imagination but I can't notice any motion hics at all. Without the interlacing I can definately notice the jerks in movement, and they're really annoying, but with the above script everything seems nice and fluid :).

I've given MotionPerfect a go but it's ridiculously slow, a pain to set up for big sources, and it introduces too many artefacts :(.

or encode as

704x576@23.976 fps Progressive and let dgpulldown do the Telecine to 50i.

I've done already some NTSC2PAL DVD conversions this way.

Would that then be a 2:2:2:2:2:2:2:2:2:2:2:3 pulldown? Would it be any better than using changefps(50,true).separatefields.selectevery(4,0,3).weave ?

And is it better to use 'changefps' as in your script or 'convertfps'? The blurring doesn't seem to be very obvious, but then I can't notice any jerking with 'changefps', although my source doesn't have very much movement in it.

AssumeFPS, as you did, will speedup a 23,976 fps source. What you need to do is this:
Lanczos4Resize(704,576) #or (720,576), if your source has digital overscan
ConvertFPS(50)
SeparateFields.SelectEvery(4,1,2) #or (4,0,3) depending on encoder settings
WeaveThough make sure, your source IS progressive frames. If not, use a deinterlacer first!
If you get any artifacts other than blendings, there's probably something wrong with the field order. Check your encoder settings for that or try to change it in the avs script!
It's the best you will get without speedup and in fact, many TV stations do this blending way in order to maintain their schedule.

resizing directly between 704x480 <-> 704x576 or
between 720x576 <-> 720x480 does NOT introduce an AR error!

NTSC - PAR: 0.911
702x480 -> exact 4:3

PAL - PAR: 1.094
702x576 -> exact 4:3

Cheers :). About the resizing, though. I'm trying to resize to 702x576 for an exact aspect ratio, but I only seem to be able to be able to resize YV12 input to multiple of 4, while the documentation says width of 2 and height by 2 or 4 with interlaced material.

I'll probably be encoding using CCE, but I'm wondering if converting to YUY2 at the start rather than the end will degrade the quality at all? Also, the newer CCEs seem to handle YV12 input without any conversaion, so it would be great to avoid it at all if I could - or does CCE just do an internal YV12 -> YUY2 before encoding anyway?

Thanks for all the help so far everyone, I am very appreciative :D.

Just to clarify, at the moment it looks as if my best choice is either:

changefps(50,true).separatefields.selectevery(4,0,3).weave

or

convertfps(50,true).separatefields.selectevery(4,0,3).weave

or else using DGPulldown to do a 23.976p -> 50i conversion, although I'm a bit concerned about how compatible that will be with different DVD players?

Thanks again, everyone :).

[scharfis_brain]

motionwise changefps equals to dgpulldown, because both do the same here: inserting Frames.

but the 'when' is important here!
changefps will do it before encoding and will make it (unnecessary) interlaced, which is hard to compress.

dgpulldown sets flags, which forces the Standalone DVD-Player to insert the frames while playback. this means you can (MUST) encode progressive, thus raising compression efficency.

of course motion will be a little jerky: two slight stops per second.
As you already said: a 2:2:2:2:2:2:2:2:2:2:2:3 - Pulldown

convertfps will introduce blends (motion ghosting) which is pure evil IMHO.
it lowers compression efficency even more compared to changefps and introduces annoying motion ghosts...
of course, motion is a tad smoother...

but I prefer a blend-free video, so I strongly recommend using dgpulldown, even because it is easier to handle (no weird scripting, breaking minds about interlacing etc.)


btw.: you don't need to resize to exact 702 pixels. 704 are full sufficient.
and you don't need to touch the horizontal resolution at all. just scal vertically by a factor af 1.2

[mg262]

yv12 to yuy2 conversions shouldn't degrade quality at all. The reverse process will degrade it very slightly. But if your source and destination are both yv12, I wouldn't worry about working in yuy2 for the intermediate steps; what you are effectively doing is up sampling the chroma for the intermediate part . (That's all in theory, so I hope someone will confirm it is true in practice...) The colour space conversions are more important to avoid are from the above spaces <-> RGB.

[az_bont]

motionwise changefps equals to dgpulldown, because both do the same here: inserting Frames.

but the 'when' is important here!
changefps will do it before encoding and will make it (unnecessary) interlaced, which is hard to compress.

dgpulldown sets flags, which forces the Standalone DVD-Player to insert the frames while playback. this means you can (MUST) encode progressive, thus raising compression efficency.

of course motion will be a little jerky: two slight stops per second.
As you already said: a 2:2:2:2:2:2:2:2:2:2:2:3 - Pulldown

convertfps will introduce blends (motion ghosting) which is pure evil IMHO.
it lowers compression efficency even more compared to changefps and introduces annoying motion ghosts...
of course, motion is a tad smoother...

but I prefer a blend-free video, so I strongly recommend using dgpulldown, even because it is easier to handle (no weird scripting, breaking minds about interlacing etc.)

That looks to be the better option, then. Will the jerks be any more noticable than the usual 3:2 pulldown?

Also, how is compatibility with different players? Especially some of the more awkward ones like the Playstation 2?

btw.: you don't need to resize to exact 702 pixels. 704 are full sufficient.
and you don't need to touch the horizontal resolution at all. just scal vertically by a factor af 1.2
Ah, well my source is XviD ;).

But if I do happen to want to convert a DVD source, how would I go about just changing the vertical resolution? If I had a 720x480 source, could I use something like lanczos4resize(720x576) and it would automatically not touch the horizontal?

yv12 to yuy2 conversions shouldn't degrade quality at all. The reverse process will degrade it very slightly. But if your source and destination are both yv12, I wouldn't worry about working in yuy2 for the intermediate steps; what you are effectively doing is up sampling the chroma for the intermediate part . (That's all in theory, so I hope someone will confirm it is true in practice...) The colour space conversions are more important to avoid are from the above spaces <-> RGB.
Ah, good - thanks for putting my mind at rest :).

[MOmonster]

The internal resizers in avisynth has seperated horizontal and vertical resizers. So, you can do it that way.

[scharfis_brain]

@mg262: a yv12 -> yuy2 -> yv12 convertsion WILL introduce vertical chroma blur.
I asked several times for yuy2<->yv12 routines that use point-sampling, but noone heared me.. :(
pointsampled yv12 -> yuy2-> yv12 is lossless!

@az_bont:
when not altering one of the relolution parameters, the resizer will internall skip that direction, meaning a speedup and a non touched direction.

but if your source is XVId, you probable have square pixels and need to resize everything.

what's the resolution of that xvid?

[az_bont]

@mg262: a yv12 -> yuy2 -> yv12 convertsion WILL introduce vertical chroma blur.
I asked several times for yuy2<->yv12 routines that use point-sampling, but noone heared me.. :(
pointsampled yv12 -> yuy2-> yv12 is lossless!

@az_bont:
when not altering one of the relolution parameters, the resizer will internall skip that direction, meaning a speedup and a non touched direction.

but if your source is XVId, you probable have square pixels and need to resize everything.

what's the resolution of that xvid?
Most of them are 624x352 or 512x384, so for both it would be a resize to 704x576, right?

I was working them out by assuming the resolution is 1024x576 and then dividing 1024 by the aspect ratio e.g. 1024/1.85 = 554, so resize to 702x554 plus borders. But if I'm going to resize to a width of 704, then I'd probably be better assuming a stretched width of 1027, which is (1024/702)*704.

Would I be right in assuming that at the moment there are no available YUY2<->YV12 routines that use point sampling?

Is this 2:2:2:2:2:2:2:2:2:2:2:3 pulldown method going to be compatible with most/all DVD players? And is it any more jerky than 2:3 pulldown?

[scharfis_brain]

Most of them are 624x352 or 512x384, so for both it would be a resize to 704x576, right?

Yes.

I was working them out by assuming the resolution is 1024x576 and then dividing 1024 by the aspect ratio e.g. 1024/1.85 = 554, so resize to 702x554 plus borders. But if I'm going to resize to a width of 704, then I'd probably be better assuming a stretched width of 1027, which is (1024/702)*704.

No. these calculations aren't corrrect
it has to be
1024/1.7778 (NOT 1.85)

for 4:3 resolution assume 768x576 pixels needs to be filled, then calculate the correct heigt, afterwards replace 768 by 704 (or 702 with two black lines left& right)

512/384 = 1.3333 -> perfect 4:3 -> resize to 704x576 encode as 4:3

624/352 = 1.773 -> near perfect 16:9 -> resize to 704x576 encode as 16:9-anamorphic
or resize to 704x432 plus 72 pixels each top&bottom and encode as 4:3 (this is letterboxed 16:9)

Would I be right in assuming that at the moment there are no available YUY2<->YV12 routines that use point sampling?

No there aren't such functions.
I've made some home-brewed ones, but I fear publicating them, cause they are slow and risky to use.
At least the chroma smear isn't THAT visible, but it is still there

Is this 2:2:2:2:2:2:2:2:2:2:2:3 pulldown method going to be compatible with most/all DVD players? And is it any more jerky than 2:3 pulldown?

It should be compatible with them. But I cannot give a guarantee for it.
So test it before widely using it.

I personally prefer the 24fps -> 50Hz thing over the steady-jerky 24fps -> 60Hz telecines.

but this is a personal taste.

[az_bont]

Most of them are 624x352 or 512x384, so for both it would be a resize to 704x576, right?

Yes.

Good :).

I was working them out by assuming the resolution is 1024x576 and then dividing 1024 by the aspect ratio e.g. 1024/1.85 = 554, so resize to 702x554 plus borders. But if I'm going to resize to a width of 704, then I'd probably be better assuming a stretched width of 1027, which is (1024/702)*704.

No. these calculations aren't corrrect
it has to be
1024/1.7778 (NOT 1.85)

Ah, yes, I was just using 1.85 as an aspect ratio example ;).

for 4:3 resolution assume 768x576 pixels needs to be filled, then calculate the correct heigt, afterwards replace 768 by 704 (or 702 with two black lines left& right)

512/384 = 1.3333 -> perfect 4:3 -> resize to 704x576 encode as 4:3

624/352 = 1.773 -> near perfect 16:9 -> resize to 704x576 encode as 16:9-anamorphic
or resize to 704x432 plus 72 pixels each top&bottom and encode as 4:3 (this is letterboxed 16:9)

Right, got you. If I convert to YUY2 straight after loading I can resize to 702 (width) and then add in those black lines. Is there any reason not to do that at the start.

I've got a semi-related question to ask that's been bothering me for a while. If the display area of video is only 702x480/576, why do all commercial DVDs choose to do 720x480/576 with thick borders when they could just use the perfectly valid resolution of 704x480/576?

Would I be right in assuming that at the moment there are no available YUY2<->YV12 routines that use point sampling?

No there aren't such functions.
I've made some home-brewed ones, but I fear publicating them, cause they are slow and risky to use.
At least the chroma smear isn't THAT visible, but it is still there

Are there any functions/settings I should avoid in order to minimise the damage, or is it all the same regardless?

Is this 2:2:2:2:2:2:2:2:2:2:2:3 pulldown method going to be compatible with most/all DVD players? And is it any more jerky than 2:3 pulldown?

It should be compatible with them. But I cannot give a guarantee for it.
So test it before widely using it.

I personally prefer the 24fps -> 50Hz thing over the steady-jerky 24fps -> 60Hz telecines.

but this is a personal taste.
Okay, I'll burn a test disc and try all the players in the house - I've got eight including consoles so if they can all handle them then chances are most players will :).

Thanks again for the help :D.

[scharfis_brain]

Right, got you. If I convert to YUY2 straight after loading I can resize to 702 (width) and then add in those black lines. Is there any reason not to do that at the start.

Why do you want to convert to yuy2 at all? before resizing?
This script does all needed for your conversion:

AVISOurce("mpeg4.avi") #commonly YV12
lanczosresize(704,576) #still yv12
converttoyuy2() # mabe needed for the encoder (CCE/ProCoder)

Are there any functions/settings I should avoid in order to minimise the damage, or is it all the same regardless?

one should
1) never do unecessary conversions.
2) honor interlacing whil processing. / never convert with separated fields...

[Mug Funky]

between 720x576 <-> 720x480 does NOT introduce an AR error!

oh, now i'm confused... i was basing my opinion on the output from the standards-converter here and my home-brewed conversion script designed to emulate it. the direct 480->576 was slightly taller than the 525->625 cropped method (which came out pretty much identical to the Ixion's output). which is correct i really don't know now, but i know that pro level converters seem to do it the 525->625 way.

[IanB]

Is this 2:2:2:2:2:2:2:2:2:2:2:3 pulldown method ... And is it any more jerky than 2:3 pulldown?The amplitude of the temporal step in both case is the same, however the frequency of the event are not. The first is 2Hz, the second is 24Hz. To the eye the 2Hz "hic" is an identifyable event. The 24Hz stutter is almost but not quite fast enough to be unnoticable, i.e. the motion has something wrong with it but your eye won't tell you what.

To be able to see the temporal step of course it has to be of sufficient magnitude, things like a sceen pan, or an object moving steadily sizeways. In static images of people talking and such like there is nothing to see.

My best advice. If you can't see it and don't know what it looks like. Do not try to find it, because once you see it and recognise it you are forever damned to always see it.

IanB (forever damned)

[IanB]

@Mug Funky,

Last time I checked NTSC had 486 active lines, this 480 lines concept is part of the "digital" corruption^h^h^h^h^h^h^h^h^h^hrevolution.

480/576= 0.833..
486/576= 0.84375
525/625= 0.84
576*0.84= 483.84

Thorts?
IanB

[scharfis_brain]

okay. 704x576 <-> 704x480 is the quick'n'dirty method of resizing.


the real active areas of NTSC and PAL are:
NTSC: 711x486
PAL: 702x576

between those two ones you need to scale, but with 711 (720)x480 digital NTSC the scaling becomes rather difficult:

720x480 NTSC to 720x576 PAL:
(not bothering yuy2 cropping restrictions!)

xxxsource("NTSC.xxx")
crop(4,0,711,0)
addborders(0,3,0,3)
resize(702,576)
addborders(9,0,9,0)

the same for 720x576 PAL to 720x480 NTSC

xxxsource("PAL.xxx")
crop(9,0,702,0)
resize(711,486)
crop(0,3,0,480)
addborders(4,0,5,0)

I don't think that those conversions are very practical.

I prefer the simple resizing approach, which also lets the horizontal resolution unchanged. 702 <-> 711 resizing unnecessary blurs horizontal.

[Kika]

I agree to scharfis_brain. The correct way is to use 711x486, than crop, but as scharfis_brain wrote: I don't think that those conversions are very practical.

704x576 <-> 704x480 may not be absolutly correct, but is is simple to use and there's no risc to have trouble with YUV-restrictions or other things. And it is always better to resize only in one direction.

[az_bont]

The amplitude of the temporal step in both case is the same, however the frequency of the event are not. The first is 2Hz, the second is 24Hz. To the eye the 2Hz "hic" is an identifyable event. The 24Hz stutter is almost but not quite fast enough to be unnoticable, i.e. the motion has something wrong with it but your eye won't tell you what.

To be able to see the temporal step of course it has to be of sufficient magnitude, things like a sceen pan, or an object moving steadily sizeways. In static images of people talking and such like there is nothing to see.

My best advice. If you can't see it and don't know what it looks like. Do not try to find it, because once you see it and recognise it you are forever damned to always see it.

IanB (forever damned)

Okey-dokey :).

About the NTSC resolution thing - I read a very good guide that seemed to explain it in simple enough terms that I could understand it (almost) completely: A Quick Guide to Digital Video Resolution and Aspect Ratio Conversions (http://www.uwasa.fi/~f76998/video/conversion) (#4.5.3 in particular)