What is telecine?

You have an old film transfer. A DVD rip, a converted tape, something off a disc a relative burned. Every few frames, moving objects break into horizontal comb teeth. So you check the file, and the file says progressive. It isn't lying to you exactly. It's telling you about the wrong thing.

Twenty-four frames into sixty fields

Film runs at twenty-four frames a second. American broadcast video runs at close to thirty frames, or sixty fields, a second. Those numbers don't divide, so getting a movie onto video meant inventing frames that were never shot. The trick is called 3:2 pulldown. It spreads four film frames across five video frames by splitting them into fields and repeating some of them: two fields from the first frame, three from the second, two from the third, and so on.

Three of those five video frames are clean, because both of their fields came from the same film frame. Two are mixtures of two different film frames, photographed a twenty-fourth of a second apart. Those two are where the comb comes from, and it's why telecine combs in a rhythm rather than continuously.

Why the file says progressive anyway

This is the part that sends people in circles. The pulldown happened once, decades ago, when the film was laid down to video. Everything that has happened to the file since has re-encoded it: the DVD encode, your rip, the export from whatever tool you tried first. And after a re-encode, every frame genuinely is a whole frame. The container is correctly labelled progressive.

The mixed fields didn't go anywhere. They're baked into the pixels of those frames, as ordinary picture content. The flag describes how the file is stored, not what was photographed, and once those two disagree no amount of reading metadata will tell you what you're looking at. You have to look at the picture.

We measured exactly this on one piece of footage while building Crisp's detector. The original MPEG-2 honestly reports field_order=tt. Cut and re-encoded (the state most files reach anybody in) the container claims progressive while every frame is still combed. Reading the frames instead of the flag still gets it right: ffmpeg's idet called 96 of 96 frames interlaced on the file that lied, and 82 of 82 progressive on the same clip after an inverse telecine had actually fixed it. The detector was never fooled. Only the metadata was.

How to actually check

Open the file, find a shot with steady horizontal movement, and step through ten frames one at a time. Interlaced video combs on every frame with motion in it. Telecined film gives you a repeating pattern: roughly three clean frames, then two dirty ones, over and over. That rhythm is the signature, and it's visible to the eye at a glance once you know to look for it.

Do this on the original file, at its original size, and the reason is worth stating precisely, because it is a different failure from the one above. Comb teeth are a one-pixel-row structure. A vertical resize interpolates the two woven fields into each other, so the teeth become a soft ghost. Measured: the same frames read interlaced at 640×480 and progressive at 1280×720, while the defect was still plainly there as smearing. That is also why combed footage usually arrives on the web looking like motion blur rather than like comb teeth.

So there are two distinct traps, and it is worth keeping them apart:

• Re-encoding falsifies the container flag. The label says progressive; the pixels are still combed. Frame-level detection is unaffected and still answers correctly.
• A vertical resize blinds the detector itself. Nothing in the file is labelled wrongly. The evidence has genuinely been smeared away, and no filter can cleanly put it back.

"Run the check on the original" is the right advice, but it is advice about the second trap, not the first. Re-encoding alone does not blind a frame-level detector. The scale does.

Why it matters before you enhance anything

For the same reason interlacing does, only more quietly. An upscaler has no idea what a field is. Handed a combed frame, it sees a regular high-contrast horizontal pattern, exactly the fine structure it was trained to protect, and sharpens it. You end up with crisp, high-resolution comb teeth, which are far harder to remove than the originals.

With telecine the trap is worse than with plain interlacing, because most frames look perfect. It's easy to check a still, see nothing wrong, and run the whole job before noticing that two frames in five have been enhanced into a mess. The ordering rule is the same: fix the fields first, then denoise, then upscale, then colour.

Deinterlacing and inverse telecine aren't the same job

Deinterlacing reconstructs a whole frame from each pair of fields. Applied to telecined film it works, and the comb goes away, but you're left with sixty frames a second built out of a film that only ever had twenty-four, so the invented frames are blends and motion can look a little soft.

Inverse telecine instead throws away the repeated fields and reassembles the original twenty-four frames exactly as they were shot. When the pulldown pattern is clean it's lossless, which is a rare thing to be able to say about any video operation. Measured on a 3:2 fixture, 120 frames come out as exactly 96, at SSIM 0.9969 against the true original. When the pattern has been disturbed, by an edit made after the transfer or by a variable frame rate somewhere in the chain, it isn't, and deinterlacing is the safer choice.

Pointing the two operations the wrong way round is not a cosmetic mistake. Inverse-telecining genuinely interlaced video drops one frame in five that nobody ever duplicated: real motion, gone, and nothing gets it back.

Doing it on a Mac

Crisp does both, and tells them apart. It detects a 3:2 cadence and reverses the pulldown (the fieldmatch,decimate route) rather than deinterlacing film and softening every frame, which is what its bwdif fallback would do to it. Genuinely interlaced video gets that fallback instead. The route line on the finished job names which one ran: Inverse telecine or Deinterlaced. The deinterlacing walkthrough has the detail, including the two cases Crisp leaves alone.

