Hi, I'm watching (non-4:3) videos on TV connected to g400's 2nd head using: mplayer -vo fbdev -fb /dev/fb1 -vop expand=720:576:0:32:1,scale=720:-2 cd1.avi (fb1 is set to 720:576, 32bpp) sometimes, the bottom line of the video is somewhat reverted, when it shows blue things, i see red, and vice versa. looks like the last line is byte-swapped. it doesnt seem to depend on the original (unscaled) video size of aspect ratio. i've tried to reproduce with -vo x11 and -vo png, no success. maybe because vo_x11 has swscaler built-in, and vo_png uses 24bpp and reverse byteorder. if you cannot reproduce, i'll investigate further... A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu
Hi On Monday 15 March 2004 14:51, Arpi wrote:
Hi,
I'm watching (non-4:3) videos on TV connected to g400's 2nd head using:
mplayer -vo fbdev -fb /dev/fb1 -vop expand=720:576:0:32:1,scale=720:-2 cd1.avi
(fb1 is set to 720:576, 32bpp)
sometimes, the bottom line of the video is somewhat reverted, when it shows blue things, i see red, and vice versa. looks like the last line is byte-swapped. it doesnt seem to depend on the original (unscaled) video size of aspect ratio.
i've tried to reproduce with -vo x11 and -vo png, no success. maybe because vo_x11 has swscaler built-in, and vo_png uses 24bpp and reverse byteorder.
if you cannot reproduce, i'll investigate further... its known problem, the last line is converted with the c converter while the rest is done in mmx, alex changed the rgb<->bgr behavior of the c code sometime ago, and after some complaints by me, alex summarized how rgb and bgr should be defined, and IMHO the definition is good its just not what most of the code in mplayer currently uses, so IIRC the mmx code matches your definition of rgb/bgr while the c code matches alexs :)
[...] -- Michael level[i]= get_vlc(); i+=get_vlc(); (violates patent EP0266049) median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]); (violates patent #5,905,535) buf[i]= qp - buf[i-1]; (violates patent #?) for more examples, see http://mplayerhq.hu/~michael/patent.html stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en
Hi,
if you cannot reproduce, i'll investigate further... its known problem, the last line is converted with the c converter while the rest is done in mmx, alex changed the rgb<->bgr behavior of the c code sometime ago, and after some complaints by me, alex summarized how rgb and bgr should be defined, and IMHO the definition is good its just not what most of the code in mplayer currently uses, so IIRC the mmx code matches your definition of rgb/bgr while the c code matches alexs :)
"cool". any chance to fix it anyway? btw the rgb vs bgr thing is imho well defined in docs/tech/colorspaces.txt. and anyway, if mmx code behaves way one, the fallback c code should do it teh same way, even if alex is mad as usual. A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu
Hi,
if you cannot reproduce, i'll investigate further...
its known problem, the last line is converted with the c converter while the rest is done in mmx, alex changed the rgb<->bgr behavior of the c code sometime ago, and after some complaints by me, alex summarized how rgb and bgr should be defined, and IMHO the definition is good its just not what most of the code in mplayer currently uses, so IIRC the mmx code matches your definition of rgb/bgr while the c code matches alexs :)
"cool". any chance to fix it anyway?
Hi On Monday 15 March 2004 18:55, Arpi wrote: patch attached, i wont commit, as i dont want to be flamed :)
btw the rgb vs bgr thing is imho well defined in docs/tech/colorspaces.txt.
IMHO its not, the reason why i think so is that if a developer doesnt know open gl then he depends upon -vo gl which only supports RGB24 & RGB32
and anyway, if mmx code behaves way one, the fallback c code should do it teh same way, even if alex is mad as usual. yes, fully agree, we should either change all code or leave it
[...] -- Michael level[i]= get_vlc(); i+=get_vlc(); (violates patent EP0266049) median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]); (violates patent #5,905,535) buf[i]= qp - buf[i-1]; (violates patent #?) for more examples, see http://mplayerhq.hu/~michael/patent.html stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en
On Mon, Mar 15, 2004 at 07:13:50PM +0100, Michael Niedermayer wrote:
Hi
Hi,
if you cannot reproduce, i'll investigate further...
its known problem, the last line is converted with the c converter while the rest is done in mmx, alex changed the rgb<->bgr behavior of the c code sometime ago, and after some complaints by me, alex summarized how rgb and bgr should be defined, and IMHO the definition is good its just not what most of the code in mplayer currently uses, so IIRC the mmx code matches your definition of rgb/bgr while the c code matches alexs :)
"cool". any chance to fix it anyway?
On Monday 15 March 2004 18:55, Arpi wrote: patch attached, i wont commit, as i dont want to be flamed :)
Are you sure this patch is correct? IMO the depth reading is incorrect:
- const int isRgb = IMGFMT_IS_RGB(c->dstFormat); + const int isRgb = !IMGFMT_IS_RGB(c->dstFormat); const int bpp = isRgb?IMGFMT_RGB_DEPTH(c->dstFormat):IMGFMT_BGR_DEPTH(c->dstFormat);
The last line should be: const int bpp = isRgb?IMGFMT_BGR_DEPTH(c->dstFormat):IMGFMT_RGB_DEPTH(c->dstFormat); Or better yet, rename the "isRgb" variable to "isBgr" so it's consistent. Rich
Hi On Tuesday 16 March 2004 09:23, D Richard Felker III wrote:
On Mon, Mar 15, 2004 at 07:13:50PM +0100, Michael Niedermayer wrote:
Hi
On Monday 15 March 2004 18:55, Arpi wrote:
Hi,
if you cannot reproduce, i'll investigate further...
its known problem, the last line is converted with the c converter while the rest is done in mmx, alex changed the rgb<->bgr behavior of the c code sometime ago, and after some complaints by me, alex summarized how rgb and bgr should be defined, and IMHO the definition is good its just not what most of the code in mplayer currently uses, so IIRC the mmx code matches your definition of rgb/bgr while the c code matches alexs :)
"cool". any chance to fix it anyway?
patch attached, i wont commit, as i dont want to be flamed :)
Are you sure this patch is correct? IMO the depth reading is #define IMGFMT_RGB_DEPTH(fmt) ((fmt)&0x3F) #define IMGFMT_BGR_DEPTH(fmt) ((fmt)&0x3F)
incorrect:
- const int isRgb = IMGFMT_IS_RGB(c->dstFormat); + const int isRgb = !IMGFMT_IS_RGB(c->dstFormat); const int bpp = isRgb?IMGFMT_RGB_DEPTH(c->dstFormat):IMGFMT_BGR_DEPTH(c->dstFormat);
The last line should be:
const int bpp = isRgb?IMGFMT_BGR_DEPTH(c->dstFormat):IMGFMT_RGB_DEPTH(c->dstFormat);
IMHO it should be const int bpp = IMGFMT_RGB_DEPTH(c->dstFormat); [...] -- Michael level[i]= get_vlc(); i+=get_vlc(); (violates patent EP0266049) median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]); (violates patent #5,905,535) buf[i]= qp - buf[i-1]; (violates patent #?) for more examples, see http://mplayerhq.hu/~michael/patent.html stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en
btw the rgb vs bgr thing is imho well defined in docs/tech/colorspaces.txt.
IMHO its not, the reason why i think so is that if a developer doesnt know open gl then he depends upon -vo gl which only supports RGB24 & RGB32 I can help you there. The attached patch lets vo_gl use most colour
Hi, formats (needs OpenGL 1.2). Start it with -vo gl:manyfmts. It seems that at least the MMX/3dnow-optimized YUV->RGB32 version uses a different format for RGB32 than OpenGL... I get funny colors on my AMD Athlon machine with -vf format=RGB32. No other vo module I can use supports this format... Greetings, Reimar Döffinger Index: vo_gl.c =================================================================== RCS file: /cvsroot/mplayer/main/libvo/vo_gl.c,v retrieving revision 1.39 diff -u -r1.39 vo_gl.c --- vo_gl.c 22 Feb 2004 15:30:01 -0000 1.39 +++ vo_gl.c 16 Mar 2004 16:55:44 -0000 @@ -47,6 +47,9 @@ static uint32_t image_width; static uint32_t image_height; static uint32_t image_bytes; +static int many_fmts; +static GLenum gl_format; +static GLenum gl_type; static int int_pause; @@ -67,6 +70,62 @@ glLoadIdentity(); } +static int find_gl_format (uint32_t format) +{ + switch (format) { + case IMGFMT_RGB8: + gl_format = GL_RGB; + gl_type = GL_UNSIGNED_BYTE_2_3_3_REV; + break; + case IMGFMT_RGB15: + gl_format = GL_RGBA; + gl_type = GL_UNSIGNED_SHORT_1_5_5_5_REV; + break; + case IMGFMT_RGB16: + gl_format = GL_RGB; + gl_type = GL_UNSIGNED_SHORT_5_6_5_REV; + break; + case IMGFMT_RGB24: + gl_format = GL_RGB; + gl_type = GL_UNSIGNED_BYTE; + break; + case IMGFMT_RGB32: + gl_format = GL_RGBA; + gl_type = GL_UNSIGNED_BYTE; + break; + case IMGFMT_BGR8: + gl_format = GL_RGB; + gl_type = GL_UNSIGNED_BYTE_3_3_2; + break; + case IMGFMT_BGR15: + gl_format = GL_BGRA; + gl_type = GL_UNSIGNED_SHORT_1_5_5_5_REV; + break; + case IMGFMT_BGR16: + gl_format = GL_RGB; + gl_type = GL_UNSIGNED_SHORT_5_6_5; + break; + case IMGFMT_BGR24: + gl_format = GL_BGR; + gl_type = GL_UNSIGNED_BYTE; + break; + case IMGFMT_BGR32: + gl_format = GL_BGRA; + gl_type = GL_UNSIGNED_BYTE; + break; + case IMGFMT_Y800: + case IMGFMT_Y8: + gl_format = GL_LUMINANCE; + gl_type = GL_UNSIGNED_BYTE; + break; + default: + gl_format = GL_RGBA; + gl_type = GL_UNSIGNED_BYTE; + return 0; + } + return 1; +} + /* connect to server, create and map window, * allocate colors and (shared) memory */ @@ -83,6 +142,7 @@ image_height = height; image_width = width; + find_gl_format (format); vo_dwidth = d_width; vo_dheight = d_height; @@ -266,8 +326,8 @@ i, // y offset image_width, // width (i+slice_height<=image_height)?slice_height:image_height-i, // height - (image_bytes==4)?GL_RGBA:GL_RGB, // format - GL_UNSIGNED_BYTE, // type + gl_format, + gl_type, ImageData+i*image_bytes*image_width ); // *pixels } @@ -279,6 +339,8 @@ { if ((format == IMGFMT_RGB24) || (format == IMGFMT_RGB32)) return VFCAP_CSP_SUPPORTED | VFCAP_CSP_SUPPORTED_BY_HW; + if (many_fmts && find_gl_format(format)) + return VFCAP_CSP_SUPPORTED | VFCAP_CSP_SUPPORTED_BY_HW; return 0; } @@ -293,15 +355,19 @@ static uint32_t preinit(const char *arg) { + many_fmts = 0; + slice_height = 4; if(arg) { + if (strncmp (arg, "manyfmts", 8) == 0) { + many_fmts = 1; + arg = &arg[8]; + } + if (arg[0] != 0) { slice_height = atoi(arg); if (slice_height <= 0) slice_height = 65536; - } - else - { - slice_height = 4; + } } mp_msg(MSGT_VO, MSGL_INFO, "[vo_gl] Using %d as slice_height (0 means image_height).\n", slice_height);
Hi On Tuesday 16 March 2004 18:09, Reimar Döffinger wrote:
Hi,
btw the rgb vs bgr thing is imho well defined in docs/tech/colorspaces.txt.
IMHO its not, the reason why i think so is that if a developer doesnt know open gl then he depends upon -vo gl which only supports RGB24 & RGB32
I can help you there. The attached patch lets vo_gl use most colour formats (needs OpenGL 1.2). Start it with -vo gl:manyfmts. It seems that at least the MMX/3dnow-optimized YUV->RGB32 version uses a different format for RGB32 than OpenGL... I get funny colors on my AMD Athlon machine with -vf format=RGB32. No other vo module I can use supports this format... -vo sdl supports it
[...] -- Michael level[i]= get_vlc(); i+=get_vlc(); (violates patent EP0266049) median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]); (violates patent #5,905,535) buf[i]= qp - buf[i-1]; (violates patent #?) for more examples, see http://mplayerhq.hu/~michael/patent.html stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en
participants (4)
-
Arpi -
D Richard Felker III -
Michael Niedermayer -
Reimar Döffinger