[MPlayer-dev-eng] Re: [MPlayer-users] ssa reader for mplayer using vf_overlay

[Robert Henney]

On Fri, Sep 30, 2005 at 11:01:35PM -0400, Jason Tackaberry wrote:
> On Fri, 2005-09-30 at 22:57 -0400, Robert Henney wrote:
> > I found the bug in vf_overlay.c.  at the end of invalidate_rect(), 
> > the line
> [...]
> > 	priv->invalid_rects = r;
> 
> Sorry I haven't replied to your other emails yet.  I've had a busy
> night, and will reply tomorrow.

don't worry about it.  :)

> I did find this bug a couple weeks ago, but I haven't posted a new patch
> since then.  I should have remembered it when you posted your email.
> Sorry for causing you a lot of wasted time, but good eye catching that
> one. :)

:)


I'm still having one last issue which appears to be of a color space
nature, even with the vf_overlay_outbuf-2005-09-20-TESTING.diff applied.
Doesn't appear any different even if I insert the scale filter.  It also
doesn't happen every time I go to update the overlay, but is
consistently repeatable if I follow the same sequence each time.

A snapshot of the problem:

	http://rut.org/mpssa/osdtest/outfile.png

The image is of a bitblt'ed rectangle of data into the overlay buffer at
x=122 y=191 w=395 h=98, followed by "overlay invalidate=122:191:395:98"
and setting the lockbyte to 0x20.

Now, this is what's very interesting..  if instead of those invalidate
coordinates, I use coordinates that box the entire screen (eg. 0:0:640:480) 
then the problem disappears and everything looks perfectly correct.

	UPDATE: did some further testing before sending this mail and
	came up with a pattern.  if the y value passed with the
	invalidate command is ODD, then this strange color shift
	always happens, but never when it's EVEN.

below is the bitblt code used for writing to the overlay buffer, out of
context of course.  I include it because the bug may certainly be in it,
though I've gone over it several times already.  For this test I've
forced the code to write only full red for /any/ non-black pixels in the
data.  that way the overlay buffer should only be getting two values
from that code, 0xffff0000 and 0x00000000, and yet it appears we're
seeing three by the time it's on the screen.

    int x, y
    unsigned long *pR, *pW;
    // 'mem' is pointer to overlay memory

    for (y=0; y<imgheight; y++) {
	pW = (unsigned long*)mem + 4 + imagex + (y+imagey) * screenwidth;
	for (x=imgwidth; x; x--) {
	    unsigned long v;
	    v = *(pR++);
	    if (v&0xffffff)
		*(pW) = 0xffff0000;
	    else *(pW) = 0x00000000;
	    pW++;
	}   
    }

-- 
robh