[vlc-devel] Soft field repeat?

[Juha Jeronen]

Hi all,

About soft field repeat and the VLC core...

I think I realized what goes wrong with the Angel Links OP - the PTS 
diffs look suspiciously like integer multiples of field length at 59.94 
fps. It's actually requesting a soft telecine!

It's literally the first anime disc I've ever seen to do that. It may 
still be incorrectly mastered - the cels look hard-telecined at least 
during the episode...

Anyway, this explains the TFF/BFF flips and the uneven framerate. If the 
fields are repeated correctly as the disc requests, then the alternating 
field sequence will match the flags (which at first I thought to be 
wrong), and the output should become smooth.

Needless to say, none of the current deinterlacers in VLC handle this 
situation correctly. I'd like to fix this - I think it's needed to make 
DVD support more robust.


Rendering correctly a stream that behaves like this seems to require one 
to four output fields per one input frame, rendered just like each 
frame's TFF/BFF flag tells to.

The output spacing would still be 15 ms (one field length), so it 
wouldn't change the actual output framerate - it'd still act like a 
framerate doubling deinterlacer.

For the existing doublers (Bob, Linear, Yadif2x), two unique output 
frames would probably be enough, but for Phosphor I need three (because 
the output frame containing the first field includes the still fading 
old field from the previous frame, whereas any fields from the second 
one on can be rendered using only data from the new frame).


So, I have a question or two about the VLC core.

First, is there a specific assumption in the core that one input frame 
produces at most two output frames from the deinterlacer module?

At least filter_NewPicture() always fails if I try to get a third one 
during the same frame. Following the code reveals that the vout's 
private pool has become empty at that point.

And if I do picture_NewFromFormat() instead (which I probably 
shouldn't), then the xv vout segfaults, because the new picture is 
missing an shm segment.

So to me it seems there is indeed such an assumption. How hard would 
this limitation be to remove (supporting 1 in, N out where N = 0, 1, 2, 
...)? Is this being planned? Or would anyone happen to know where I'd 
want to look if I wanted to do this myself?


The second issue is that, to do this robustly, I'd need to be able to 
calculate the number of expected output fields for the given input 
frame, and their correct timings.

There is an "i_nb_fields" member in picture_t, but this seems to be set 
to 2 even for pictures whose PTS diff suggests it should be 3. Is this a 
bug, or working as expected?

If that member isn't supposed to be used for this purpose, is there a 
way to access the input nominal framerate from the deinterlacer module? 
I could compute the number of fields from that and the PTS diff... but 
it wouldn't be very robust, given that PTS diffs are thrown out of whack 
simply by alt-tabbing. The i_nb_fields approach would be much better, if 
possible. I like the current design rather much in that the deinterlacer 
doesn't really have to worry about the actual framerate.


I'd appreciate any input on this matter :)

  -J