Re: deintrelacing patch

Thu Sep 29 2005, Mikhail Ramendik wrote:

> can not try it, because the patch has failed to apply to the CVS which I have 
> pulled yesterday. Perhaps you could just check the patched version into CVS?
> 
I'd rather not check this patch in, because there is some things that
should be changed before comitting, like the key commands to turn
on/off. But the patch should have applied. Maybe you can hand patch it,
it not very much to change.



> My idea would be: don't create a new xv_image on switch. Rather, do the 
> following:
> 
> xv_image->width = xv_image.width/2;
> xv_image->height = xv_image.height*2;

I tried that before, but I think the Xserver saves the values in another
place because changing xv_image->width doesn't do anything after the
XvCreateImage call.

> If this does not work, one can destroy an xv_image using a mere free() call. 
> It's allocated by Xmalloc which in turns points to malloc. So, just do a 
> temp_xvimage=xv_image before the allocation of the new xv_image, and 
> free(temp_xvimage) after that.

Maybe it would be better to use XFree() or does that do something else?

> Seems like we have a way to a clean (but Xv-dependent) implementation of 
> simple deinterlacing in ogle?

Yes, ugly deinterlacing, Xv-dependent and dependent on the gfxcard
being able to handle xvimages with a width up to 1440 :)
But it's better than nothing.
My card handles xvimages up to 2048x2048 according to xvinfo,
I don't know if those are limits in width and height or if the limit
is on the total size being less than 2048*2048 pixels.

/Bj|rn