Working on Telecined PAL source \o/

[Snowcrash]

Hi guys,

I am working currently on a PAL source which is surprising me a little.

First here is a sample: http://www.sendspace.com/file/fonxdr

It's the first time I get a PAL DVD from a NTSC source - Batman is of course an american release - which seems to be telecined (lucky me!).

JHowever it seems to be mixed between interlaced (we can see scanlines in the green smoke) and progressive (no interlacing with Bruce and the Joker). I am not sure about it so you can check the sample I linked above.

I did a simple script according to the Org guide:

Code: Select all

mpeg2source("batman.sample.d2v")
TFM()

I actually want to keep it at 25 fps because my main source is at 25 fps (batman is under 5% of my video). So I don't need to add any lines to my script, I suppose.

But if I want to restre properly the frames, I need to add these lines at the end normally ?

Code: Select all

TDecimate(cycle=25)
AssumeFPS(23.976)

Is that correct ?
But my final framerate will be 25 fps, that's why I don't need to add theses lines.

Extra question: it seems that this source got each frame in double. Every second frame is identical to the first one. Was it animated at 12 fps then doubled at 24 fps ?

Thanks in advance.

[mirkosp]

Nope, not soft telecined. If you check both honor and ignore pulldown, you see the result is identical. At most it could be a hard telecine, but there is no euro telecine pattern (the infamous 2:2:2:2:2:2:2:2:2:2:2:3 ─ that's eleven 2 and a 3) in sight here.
Basically, if you check the motion of the cloud after deinterlacing (or even just field matching), you'll see it's all "unique" frames (well, in this case you have dups in some places due to the 12fps animation, but you get what I mean by unique). If it was really a telecine, every 12 frames there'd be a 13th dup one. In this specific case, due to the 12fps animation, you'd have 5 groups of 2 dups and a 6th group of 3 dups. But that's not what you have, so, yeah, not a euro telecine.
This is likely just a slowdown from 60i (or MAYBE it's not a slowdown and they just dropped a field in every set of 6, but it seems very unlikely to me), I wouldn't decimate (in either case). TFM seems to be fixing the interlacing regardless since all the interlaced fields are just dups anyway due to the low framerate of the animation in this scene. I don't how the rest of the footage looks, but if there is actual pure interlacing, it might be safer to just use tdeint or perhaps QTGMC with nice settings with a selectodd (or selecteven, whichever you prefer) afterwards.