14.999fps to DVD: which way to go? like, decided, exactly, encode, change

andy

Having experienced the goodness of recent block removal utilities, I decided to dust off my Gabriel Knight 1 CDs (I have two) and try to make a miniDVD out of the quot;making ofquot;. Problem is, the source is exactly 14.999fps, so I figure these are the options:

1) Alter framerate to 23.976fps, encode and then pulldown.

2) Alter framerate to 25fps.I'd like to hear your opinions on which should be better and why. Also, in order to change the framerate, should I use interpolated/dupe frames or speed up the video?

Original Progressive?
NTSC
abc=gt;aabbcc
Code:
Interleave(Last,Last)
AssumeFPS(60000, 1001,True)
ResampleAudio(48000)
PAL
abc-\aabbc
abc-/abbcc
Code:
AssumeFPS(15,True)
DoubleWeave
SelectEvery(6,0,1,2,3,4)
ResampleAudio(48000)
PAV v2
abc-\abbcc
abc-/abbca
Code:
Interleave(SelectEvery(3,0),SelectEvery(3,1),SelectEvery(3,1),SelectEvery(3,2),DoubleWeave.SelectEvery(6,5))
AssumeFPS(25,True)
ResampleAudio(48000)if you want to force progressive encoding without introducing an unsmooth pattern of duplicated frames for PAL, you may speedup the 14.999fps to 16.667 fps (16 2/3) and then pulldown to 25fps.

16.6667 fps ist the lowest framerate achievable with PAL and pulldown.

Motion-interpolation!  Okay, with a cinepak source you may as well pray for sierra to send you their master copy, but at least it might help. (The GK videos have been on my quot;list of stuff to process laterquot; for a while now.)

Everyone: thanks for the advices .

AI: yes, the original is progressive.
Originally Posted by scharfis_brainif you want to force progressive encoding without introducing an unsmooth pattern of duplicated frames for PAL, you may speedup the 14.999fps to 16.667 fps (16 2/3) and then pulldown to 25fps.

16.6667 fps ist the lowest framerate achievable with PAL and pulldown.

I read once that any other pulldown than 23.976--gt;29.97 using DGPulldown will cause some jittering (wobbling, right?). Does that not apply to 14.999---gt;16.667? If not, how would you go about speeding up to 16.667?foxyshadis: it's not Cinepak, it's Microsoft Video 1 and it's so crappy that I couldn't use AVISource right away since the decoder couldn't handle YUV or RGB. I ended up loading the video itself, making an uncompressed RGB encode and loading that into AVISource. Everyone, this is the current filterchain:

Code:
Levels(0,1,245,16,235)
ConvertToYV12()
FFT3DFilter(sigma=6,plane=3,bw=32,bh=32,bt=3,ow=16,oh=16)
hqdn3d(0,0,3,3)
AddBorders(0,4,0,4)
Deblock_QED(quant1=30,quant2=51)
Crop(0,4,160,120,align=true)
GaussResize(192,144)
dull=last
sharp=dull.LimitedSharpenFaster(SMode=4,LMode=3,Strength=1000,wide=true,soft=75)
Soothe(sharp,dull,30)
EEDI2().TurnRight().EEDI2().TurnLeft()
FFT3DFilter(sigma=1,bw=32,bh=32,bt=3,ow=16,oh=16,sharpen=0.7)
GaussResize(3xx,2xx,p=100)   lt;--- depends on wether I go PAL or NTSC
Tweak(sat=1.2)
AddGrain(10,0,0)
AddBorders(16,16,16,16)
ConvertToYUY2()   lt;--- for CCE
(by the way foxyshadis, we should include a check within BlockTerminator that detects when source width and height are not MOD16 so that it adds suitable borders before deblocking and removes them after, like I did here)

and this is a comparison with both source and result blown up to 640x480 for a better view:Any kind of feedback on how to make it look better is welcome.

Chainmax
What you think about my pulldown with out chenge speed?

Note: quot;aquot;,quot;bquot;,quot;cquot; is fields as manual built-in pulldoun.

Oh, I knew it was one of those codecs that made me install the stupid quot;legacy codec packquot;, that turn every 2x2 pixel block into a single huge pixel. Since I dealt with some similar cinepak videos a few months ago I was going to show you what I did, which was similar to an immature BlockAhnold+immature mcnr_simple, but that already looks better anyway. Dang, I guess I need to redo Jesse Cook now. EEDI2 is so effective at repairing those old junkers!


Originally Posted by scharfis_brain16.6667 fps is the lowest framerate achievable with PAL and pulldown.

Why does it have to be a 3:3 pulldown from an 11% speed up. What is wrong with a 4:3:3 pulldown pattern from 15 fps. The 5Hz jitter won't be detectable over the 15hz judder.

because then interlace encoding is required.
with an 3:3 pulldown you can stick with progressive encoding.

Ahah, I see your point, if you do it in AviSynth, yes.

But if you use DGPulldown this is not a problem.

