[vlc-devel] Q: Deinterlacer merge function

[Juha Jeronen]

Hi,


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?


  -J