[vlc-devel] Updating the deinterlacer user documentation

Juha Jeronen juha.jeronen at jyu.fi
Tue Apr 12 12:05:38 CEST 2011

Hi all,

I'm planning to combine the user doc draft I wrote last week* into the
official user documentation on the wiki**.

I'm posting this as open for comments in case someone reading this list
wants to comment. If not, I'll do the update based on this. I'd prefer
to update the docs after the merging of IVTC, so that only one larger
update for the doc is needed.

* http://mailman.videolan.org/pipermail/vlc-devel/2011-April/079614.html
** http://wiki.videolan.org/Deinterlacing

The existing documentation has a good introduction, and having a
separate short description of each algorithm is nice. These will be kept.

I'm planning to expand a bit:

- Adding the classification of the algorithms into general types. It
requires reading one more paragraph per algorithm type, but it makes
comparing the algorithms (based on the summary table) much faster for
mathematical-logical readers. (This is in addition to the existing short
descriptions, not to replace them.)

- The general idea behind framerate doublers. Users that come looking
for documentation are not necessarily (or even probably?) familiar with

- More complete information in the summary table. My suggestions for a
new table, to replace the existing one, is in the draft. (It's weird, I
could have sworn there were three separate tables containing the
algorithm info in the original doc when I last looked. But there is only
one. I must have looked at something else.)

- True interlaced vs. telecined. It's relevant as they require different
algorithms, telecine is very widely used at least in anime, and anime is
popular enough that in my opinion we shouldn't ignore it. Some framerate
doublers can be used for both types, but some cannot, and 1x
interpolators are never applicable to telecined (and obviously, IVTC is
not applicable to true interlaced).

- Note that VLC's deinterlacer is software-based. (As opposed to
hardware-based deinterlacers some cards/drivers have.)

- Suggestion for ordering of contents:

1) Description (from existing doc)
2) Interlaced or telecined? (material from draft; three paragraphs at
maximum, like the current "Description" section)
3) Algorithm types (from draft; one or two paragraphs for each of the
four types)
4) VLC settings (from existing doc)
5) VLC deinterlace modes (from existing doc)
6) Summary (new table from draft; replaces "Resulting framerate and
7) Recommendations (needs to be rewritten, see below)
8) Disclaimer (needs to be updated)

The algorithm descriptions in "VLC deinterlace modes" need some updating:

Disabled: The parenthetical remark is correct, so the wording should be
changed. The acronym PsF is used without definition. Suggest linking to

Blend: It could be explained more clearly that this is a full-resolution
blender, combining adjacent lines in a scanning fashion. Otherwise it's
not clear what the difference to Mean is.

Bob: Essentially correct, but it's not quite 2x Discard due to the
one-line offset without which it wouldn't be Bob. But maybe this is
close enough for the short description. Leave as-is.

Discard: Correct (if we allow the term "judder" for behaviour that is
regular in time). Leave as-is.

Linear: Hair-splitting aside, correct, and a good description. Leave as-is.

Mean: Correct and a very compact wording. Near perfect. I'd like to add,
just for emphasis and not to leave it to the reader to notice the
implication, that this is a half-resolution blender. Otherwise it's not
clear what the difference to Blend is.

X: The code says it keeps the even lines (top field), but then again in
the code the numbering begins from 0. I think it's nontrivial to decide
which is more natural for the user documentation. I vote for "top =
even" and "bottom = odd" for consistency, even if it requires starting
numbering from 0. Any real TV engineers will probably disagree with
whichever convention is chosen here ;)

In any case, the part "complicated algorithm..." could be replaced by a
mention of progressive and interlaced blocks, and edge-oriented
interpolation. And yes, block-based is a simple version of area-based,
so the question mark can be eliminated and the note reworded.

Yadif: this explanation is nonsensical, and should be replaced with
something like "Keeps the even lines, and creates the odd lines by
combined spatial and temporal interpolation."

Yadif (2x): could be changed to simply "Bob with Yadif interpolation".
The "2x" and "like linear" just confuse things.

The note about frame skipping seems out of place here. Obviously that's
due to CPU load - there should be a separate section on that. Maybe a
column in the algorithm info table, saying "low", "medium", "high", or
"very high", and then a note that if the CPU usage is too high for the
computer to handle, VLC will skip frames?

Obviously, I plan to add similar notes for the new modes:

X (2x) (v1.2.0+): Bob with X interpolation.

Phosphor (v1.2.0+): Simulate a traditional CRT TV. The latest two
half-pictures are weaved, and the older half-picture is darkened as if
it was fading out. Unlike Disabled, this weaving disregards temporal
frame boundaries.

IVTC (v1.2.0+): Inverse telecine. Removes NTSC telecine, losslessly
recovering the progressive signal. Only applicable for telecined material.

Updated recommendations (from my earlier message), will be properly
formatted and worded later:

- For any true interlaced input: matter of taste; use anything other
than IVTC.
  - If an interpolator is desired: try Yadif and X. Maybe Yadif as a
general recommendation?
  - If a framerate doubler is desired: use Linear if not particularly
picky. Gives low CPU usage and acceptable quality. Otherwise, try all
(Bob, Linear, X2x, Yadif2x, Phosphor) and pick one.
- For telecined input (e.g. almost all NTSC anime), use IVTC.
- For hybrid 60i/24p (Sol Bianca...), use a framerate doubler.

Finally, some small things:

- Documentation says "full" vs. "half" framerate, while the UI suggests
2x vs. 1x (with Yadif (2x)).

Technically speaking, which one is the "full" fps depends on the
material: for true interlaced, it's the field rate, for true
progressive, the frame rate, and for telecined... auuuugh! (24p encoded
as 60i, so the field rate for the container, and (4/5)x the container
frame rate for the content, assuming a correct, unbroken telecine. Not
to mention hybrid 24p/60i, which would be field rate, kind of, but, you
know, eh... but I think we don't really need to go into this much
detail. Two general options and one special note for IVTC should be fine.)

In any case, I think the terminology needs to be consistent. Which
convention do we want to adopt? I vote for 1x/2x, with a note that "2x"
means the field rate ("half-picture rate" for the doc).

- There is nothing about 4:2:0 chroma considerations in the original
doc, and also very little in my draft, but I'm undecided on whether
that's relevant, or too technical for the average (technical) user.

Personally, I think it's very much relevant for getting a
correct-looking picture. But perhaps it's enough to have the further
details in the developer doc. The relevant section of that can be linked
from the user doc.

- Strictly speaking, HDTVs do display a full frame at a time. Commonly
they have some kind of deinterlacing built in to handle interlaced
sources. Maybe this distinction between old and new TVs should be made
in the "Description" section?

Maybe something like the following. (This is still a bit confusing and
needs to be changed somehow.) Begin with "Traditionally, TVs do not
display..." and add a new paragraph "Modern TVs (HD Ready and Full HD)
display a full picture-frame at a time, just like computers do.
Similarly, they utilize deinterlacing to display traditional TV
material." just before the final "A very good description..."

That's all for now,


More information about the vlc-devel mailing list