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.)
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)
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);
}
regards,
Martin
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