How it decides, and why it doesn't guess

Choosing wrong destroys frames, so the decision is narrowed and then checked:

• Frame rate narrows it. A 3:2 pulldown can only exist near thirty frames a second, so inverse telecine is only considered between 29.0 and 30.5 fps.
• A frame count proves nothing on its own. decimate removes the most similar frame in every group of five whether or not anything duplicated it: measured, genuinely interlaced 30fps video yields exactly 0.800, identical to a true pulldown. The ratio survives only as a sanity bound.
• So the answer gets rendered and re-examined. Crisp runs a short sample through fieldmatch,decimate and asks the detector whether the combing is actually gone. On telecined film the matching fields exist and the sample comes out clean. On genuinely interlaced video there is no matching field, the sample is still combed, and Crisp refuses the inverse telecine and deinterlaces instead.

The test deliberately asks "is the comb gone", not "does it say progressive": a detector returns unknown on smooth content it can't classify either way, and demanding the word progressive made this reject real telecine on a synthetic 3:2 fixture.

What it costs, including the case where it loses

The pre-pass runs on the whole file before frames are extracted, and it is cheap: 0.24s on a four-second clip. On a DVD-shaped clip an inverse telecine took 300 frames down to 240 and the job from 19.6s to 17.4s, because there are 20% fewer frames to upscale. It is not free, though, and on a three-second clip the same work came out about 4% slower. The fixed cost of the extra encode outweighs the saving when there is barely any render to save. On long jobs the trade is heavily in your favour; on very short ones it is slightly against you.

Where it doesn't run

Two lanes skip the pre-pass, and Crisp says so rather than reassuring you falsely. The Max restore lane returns into the generative path before the field fix, so a combed source there would be rebuilt in high fidelity over about an hour. Crisp warns before the render starts and tells you to run an ordinary Enhance first, then bring that result back. HDR sources skip the fix on every lane. A third case is narrower than it looks: the timeline export does straighten each clip as it assembles the edit, but with the deinterlacing filter rather than the inverse telecine, because the concat forces a common frame rate. Measured on the rendered output, comb energy fell from 4.728 to 3.059, about 35% less, so telecined film in an edit is blended there, not restored to its original twenty-four frames. If that matters for your footage, upscale the source on its own first.

Everything above runs on your Mac. Nothing is uploaded.

Telecine, in detail

My file says progressive but it still combs. How?

Because the combing is in the pixels, not in the flags. Telecined film is interlaced when it's first laid down to video, but the moment that video is re-encoded (a DVD rip, an export, a transcode of any kind) every frame becomes a whole frame, and the file is honestly labelled progressive. The mixed fields are still there, baked into the picture. The flag describes the container, not what you can see. Frame-level detection still reads it correctly: on the file that lied, ffmpeg's idet called 96 of 96 frames interlaced.

How do I tell telecine from ordinary interlacing?

Count the dirty frames. Interlaced video combs on every frame that contains movement. Telecined film combs in a repeating pattern: with 3:2 pulldown, two frames out of every five are mixed and three are clean. Step through ten frames of a moving shot one at a time. If you see a clean-clean-clean-dirty-dirty rhythm, it's telecine.

Why does detection stop working after I resize?

Comb teeth are a single-pixel-row structure. Any vertical scaling interpolates the two woven fields into each other, so the teeth turn into soft grey banding that no detector recognises and no filter can cleanly undo. Measured on one clip: the same frames read interlaced at 640×480 and progressive at 1280×720, while the defect was still plainly visible as smearing. Check the original file, at its original size, before anything in your pipeline touches the resolution.

Is deinterlacing a telecined file the wrong thing to do?

It's the safe thing to do, and it isn't the ideal thing. Deinterlacing gives you sixty whole frames per second, but the extra ones are reconstructed from a film that only ever had twenty-four, so motion can look slightly soft. Recovering the original twenty-four frames instead is called inverse telecine, and it's a different operation. Either way it has to happen before any enhancement runs.

Does Crisp inverse-telecine my file, or just deinterlace it?

It decides per file, and it proves the answer before it uses it. A 3:2 cadence can only exist near 30fps, so Crisp only considers inverse telecine when the source runs between 29.0 and 30.5 frames a second. Even then a frame count is not proof: decimate drops one frame in every five by design, so genuinely interlaced 30fps video returns exactly the same 0.800 ratio a real pulldown does. So Crisp renders a short sample through fieldmatch,decimate and asks the detector whether the combing is gone. If it is, the job runs as an inverse telecine. If not, it falls back to bwdif deinterlacing, which is always safe. The route line on the finished job names which one ran.

Related

• What is variable frame rate?
• Why upscaling to 4K takes so long
• Why AI upscaling can't rescue a shot that missed focus