2006/4/1, Walter Belhaven <wbelhaven@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:)