[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 18:52:07 2003
+++ shadow/112621.tmp.29740	Sat May 10 04:57:04 2003
@@ -169,6 +169,41 @@
 #endif
 
 Arguably, one can make this cleaner, although not smaller.  However,
 one must use #ifdefs for GST_PAD_TEMPLATE_FACTORY().
 
 
+
+------- Additional Comments From rbultje at ronald.bitfreak.net  2003-05-10 04:57 -------
+But this will go for most file-source/file-sink elements. I'm assuming
+that swf inherently always uses big-endian inside? Similarly, AVI
+always contains little endian data. So RGB32 data in an AVI file would
+always look like BGRA:
+
+((guint8 *) data)[0] = b;
+((guint8 *) data)[1] = g;
+((guint8 *) data)[2] = r;
+((guint8 *) data)[3] = a;
+
+Most files/streams simply have an internally defined, fixed, byte
+order. This is simply a portability feature of these files. So
+file/stream elements, in the old case, would always need #ifdefs. In
+the new case, they wouldn't.
+
+Device elements, on the other hand, will always wan the native byte
+order, e.g. for sending stuff to the sound card, xvideo,
+reading/writing v4l, etc. This is because the byte order here always
+depends on the host system. In the old case, we didn't need #ifdefs
+all around, you simply describe (RGB32 as example)
+red_mask=0x00ff0000, blue_mask=0x0000ff00, green_mask=0x000000ff and
+endianness is G_BYTE_ORDER. In the new case, we get exactly the
+problem that file elements have in the old case: we'll need #ifdefs,
+and the caps you described above will be exactly what's needed here, now.
+
+For encoders/decoders/filters, I'm not sure what applies most. This
+basically depends on whether the underlying lib/backend reads data as
+bytes or as guint32's. I'm guessing some libs do the one, other libs
+do the other so I can't say much here.
+
+So my conclusion is that for some elements, fixed byte order is easier
+in describing their caps, while for others, native byte order is
+easier. It doesn't make any difference, really...