After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 564115 - [PATCH] fbdev: remove endianness swapping
[PATCH] fbdev: remove endianness swapping
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-12-11 13:27 UTC by Luotao Fu
Modified: 2009-07-16 18:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch removes swapping endianess (1.27 KB, patch)
2008-12-11 13:27 UTC, Luotao Fu
none Details | Review

Description Luotao Fu 2008-12-11 13:27:02 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.
Comment 1 Luotao Fu 2008-12-11 13:27:52 UTC
Created attachment 124418 [details] [review]
patch removes swapping endianess
Comment 2 Wim Taymans 2008-12-16 16:01:47 UTC
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?
Comment 3 Luotao Fu 2008-12-18 15:57:34 UTC
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
Comment 4 Tobias Mueller 2009-05-30 14:59:43 UTC
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.
Comment 5 Sebastian Dröge (slomo) 2009-07-16 18:59:58 UTC
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.