[vlc-devel] Q: Deinterlacer merge function
juha.jeronen at jyu.fi
Thu Aug 2 15:58:46 CEST 2012
On 02.08.2012 16:28, Rémi Denis-Courmont wrote:
> I am looking at the Merge() function in the deinterlacer. There seems to be
> confusion with the picture pitches, and/or in my brain:
> On the one hand, linear, mean and blend modes assume that the input pitch is
> smaller (or equal) to the output pitch. If this is not true, an overflow will
> occur while running memcpy() or Merge().
> On the other hand, the IVTC and Phosphor (i.e. ComposeFrame()) check the
> visible widths instead of the pitches. They make no assumptions: neither that
> both input pitches are equal, nor that the input pitches and the output pitch
> are equal.
One note here: the pitch and visible width may wildly differ in one
special case. To do a single-field copy (needed by IVTC and Phosphor),
the other field (which is to be skipped in the copy operation) is
defined as part of the pitch - which makes plane_CopyPixels() skip it
(as pitch is then >= 2*visible_width; see source of plane_CopyPixels()).
See FieldFromPlane() in modules/video_filter/deinterlace/helpers.c. This
solution was based on a discussion with Laurent.
So, whether one should look at the visible width or the pitch, depends
on what is being done. Perhaps visible_pitch should be used instead of
visible width, though.
> While the latter approach is certainly safe, it is suboptimal: The picture
> widths are not so SIMD-friendly power-of-two multiples as picture pitches.
> Also, if all pitches are equal, the Merge() operation for each plane could be
> all done in one go, rather than one scan line at a time.
As for why those algorithms don't make assumptions, it's just that I
rather err on the safe side when I'm not 100% sure of the input :)
> So hmm, can the the pitches from the two input pictures actually be different
> (for the same plane, of course)? I'd think they have to be equal to the width
> of the video format...
I have no idea here. You're probably right, since the pictures come from
the same stream (if we make the assumption that, upon playlist item
change, the filter chain is closed/reopened).
> Also, can the output pitch differ from the input pitch?
Again, I'm not sure. I have a faint, vague recollection that when I
tested with various DVD sources in I420 format, there *might* have been
some case where this actually happened.
> How come the filter only checks chroma and height after GetOutputFormat()?
This comes from the original version of the filter before I started
hacking it. Maybe it's based on the assumption that the filter chain is
always recreated if the format changes?
More information about the vlc-devel