Henning Haaland Kulander wrote:
On Wed, 3 Dec 2003, IOhannes zmoelnig wrote:
I have tried setting m_image.image.upsidedown to 1 and 0, but there is no change. Still upsidedown.
i tried it too. it worked for me.
the other problem is BGR-colorspace (or BGRA) vs RGB(A). (pix_* processing in) Gem supports 3 different colorspaces: GL_RGBA, yuv422 (UYVY) and Greyscale (GL_LUMINANCE). the [pix_texture] just passes the current-colorspace to the renderer, thus supporting other formats like GL_BGR too.
I don't get this either. The ffmpeg streams I've tried are YUV420, and the ressult should be GL_RGBA. The plugins tries to use img_convert with the correct colorspaces as paramters, but the output is still wrong. I haven't tried the fromBGR hack yet. It seems wrong to first convert from YUV to BGR and then from BGR to RGB...
this turned out to be a bit complicated PIX_FMT_RGBA32 is not RGBA (as i would have thought) but it is really BGRA (on intel and friends: little_endian) and ARGB (on big-endians)
and although it seems wrong to do too much conversion, it is the easiest for now. Gem supports a lot of conversion-routines by itself, so we could use these (but this needs time, as to find out what ffmpeg means with it's formats (like RGBA32 beeing anything but RGBA (in this order)) the attached files make this double conversion for convenience.
i am afraid, these changes will not make it into the next release.
mfg.as.dr IOhannes
On Thu, 4 Dec 2003, IOhannes zmoelnig wrote:
the other problem is BGR-colorspace (or BGRA) vs RGB(A). (pix_* processing in) Gem supports 3 different colorspaces: GL_RGBA, yuv422 (UYVY) and Greyscale (GL_LUMINANCE). the [pix_texture] just passes the current-colorspace to the renderer, thus supporting other formats like GL_BGR too.
I don't get this either. The ffmpeg streams I've tried are YUV420, and the ressult should be GL_RGBA. The plugins tries to use img_convert with the correct colorspaces as paramters, but the output is still wrong. I haven't tried the fromBGR hack yet. It seems wrong to first convert from YUV to BGR and then from BGR to RGB...
this turned out to be a bit complicated PIX_FMT_RGBA32 is not RGBA (as i would have thought) but it is really BGRA (on intel and friends: little_endian) and ARGB (on big-endians)
That's nice... :)
and although it seems wrong to do too much conversion, it is the easiest for now. Gem supports a lot of conversion-routines by itself, so we could use these (but this needs time, as to find out what ffmpeg means with it's formats (like RGBA32 beeing anything but RGBA (in this order)) the attached files make this double conversion for convenience.
The attached files look identical to the CVS-version... But I added this myself to test, and it worked. So thanks!
Regards, Henning Kulander
On Thu, 4 Dec 2003, Henning Haaland Kulander wrote:
Gem supports a lot of conversion-routines by itself, so we could use these (but this needs time, as to find out what ffmpeg means with it's formats (like RGBA32 beeing anything but RGBA (in this order)) the attached files make this double conversion for convenience.
The attached files look identical to the CVS-version... But I added this myself to test, and it worked. So thanks!
I have written the FFMPEG port because it was said that it is the best video decoding library around. unfortunately seeking wasn't supported at that time, so it wasn't possible to write a fully compliant pix_film. MAybe I will find the time to do so during christmas.
Greetings,
Guenter
-
guenter geiger -
Henning Haaland Kulander -
IOhannes m zmoelnig -
IOhannes zmoelnig