YUV422 enc INPUT --> BGR24 dec OUTPUT ??

[xmerlin]

Hi to all.

I'm writing on a simple piece of code that accepts in input a YUV422 image, encodes it with XVID and then decodes it to RGB 24 ...but I have found that the output image is in GBR24 format ...how is it possible?

The input colorspace is YUY2 and the output colorspace is RGB24.


Thanks,
Christian

[-h]

Without further data, are you sure it isn't really RGB24 thanks to endian byte order?

There is no code in XviD that could reorder bytes from RGB to BGR.

-h

[xmerlin]

Originally posted by -h
Without further data, are you sure it isn't really RGB24 thanks to endian byte order?

There is no code in XviD that could reorder bytes from RGB to BGR.

-h

I have to swap the r and b components to have the right image ...
(the encoder output is as expected).


YUV422 == YUY2 isn't it ?


Thanks,
Christian

[-h]

What are you decoding/displaying the RGB data with?

One test for this is to load the avi into a program which forces rgb24/rgb32 output, like VirtualDub.

-h

[xmerlin]

dec output --> dump in a PPM file ---> GIMP

Christian

[-h]

You are correct, we output BGR ordering. As XviD's colourspace routines were based on FourCC demands, they output RGB24/32 data as demanded by the FourCC code:

http://www.fourcc.org/fccrgb.htm
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directshow_sp1/htm/uncompressedrgbvideosubtypes.asp

I'm not sure how this works on other platforms, but since no *nix people have ever spoken up about it, I guess it's the same ordering for RGB video there as well. Or it's never been tried before.. mplayer seems to support both RGB and BGR orderings.

-h

[xmerlin]

yes mplayer support also BGR because it has some routines to convert BGR24 --> RGB24.

...I have implemented this simple routine but obviously it adds a delay ~10-15ms on a PIII 1GHz (too high for a REALTIME app)...
(i'm working on a open source piece of code that intend to acquire dv streams, convert them into MJPEG or XVID, send the stream over a network [mainly wireless] ...receive it and output the result to a DV converter D/A or the display it with a custom player)


Christian

[-h]

...I have implemented this simple routine but obviously it adds a delay ~10-15ms on a PIII 1GHz (too high for a REALTIME app)...
(i'm working on a open source piece of code that intend to acquire dv streams, convert them into MJPEG or XVID, send the stream over a network [mainly wireless] ...receive it and output the result to a DV converter D/A or the display it with a custom player)

None of the display components support YUV?

You could disable the mmx rgb24 conversion in xvid.c (just comment out the line that assigns yv12_to_rgb24_mmx) and change the value ordering in colorspace.c (lines 834 through 863, just swap b's and r's).

If you need mmx, this is all I "think" needs to be done, but don't have time to check right now:

yv12_to_rgb24_mmx.asm:
line 379 (blank) - add "movq mm0, mm4"
line 380 ("movq mm0, [TEMP_B1]") - change to "movq mm4, [TEMP_B1]"
line 422 (blank) - add "movq mm0, mm6"
line 423 ("movq mm0, [TEMP_B2]") - change to "movq mm6, [TEMP_B2]"

Or you could try adapting mplayer's colourspace conversion code to XviD, it's probably better.

-h

[xmerlin]

Originally posted by -h
...I have implemented this simple routine but obviously it adds a delay ~10-15ms on a PIII 1GHz (too high for a REALTIME app)...
(i'm working on a open source piece of code that intend to acquire dv streams, convert them into MJPEG or XVID, send the stream over a network [mainly wireless] ...receive it and output the result to a DV converter D/A or the display it with a custom player)

None of the display components support YUV?

You could disable the mmx rgb24 conversion in xvid.c (just comment out the line that assigns yv12_to_rgb24_mmx) and change the value ordering in colorspace.c (lines 834 through 863, just swap b's and r's).

If you need mmx, this is all I "think" needs to be done, but don't have time to check right now:

yv12_to_rgb24_mmx.asm:
line 379 (blank) - add "movq mm0, mm4"
line 380 ("movq mm0, [TEMP_B1]") - change to "movq mm4, [TEMP_B1]"
line 422 (blank) - add "movq mm0, mm6"
line 423 ("movq mm0, [TEMP_B2]") - change to "movq mm6, [TEMP_B2]"

Or you could try adapting mplayer's colourspace conversion code to XviD, it's probably better.

-h


thanks for the infos I'll have a look.

mplayer converts bgr24 to rgb24 with a simple swap cicle...
the problem is that we have to do 3456000 copies/s in memory [PAL 720x576 - 25fps]. So the only possible solution is to make it in the xvid code.


Christian