[vlc-devel] Soft field repeat?
juha.jeronen at jyu.fi
Thu Jan 6 11:20:25 CET 2011
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 :)
More information about the vlc-devel