[vlc-devel] Deinterlacer documentation

[Juha Jeronen]

Hi,

On 04/03/2011 07:26 PM, Jean-Baptiste Kempf wrote:
> Hello,
>
> On Sun, Apr 03, 2011 at 07:17:53PM +0300, Juha Jeronen wrote :
>> On 04/03/2011 05:17 PM, Jean-Baptiste Kempf wrote:
>>> Yes, how are the deinterlaced frames stored...
>>> I had to write a decoder (crystalhd) and seriously I had a lot of
>>> difficulties for interlaced mode.
>> Ah, if you're referring to the hardware deinterlacing of CrystalHD, then
>> what I wrote may not be relevant at all.
> No, the question I had to face was more:
>  - how do I correctly output the data in the picture_t, so that the deinterlacers
>    can be run afterwards?
>    Especially if you get one field after another...

An input question, I see :)

This needs to be documented, too... first draft:


The deinterlacer assumes that the input consists of full frames
(picture_t), with i_nb_fields == 2 or 3 (depending of repeat_pict flags
in the input stream), b_progressive == false, and full vertical
resolution (i_visible_lines) of the input stream. The b_top_field_first
flag is also optionally used by the deinterlacer, and must be set
correctly to guarantee correct operation in all modes.

Each plane is stored linearly, one line at a time, in an uint8_t array
of size i_lines*i_pitch, where i_lines and i_pitch can be read off the
plane_t for each plane (e.g. p_pic->p[plane_index].i_lines). In YUV
formats, the luma and chroma planes have different resolution.

Note that i_lines may differ from i_visible_lines and i_pitch from
i_visible_pitch. The value of i_pitch depends on how the picture_t was
created. The filter picture pool may, and usually does, have a pitch
different from that produced by picture_NewFromFormat(), even though the
visible pitches are the same.

It is assumed that the active picture area starts at the upper left
edge. The first i_visible_lines lines (0 through i_visible_lines-1,
inclusive), make up the visible lines. The rest of the lines
(i_visible_lines through i_lines-1, inclusive) are the (invisible)
vertical margin.

Pixels at offsets 0 to i_visible_pitch-1 relative to each visible line
start are visible. The rest of the pixels, at offsets i_visible_pitch to
i_pitch-1, make up the (invisible) horizontal margin.

It is not necessary to initialize the memory in the invisible parts;
writing just the visible part of the picture is enough.

Note that this implies that any processing loops only need to iterate
through the part from 0 to i_visible_pitch (and i_visible_lines), but
the pixel offsets in the array must be computed using i_pitch.

For any plane that has full vertical resolution, the (macro-)pixels are
stored as if the frame was progressive, i.e. the fields are interleaved.
Line 0 of the plane comes from the top field, line 1 from the bottom
field, line 2 from the top field, and so on. This always holds for the
luma plane, and in the 4:2:2 chroma formats (I422 and J422), also for
the chroma planes.

If the chroma format is 4:2:0 (I420, J420 or YV12), both fields share
the same chroma. This kind of chroma is stored as-is, at half resolution
(both horizontal and vertical) in the U and V planes of the picture_t.
The same linear format is used as above (array of size i_lines*i_pitch,
first i_visible_lines used, and first i_visible_pitch pixels on each
visible line used), but because there is only one "chroma field" in this
case, the fields do not alternate. Instead, chroma line 0 corresponds to
luma lines 0 and 1, chroma line 1 to luma lines 2 and 3, and so on.

Additionally, if chroma is YV12, the U plane is stored in the array
index V_PLANE, and the V plane is stored in the array index U_PLANE.
This is because YV12 uses the plane ordering YVU, while the array index
constants (see include/vlc_picture.h) are named according to the more
common ordering YUV. For all chroma formats using the more common
ordering, U_PLANE refers to the U component and V_PLANE to the V
component, as expected.

Example:

p_pic->p[Y_PLANE].p_pixels[23*w+42]

where w = p_pic->p[Y_PLANE].i_pitch, refers to the pixel on the luma
plane at x = 42, y = 23 (0-based indexing).

If the chroma is I420 or J420,

p_pic->p[U_PLANE].p_pixels[11*w+21]

where now w = p_pic->p[U_PLANE].i_pitch, refers to the chroma macropixel
on the U plane that corresponds to the above example. Obviously, 11 =
floor(23/2).

For 4:2:2 chroma (I422 or J422), only the horizontal chroma resolution
is half that of the luma, and the corresponding macropixel is

p_pic->p[U_PLANE].p_pixels[23*w+21]


 -J