[FFmpeg-user] decomb versus deinterlace

Mark Filipak markfilipak.windows+ffmpeg at gmail.com
Sun Apr 19 03:38:36 EEST 2020


On 04/18/2020 07:16 PM, pdr0 wrote:
> Mark Filipak wrote
>> Deinterlacing is conversion of the i30-telecast (or i25-telecast) to p30
>> (or p25) and, optionally,
>> smoothing the resulting p30 (or p25) frames.
> 
> That is the description for single rate deinterlacing. But that is not what
> a flat panel TV does with interlaced content or "telecast" - it double rate
> deinterlaces to 50p (50Hz regions) or 59.94p (60Hz regions). The distinction
> is important to mention; one method discards half the temporal information
> and motion is not as smooth.

Very good point. My 60Hz TV would best do a p24-to-p60 telecine (via something like 55 pull-down or, 
better: motion compensation, but it apparently does not). It apparently does a 23 pull-down (to p30) 
and then frame doubles. The reason I say "apparently" is that, on my TV, hard-telecined 30fps 
content and 24fps content have identical judder.

> Deinterlacing does not necessarily have to be used in the context of
> "telecast".  e.g. a consumer camcorder recording home video interlaced
> content is technically not "telecast".  Telecast implies "broadcast on
> television"

You are right of course. I use "telecast" (e.g., i30-telecast) simply to distinguish the origin of 
scans from hard telecines. Can you suggest a better term? Perhaps "i30-camera" versus "i30"? Or 
maybe the better approach would be to distinguish hard telecine: "i30" versus "i30-progressive"? Or 
maybe distinguish both of them: "i30-camera" versus "i30-progressive"?

> The simplest operational definition is double rate deinterlacing separates
> and resizes each field to a frame +/- other processing. Single rate
> deinterlacing does the same as double, but discards either even or odd
> frames (or fields if they are discarded before the resize)

I think I understand your reference to "resize": line-doubling of half-height images to full-height 
images, right?

But I don't understand how "double rate" fits in. Seems to me that fields have to be converted 
(resized) to frames no matter what the "rate" is. I also don't understand why either rate or 
double-rate would discard anything.

>> Combing is fields that are temporally offset by 1/24th second (or 1/25th
>> second) resulting from
>> telecine up-conversion of p24 to p30 (or p25).

Including "(or 1/25th second)" in the above was a mistake. Sorry.

> I know you meant telecine up conversion of 23.976p to 29.97i (not "p"). But
> other framerates can be telecined eg. An 8mm 16fps telecine to 29.97i.

Well, when I've telecined, the result is p30, not i30. Due to the presence of ffmpeg police, I 
hesitate to write that ffmpeg outputs only frames -- that is certainly true of HandBrake, though. 
When I refer to 24fps and 30fps (and 60fps, too) I include 24/1.001 and 30/1.001 (and 60/1.001) 
without explicitly writing it. Most ordinary people (and most BD & DVD packaging) don't mention or 
know about "/1.001".

> "Combing" is just a generic, non-specific visual description. There can be
> other causes for "combing". eg. A warped film scan that causes spatial field
> misalignment can look like "combing". Interlaced content in motion , when
> viewed on a progressive display without processing is also described as
> "combing" - it's the same underlying mechanism of upper and lower field
> taken at different points in time

Again, good points. May I suggest that when I use "combing" I mean the frame content that results 
from a 1/24th second temporal difference between the odd lines of a progressive image and the even 
line of the same progressive image that results from telecine? If there's a better term, I'll use 
that better term. Do you know of a better term?

>> Decombing is smoothing combed frames.
> 
> Yes, but this is an ambiguous term. "Decombing" can imply anything from
> various methods of deinterlacing to inverse telecine / removing pulldown .

To the best of my knowlege, ffmpeg doesn't use the terms "combing" or "decombing" -- certainly 
there's no decomb filter. I don't have a term that distinguishes smoothing of a 1/24th second comb 
(what I call "decombing") from smoothing of a 1/60th second (or 1/50th second) comb that results 
from deinterlace (which I don't call "decombing"). Can you suggest a term for the latter? Or terms 
for the both of them?

Regarding inverse telecine (aka INVT), I've never seen INVT that didn't yield back uncombed, purely 
progressive pictures (as "picture" is defined in the MPEG spec). Can you/will you enlighten me 
because it's simply outside my experience.

>> It seems to me that some people call combing that results from telecine,
>> interlace. Though they are
>> superficially similar, they're different.
> 
> Yes, it's more appropriately called "combing".

So, if I properly understand, you favor "combing" to mean the 1/60th (or 1/50th) second temporal 
difference between odd/even lines that result from deinterlace. That's exactly the reverse of how I 
have been using "combing". You see, to me, "combing" doesn't refer to visual appearance, but to 
structural content (i.e., 1/24 sec between lines as opposed to 1/fieldrate sec between lines). I 
appreciate that to most people, "combing" is an appearance, but basing structural difference on 
appearance leaves no way to distinguish deinterlace from telecine. Perhaps "interlace-comb" versus 
"telecine-comb" would work better. What do you think?

> When writing your book , I suggest mentioning field matching and decimation
> ( inverse telecine, removing pulldown) in contrast to deinterlacing.

Well, I'm writing a guide, not a book, and I plan to not address INVT at all because I've never had 
a use for INVT and I suspect that no one else will.

> I recommend describing the content. That's the key distinguishing factor
> that determines what you have in terms of interlaced content vs. progressive
> content that has been telecined

Yes! That's exactly what I seek. But there doesn't seem to be a nomenclature that describes 
(unambiguous) structure as opposed to (ambiguous) appearance.

Thanks so much for the discussion and for your insights.
Regards, and Stay Healthy,
Mark.


More information about the ffmpeg-user mailing list