On Sun, 3 Feb 2002, Martin Vogt wrote:
>
>
> Hello,
>
> I now have the explaination from the last mail:
>
> "XV bug in nv / nvidea (and maybe other?)"
>
> The reason is, that Xfree seems to calculate the size
> of an YUV12 differently.
> Its not clear if this is a bug or not, but if you see the interface:
>
> xvimage = XvShmCreateImage(display, portid,
> guid, 0,
> width,height, shmseginfo);
>
> X sets in this call xvimage->data_size but allocates too
> much data for some yuv image combinations.
>
> I had allocated the Shm-Segment _before_ this call and
> thus have no use for xvimage->data_size.(And expected that they
> both have the _same_ data_size.)
That is a bad assumption you have made.
>
> But the calcualted data_size in X is not the "estimated" one.
> (I hope my algorithm is the right one, I'm not sure)
>
> (in fact its lager, und thus transfers more data, than actually used
> for an YUV12 image)
> -> This was the reason why the "normal"/not shm call did work.
>
> Here are some numbers:
> res X11 me
> 800,615: 739200 738400 (here it gives a segfault)
You will see that the X-server corrected what you asked for. The
XvImage returned will have height be a multiple of two, as is appropriate
for a 4:2:0 surface.
> 800,650: 780000 780000
> 360,320: 172800 172800
> 640,520: 499200 499200
>
> Whereas the lines 2-4 are correct for yuv12 image the line 1 is
> simply too much.
>
> Heres my algo: (don't know if this is correct)
>
>
> int imageSizeYUV12(int width,int height) {
> int lumsize=width*height;
> /**
> colorsize is:
> -for every 4 lum pixel we have 2 color pixel.
> -if we have an odd number of height we need for this odd
> row width/2 extra space.
> -if we have an odd number of width (eg 3) we need 2 extra color
> information for every row.
> */
> int colorsize=lumsize/2;
> if (height & 0x1) { // odd height
> colorsize+=width/2;
> }
> if (width & 0x1) { // odd width
> colorsize+=height*2;
> }
>
> return (lumsize+colorsize);
> }
>
The odd height issue aside, your calculation is too simplistic.
All scanlines will be 32 bit padded per the server's image padding
requirements. You shouldn't make these calculations yourself because
the drivers are free to make any alignment restrictions they please.
The pitches of each plane and the offset to each plane within the
allocation are given in the XvImage returned to you. You will have
problems if you do not abide by them.
Mark.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
