[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 04:20:15 2003
+++ shadow/112621.tmp.32410	Fri May  9 06:15:00 2003
@@ -31,6 +31,24 @@
   - (almost) every caps definition contains all fields.
 
 ------- Additional Comments From ds at schleef.org  2003-05-09 04:20 -------
 Created an attachment (id=16386)
 proposed patch
 
+
+------- Additional Comments From rbultje at ronald.bitfreak.net  2003-05-09 06:14 -------
+I don't really see why we would want to use BIG_ENDIAN instead of
+host-native endian order. I mean, basically, nothing changes in
+handling anything, and we're just confusing ourselves, right? The only
+advantage of your approach is that it makes it easier to understand
+how the stuff is aligned in bytes, but normally, people shouldn't have
+to care about that in the first place...
+
+I'm really not trying to be a PITA, but I do prefer to use host-native
+endian-order in the caps... Is there any specific case where your
+approach makes an obvious difference to the current one and where it's
+actually an obvious improvement?
+
+Also, note that with your approach, casting a 32-bit RGB buffer to
+guint32 and then applying the mask no longer works on little-endian
+machines, for obvious reasons. This is a clear disadvantage, in my
+opinion...