[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