Unichrome blit() bug

Hi,

unichrome driver has a bug when source and destination
surface are not
of the same size and when only a section of the source
surface should be
blitted to the destination surface.

uc_accel.c:

static bool uc_blit_planar(void* drv, void* dev,
DFBRectangle* rect, int dx, int dy)
{
    UC_ACCEL_BEGIN()

    int uv_dst_offset = ucdev->dst_offset +
(ucdev->dst_pitch * rect->h);
    int uv_src_offset = ucdev->src_offset +
(ucdev->src_pitch * rect->h);

If rect is the source rect which should be blitted then:
- destination offset  of y plane should be advanced by
dst_pitch * dy.
- dest offset of 1st uv plane is dst_offset + dest_pitch *
dst_high + (dst_pitch * dy) / 4.
- dest offset of 2nd uv plane is (dest_pitch * dst_high) / 4
past 1st plane offset.

dest_high is not part of ucdev struct I guess.

--
Stefan Lucke

_______________________________________________
directfb-dev mailing list
directfb-devdirectfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/
directfb-dev

On Sunday 04 March 2007 20:42, you wrote:
> >     int uv_dst_offset = ucdev->dst_offset +
(ucdev->dst_pitch * rect->h);
> >     int uv_src_offset = ucdev->src_offset +
(ucdev->src_pitch * rect->h);
> >
> > If rect is the source rect which should be blitted
then:

static bool uc_blit_planar(void* drv, void* dev,
DFBRectangle* rect, int dx, int dy)

My analysis is only correct if parameter rect is the source
rectangle
which should be blitted.

> > - destination offset  of y plane should be
advanced by dst_pitch * dy.
> > - dest offset of 1st uv plane is dst_offset +
dest_pitch * dst_high +
> > (dst_pitch * dy) / 4.
> > - dest offset of 2nd uv plane is (dest_pitch *
dst_high) / 4 past 1st
> > plane offset.
> 
> 
> I can believe there could be a bug in the blitting of
planar surfaces but I
> don't follow your analysis.  dst_offset is simply the
memory location of
> start of the surface image data.  uv_dst_offset holds
the memory location of
> the start of the first chrominance plane's image data
(and is subsequently
> adjusted to point to the second).  What further
correction to these values
> is needed and why?

For destination pointer calculation, the height of the
source rectangle is out of interest.

> 
> The existing code in uc_blit_planar adjusts the
rectangle and pitch values
> when it blits the chrominance planes.
> 
> Perhaps we could rewind a bit and you could describe
what's actually going
> wrong?

Ok, I've to explain a bit more.
The source surface holds data which is decoded by the via
mpeg hw-decoder
and is for expample of size 720x576. I want to crop out a
16:9 area of the 4:3
video frame. The cropped area should be taken from line 72
with height 432 
from source, and blitted to x=0 and y=0 to the destination
surface.
Hm, dest surface is in my case of height: source
rect-height, so it should fit.

But the source  u plane does not start at src_offset +
(src_pitch * rect->h)

softdevice in case we cannot use SetSourceRectangle()  .
Additional cutXXX are zero in my case.

        sRect.x = sxoff + 2 * cutLeft;
        sRect.y = syoff + 2 * cutTop;
        sRect.w = swidth  - 2 * (cutLeft + cutRight);
        sRect.h = sheight - 2 * (cutTop  + cutBottom);
        videoSurface->Blit(mpegfb[currentFB], &sRect,
cutLeft * 2, cutTop * 2);



-- 
Stefan Lucke

_______________________________________________
directfb-dev mailing list
directfb-devdirectfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/
directfb-dev

On Sunday 04 March 2007 21:20, Mark Adams wrote:
> > unichrome driver has a bug when source and
destination surface are not
> > of the same size and when only a section of the
source surface should be
> > blitted to the destination surface.
> 
> 
> OK, I understand what you're saying now.  Yes, there's
a bug: it's using the
> source rectangle height to find the U and V planes
rather than the source
> and destination surface heights.  So I guess it goes
wrong any time you set
> a source rectangle for a YV12/I420 blit that doesn't
include the full height
> of the surface.
> 
> Shame we've missed 1.0...

Here is my first suggestion to fix it.
Just looked at those places where [src|dst]_offset are set
and kept
a copy of [src|dst]_height.

Passed a short test with hw-decoding.
Video is scaled correct and colors are _not_ messed up.

-- 
Stefan Lucke

_______________________________________________
directfb-dev mailing list
directfb-devdirectfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/
directfb-dev