Hi, I’m new to the forum.
I’m using SDL to display YUV images, and it works fine on both
Linux and Windows for images over a certain size. But on Windows
I get problems with image size 176x144 (QCIF). It works fine on Linux.
Exactly the same source file is used for Linux and Windows.
Larges sizes (eg 352x288 and 704x576) work fine on both platforms.
Is there a problem with allocating areas with dimensions not divisible by 32
on Windows?
-Robert
Robert Folland wrote:
Hi, I’m new to the forum.
I’m using SDL to display YUV images, and it works fine on both
Linux and Windows for images over a certain size. But on Windows
I get problems with image size 176x144 (QCIF). It works fine on Linux.
Exactly the same source file is used for Linux and Windows.Larges sizes (eg 352x288 and 704x576) work fine on both platforms.
Is there a problem with allocating areas with dimensions not divisible by 32
on Windows?
Sometime width != image->pitches[], especially with small sizes:
if (width != m_image->pitches[0]) {
// The width is not equal to the size in the SDL buffers -
// we need to copy a row at a time
to = (uint8_t *)m_image->pixels[0];
from = y;
for (ix = 0; ix < height; ix++) {
memcpy(to, from, width);
to += m_image->pitches[0];
from += width;
}
} else {
// Copy entire Y frame
memcpy(m_image->pixels[0],
y,
bufsize);
}Larges sizes (eg 352x288 and 704x576) work fine on both platforms.
Is there a problem with allocating areas with dimensions not divisible
by 32
on Windows?
?On Aug 5, 2005, at 2:26 PM, Robert Folland wrote:
Larges sizes (eg 352x288 and 704x576) work fine on both platforms.
Is there a problem with allocating areas with dimensions not divisible
by 32
on Windows?
Have you tried other non-32-divisible dimensions?On Aug 5, 2005, at 2:26 PM, Robert Folland wrote:
There are usally some size/scaling/alignment limitations in the
hardware itself, with older cards usually having more limits. Though
if you’re using the same hardware with Linux and Windows you shouldn’t
really be seeing a difference, unless the Windows driver is
artificially limiting it for some reason.
DirectX allows you to read the limits from the driver/hardware, so it
should be possible to write a small program to dump the DDCAPS and
check what SDL will be seeing.
SiOn 05/08/05, Robert Folland <robert.folland at gmail.com> wrote:
Is there a problem with allocating areas with dimensions not divisible by 32
on Windows?
Yes, I tried it now and it works in Linux but not in Windows. I
upsampled the QCIF images by 3 to get 528 by 432 images. Did the
upsampling in Windows, played fine in Linux, but the exact same
sequence does not play in Windows.On 8/5/05, Donny Viszneki wrote:
On Aug 5, 2005, at 2:26 PM, Robert Folland wrote:
Larges sizes (eg 352x288 and 704x576) work fine on both platforms.
Is there a problem with allocating areas with dimensions not divisible
by 32
on Windows?Have you tried other non-32-divisible dimensions?
I’m now reading single bytes at a time from file, still the same problem.On 8/5/05, Bill May wrote:
Robert Folland wrote:
Hi, I’m new to the forum.
I’m using SDL to display YUV images, and it works fine on both
Linux and Windows for images over a certain size. But on Windows
I get problems with image size 176x144 (QCIF). It works fine on Linux.
Exactly the same source file is used for Linux and Windows.Larges sizes (eg 352x288 and 704x576) work fine on both platforms.
Is there a problem with allocating areas with dimensions not divisible by 32
on Windows?Sometime width != image->pitches[], especially with small sizes:
if (width != m_image->pitches[0]) { // The width is not equal to the size in the SDL buffers - // we need to copy a row at a time to = (uint8_t *)m_image->pixels[0]; from = y; for (ix = 0; ix < height; ix++) { memcpy(to, from, width); to += m_image->pitches[0]; from += width; } } else { // Copy entire Y frame memcpy(m_image->pixels[0], y, bufsize); }
There are usally some size/scaling/alignment limitations in the
hardware itself, with older cards usually having more limits. Though
if you’re using the same hardware with Linux and Windows you shouldn’t
really be seeing a difference, unless the Windows driver is
artificially limiting it for some reason.DirectX allows you to read the limits from the driver/hardware, so it
should be possible to write a small program to dump the DDCAPS and
check what SDL will be seeing.
Hm, I’m not very knowledgeable about DirectX, any pointers to where I
can see how to dump this DDCAPS…? It sounds like this may be a
limiting by Windows like you say, or is it in the SDL implementation
for Windows?On 8/6/05, Simon Owen wrote:
There are usally some size/scaling/alignment limitations in the
hardware itself, with older cards usually having more limits. Though
if you’re using the same hardware with Linux and Windows you shouldn’t
really be seeing a difference, unless the Windows driver is
artificially limiting it for some reason.DirectX allows you to read the limits from the driver/hardware, so it
should be possible to write a small program to dump the DDCAPS and
check what SDL will be seeing.
I’m now reading single bytes at a time from file, still the same
problem.
I don’t think the transfer interval of image data is what’s in question
here, rather, it is the dimensions of your overlay, and window’s
limitations.On Aug 5, 2005, at 6:02 PM, Simon Owen wrote:
On Aug 8, 2005, at 2:00 AM, Robert Folland wrote:
On Aug 8, 2005, at 2:05 AM, Robert Folland wrote:
Hm, I’m not very knowledgeable about DirectX, any pointers to where I
can see how to dump this DDCAPS…?
I think this might be what you’re looking for:
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/
ddraw7/directdraw7/ddref_18zb.asp
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: text/enriched
Size: 1329 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050810/29f3c5db/attachment.bin
Hm, I’m not very knowledgeable about DirectX, any pointers to where I
can see how to dump this DDCAPS…?I think this might be what you’re looking for:
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/
ddraw7/directdraw7/ddref_18zb.asp
Thanks for the replies on this thread. I didn’t feel I had the time to
go into DirectX stuff,
so what I ended up doing was just to pad out the image to a multiple
of 32 on the
right-hand side and the bottom. I then created a screen with
SDL_SetVideoMode with
the real dimensions, and an overlay with SDL_CreateYUVOverlay with the extended
dimensions. The padded area is then not visible.
I have to read the data a line at a time instead of the whole
component in one go. I did not measure the performance hit from having
to do this on Win32. Of course, I could read it in one go and copy in
memory.
-RobertOn 8/10/05, Donny Viszneki wrote:
On Aug 8, 2005, at 2:05 AM, Robert Folland wrote: