[vlc-devel] Phosphor: new deinterlacer under development
Juha Jeronen
juha.jeronen at jyu.fi
Wed Jan 5 22:15:15 CET 2011
On 01/05/2011 12:22 AM, Juha Jeronen wrote:
> 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?
On a side note, I noticed that the same issue affects the "bob"
deinterlacer, as it operates using the same field rendering principle.
When the field dominance flips, the perceived vertical resolution will
drop to half momentarily.
I think that ideally, all field order based deinterlacers should be
protected against this, in order to make them behave sensibly on badly
authored streams.
I've now got an idea how to handle this.
Consider the following stream, which was supposed to be TFF (diagrams
intended for a fixed-width font):
error error
v v
T1 T2 T3 T4 T5 T6 T7 T8 T9 ...
B1 B2 B3 B4 B5 B6 B7 B8 B9 ...
TFF BFF TFF
Idea: require one frame lookahead (render "current" frame, not "next").
Discard B4 and duplicate T6:
T1 T2 T3 T4 T5 T6 T7 T8 T9 ...
B1 B2 B3 B5 B6 T6 B7 B8 B9 ...
This gives us a stream that is consistently TFF. We can thus alternate
fields normally when rendering. The solution also preserves the temporal
ordering of the input fields.
The same idea works for BFF with the appropriate changes.
When the video field dominance flips, there will be a one-field stutter
(due to drop or duplication), but I think this is preferable to the
alternative of actually switching FD while field rendering.
While the FD is "flipped", we run one field ahead (of audio and
subtitles), but the FD stays correct. When the FD flips back to
original, we repay this debt and start running in sync again. (This is
important, to prevent the desync from becoming worse at each flip.)
AviSynth includes a plugin that does the same operation
(ReverseFieldDominance, according to
http://avisynth.org/mediawiki/Interlaced_fieldbased ), so I think this
might work.
I'll test this when I have the time, and report back later.
A more serious problem are streams that should have a constant 59.94
fields per second framerate, but in practice don't.
I'd like to find out whether it's the VLC core causing it or if it's
something to do with the DVD itself, but preferably without recompiling
some other media player just to insert a debug print for comparison ;)
Any suggestions how to proceed with this part?
-J
More information about the vlc-devel
mailing list