[vlc-devel] Phosphor: new deinterlacer under development

[Juha Jeronen]

Hi again,

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 
no halfsizing.

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 
DVD itself.

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 :)

  -J