So I guess I would have to recomend PAL
Code:
....
AssumeFPS(15, True)
ResampleAudio(48000)
Encode as 15FPS progressive
Use DGPulldown to set to 25 FPS

or NTSC
Code:
....
AssumeFPS(15000, 1001, True) #  14.985
ResampleAudio(48000)
Encode as 14.985FPS progressive
Use DGPulldown to set to  29.97FPS

Ianb: you didn't read my previous posts carefully enough.

1) I am not suggesting to do anything in AVISynth
2) DGPulldown only allows 3:3 pulldowns at max.
this means:
with PAL (25fps native) you can only go down to 16 2/3 fps. not lower
with NTSC (29.97fps naive) you can only go down to 19.98 fps

this effectively means: for PAL one needs to speedup 15fps to 16.667 fps in order to be ABLE to do the 3:3 Pulldown.

3) framerates like 15 or 14.985 aren't supported by mpeg2.
you need to abuse (speed change) one of the valid framerates like
23.976, 24, or 25.
then use dgpulldown and the desired ratio of 16.6667 to 25.0 .
dgpulldown will overwrite the previously assumed framerate of the encoded mpeg2.

foxyshadis: 2x2 pixel block? Is that a real quot;featurequot; of those codecs or just a sarcastic coment on the crapyness of these old codecs? By the way, the thing that impresses me the most about this filterchain is that the source doesn't even look like real life footage but hand drawn since the textures (or whatever they are called) are so screwed up, and even though the result is much too blurry, at least it looks like live footage again .

AI: your methods sound great, but I'm waiting for more opinions on wether I should do everything in Avisynth or use DGPulldown at some point.

scharfis_brain: why does 15fps---25fps needs interlace encoding?

25p -gt; 25 points on the time axis per second possible
25i -gt; 50 point on the time axis per second possible

this brings us to the following patterns (Large Letter: Top field on TV, small letter: Bottom Field on TV):

15p to 25p: AaAaBbBbCcDdDdEeEeFf, which is an 2:2:1 pattern. This means it has a VERY noticeable jerkyness

15p to 25i:  AaAbBbCcCcDdDeEeFfFf, which is an 3:3:4 pattern, which only has a slight mostly unnoticeable remaining jerkyness.

My method applies the speedup, to 16,667 fps and thus realizes a 3:3:3 pattern, which is completely jerk-free (exept of the 15fps stutter) and allows progressive encoding!
So it is the best of both methods: progressive encoding AND jerkyness suppression.

Chainmax, can you provide a sample video?
I am just curious, how motion compensated temporal super resolution approaches might help here...

@schafis,

Yes you are correct. I should learn to check these things before I open my big mouth.

So the question remains how do you Force/Trick/Deceive whatever into doing a 4:3:3 pulldown pattern of a progressive mpeg2 encode without an 11% speedup.

i.e. I want AI's pattern with a progessive encode abc-\aabbc abc-/abbcc

it is possible, but it could be VERY hard to set up!

1st step: creat a progressive mpeg file with this pattern:
AaBbCcCcDdEeFfFf (2:2:4 Pattern)

then Pulldown this MPEG to
AaAbBbCcCcDdDeEeFfFf (3:3:4 Pattern)

but it is quite difficult, because the frames containing Aa, Bb, Dd, and Ee needs to become pulldown flagged, while the already doubled Frames containing Cc and Ff must remain untouched.

I have no clue, how to do this with dgpulldown!

maybe a completely new pulldown application could be useful here. I think about an application that adaptively insert Null-P-frames into the video stream, where more than 3 is needed in the pulldown pattern...

Here's a sample.

processed file: files/16951339/sample-25p.avi.html

there are still some blotchy artifacts, for whose I was too lazy to compensate them.
It is just a test of my approach.
also the video has been interpolated up to 25 fps. So no need for any pulldown...

The motion seems quite fluid for me, but I'd like to see what others think about it. Is this much different than using 16.667 speedup+pulldown? About the filtering, it doesn't convince me: it's far too smooth and there is some kind of weird residual motion on the backgrounds.

made another sample: files/16986312/...-25p1.avi.html

btw.: please show me the results of your approach as a
video from the same snipplet I got from you.
IMHO the result of your approach according to the image
above has too much staistepping left and thus is only
virtually sharper. stairstepping is a kind of sharpness,
but not one that pleases my eyes.
That's why I prefer some kind of smoothness in that case.

my 2nd sample is a little bit sharper and has more stable backgrounds. of course the approach is also very different from the pulldown
approach, because no pulldown is needed anymore.
It is true 25fps now (upwards interpolated the framrate from 14.999 to 25fps).EDIT: my script just uses two external plugins: mvtools and eedi2.
the rest is a 3x redundant chain of pointresize, temporalsoften,
eedi2 and mvflow calls to merge 5 frames temporally while
effectively raising resolution and image detail.

@ scharfi:

that's an amazing result right there.

btw, any reason not to bump fps to 30000/1001 and encode progressive?  there's redundant frames but that's the least of this sample's problems