GNOME Bugzilla – Bug 564115
[PATCH] fbdev: remove endianness swapping
Last modified: 2009-07-16 18:59:58 UTC
Swapping r- g- and bmask is weird. It turns i.E. RGB888 to BGR888. For formats like RGB666 it turns the mask into a mess. Seems that gstreamer treat all True color as Big Endian. Still I doubt that it makes sense to swap the masks. I'm however not quite sure about this, comments are highly welcome.
Created attachment 124418 [details] [review] patch removes swapping endianess
Only the non 8-bit per color formats use the endianness because it's painfull (impossible) to express with masks. The 8-bit formats always use big-endian. What exactly is the problem here?
Thx for your comment. Like I said, I was still quite not sure about the color masking in gstreamer. e.g. the rmask ist built in fbdev with ((1 << fbdevsink->varinfo.red.length) - 1) << fbdevsink->varinfo.red.offset; Say if we have RGB888 with red.length = 8 and red.offset = 16 in varinfo. fbdevsink turns after calling swapendian() into BGR888. I quite don't get it what for. Besides, swapendian() doesn't work with masks with are not aligned on byte edges. I'm hacking on rgb666 support. Which means that the rmask is 0x000f3000. swapendian() turns it into 0x00300f00, which doesn't make lot of sense. Cheers Luotao Fu
I am reopening this bug as the questions in comment #2 have been answered. However, feel free to ask further questions or close as WONTFIX or NOTABUG.
For 32/24 bits the code is correct as explained above, for RGB666 you have to make sure to use the correct endianness. Take a look at ffmpegcolorspace for an example.