[Gstreamer-bugs] [Bug 112621] Changed - lots of plugins get RGB caps wrong

[bugzilla-daemon at widget.gnome.org]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=112621

Changed by rbultje at ronald.bitfreak.net.

--- shadow/112621	Fri May  9 15:41:58 2003
+++ shadow/112621.tmp.24052	Fri May  9 17:48:04 2003
@@ -99,6 +99,25 @@
  I don't think that anything less addresses the problem correctly.
 
 However, I don't think that anyone will actually use caps in this way.
  The primary use of RGB caps appears to be converting to/from a
 library's #define'd format.  This mostly just means knowing how to
 specify the library's format as gst caps.
+
+------- Additional Comments From rbultje at ronald.bitfreak.net  2003-05-09 17:48 -------
+Benjamin, before the patch, it works that way. Don't forget you have
+to bitshift to actually get the red value, so:
+
+guint32 red = *(guint32 *) data & redmask;
+int num_shifts = 0;
+while (redmask && !(redmask & 1))
+  redmask >>= 1;
+red >>= num_shifts;
+
+would give you the actual bytevalue of red.
+
+Dave, you're saying a lot of plugins currently have to use #ifdefs to
+convert masks depending on byte order. That sounds weird, it'd mean
+that the libs we depend on don't actually make proper use of RGB data
+depending on endianness, which seems more like an issue with them than
+with us, unless this is for a specific purpose. I don't see this
+happening a lot, actually.