[vlc-devel] Phosphor: new deinterlacer under development
juha.jeronen at jyu.fi
Tue Jan 4 23:22:20 CET 2011
I'm developing another new deinterlacer, or maybe it should rather be
called an interlaced renderer for progressive displays. I'm emulating an
old CRT in software. It's a bit like "bob" with visible "scanlines" and
How it works: if we don't mind that the pixel positions don't exactly
match between an LCD display and a CRT TV, we can use a framerate
doubler, which dims the "old" field (simulating phosphor light output
decay) while the "new" one is being rendered. The only required
components are a two-frame cache, ComposeFrame() from my IVTC filter,
and a luma dimmer (done as a bit shift, using MMX if available). I wrote
a preliminary version yesterday.
The rationale behind the filter is that there exists material,
especially anime, that doesn't lend itself to IVTC and was never
intended for progressive displays. A notorious example is Sol Bianca -
it contains, in the same video frames, 24 fps telecined cels and 60 fps
interlaced camera pans and CGI. It looks very smooth on an interlaced
display, but can't really be rendered properly on a progressive one.
The new filter works pretty well as long as the input framerate and
video field dominance are steady, and the computer can keep up a steady
60 fps output.
There is some anime for which this does not hold - e.g. the opening
sequence of Angel Links, and all of the aforementioned Sol Bianca. Angel
Links OP flipflops TFF/BFF every two frames (as given by
p_pic->b_top_field_first), while Sol Bianca contains occasional random
TFF/BFF flips for no apparent reason. The OP to Silent Mobius and the
crossfades in the OP to Kanon (2006) contain such random flips, too. I
tested my code on properly authored discs, too (e.g. Azumanga,
Str.A.In., The Third), and on them it works correctly.
I have no idea how traditional equipment (hardware DVD player + CRT TV)
can cope with flipflopping material, since they can't switch the field
dominance on the fly. The same applies to this filter, since it's based
on the same field rendering principle.
For now, I chose just to lock on to the initial TFF/BFF and ignore any
flips. This will display the fields in the wrong order in the offending
frames, but I'm not sure what else could be done. Does anyone have ideas?
Also, in the Angel Links OP I'm getting PTS diffs in the range of 16-66
ms, which causes unbearable flicker as the field display time varies
wildly. I was expecting a steady 33 ms, since VLC's stream information
tells me it's supposed to be 59.94 fps. I don't yet have an idea what to
do if the PTS diffs vary, or what it is that is going wrong with this
particular DVD. It could be just my netbook, but the CPU usage didn't
look that bad, so I don't know whether it can be the decoder taking too
much time for some frames. Or maybe the PTS values are messed up on the
For properly authored material - steady framerate and no TFF/BFF flips -
I think the new filter looks pretty good. On the netbook's 1024x600
display, NTSC material displays fine and looks CRT-ish through the
filter. Obviously, there is a slight pattern visible from the rescale,
but I think it's acceptable as long as it's run fullscreen. PAL requires
a larger output vertical resolution due to the scaling.
In other news, my preliminary tests indicate that the aggressive version
of the IVTC filter is usable (and gives better results than the
original) if the motion threshold is decreased from 30 to 10. I'll still
run some more tests before I make a final decision. I'll post about this
again in the near future.
That's it for today's dev update :)
More information about the vlc-devel