[MPlayer-dev-eng] Need help with interlaced images and strides

[Ivan Kalvachev]

2006/4/1, Walter Belhaven <wbelhaven at yahoo.com>:
> Hi,
>
> I'm attempting to implement a slight variation of the 'tinterlace=0'
> filter, and it's clear that I just don't "get" the stride
> implementation in mplayer, or just how interlaced images are stored.
>
> Can someone point me to some info on this?  I've read everything I can
> find, including all of the technical documentation.  I even think I
> understand the entire filter interface and most of what's going on in
> vf_tinterlace.c, but there's a disconnect somewhere.
>
> Here are the details.  To convert 720p/60Fps HD "video" to 480i/60fps
> SD "video" for burning to DVD-Video (capital F's mean Frames, little
> f's mean fields), I'd like to take, say, the even lines from Frame 'j',
> and, say, the odd lines from Frame 'j+1'.
>
> At a high level this is what the tinterlace=0 filter does, but not
> quite.  In order to test the concept and to get things working, I'm
> making my changes "in place" to tinterlace=0.  The changes I've made
> are as follows:

You are actually trying to make a filter that reverses what tinterlace=0 does?
I think that maybe tfields does it. :)


> vf_tinterlace.c::config()
>  1. passed 'height' and 'd_height" to next filter, rather than
>     height*2 and d_height*2

You are splitting 1 image on 2 images, it must be height/2
not sure for d_height... probably it must stay the same.

>
> vf_tinterlace.c::put_image()
>  1. requested an image of 'mpi->height' instead of 2x that
>     in vf_get_image

same as above

>  2. set 'dmpi->fields' to MP_IMGFIELD_INTERLACED.  Also tried
>     setting MP_IMGFIELD_TOP_FIRST.

if you remove the interlace then this is not what you should do. the
result is progressive.

>  3. changed all occurrences of dmpi->stride[n] to twice that value,
>     in all calls to memcpy_pic.

OK

>  4. changed all height's to height/2 in calls to memcpy_pic.  I get
>     core dumps if I don't, and it makes sense to me to make this
>     change.

ok. Note that srcScride must be mpi->stride[n]*2 while dstStride is
normal dmpi->stride[n].


( 4.5 ) call put_image to pass the first field as first frame.

>  5. Used a single stride offset when copying the 2nd field

Wrong.

You must use same height and stride as 1'st field, but the start of planes
must be one stride down (plane[n]+stride[n]


> I'm clearly missing something, because the resulting output doesn't
> look interlaced, especially with two carefully crafted JPG images I'm
> using for testing.  Any help would be appreciated.

Actually it looks like you didn't explain what are you trying to do.


The format of interlaced images is the same as in mpeg2.
one line is from first field, next line is from second field. Same
applies to chroma planes.


the strides are just offsets of the lines in bytes. this means that
they are used instead of line width to compute the start of next line.
Using ugly ascii art (f is first fields s is second, big luma small
chroma small chroma).

F F F F    f    f
S S S S
F F F F    s    s
S S S S

  (this is why if interlaced images are handled like progressive there
may be some miscoloration, and color from next fields combines with
luma from first one).


Hope it helps. (hope i didn't write something wrong:)