[gstreamer-bugs] [Bug 164268] [PATCH][ffmpegcolorspace] Fix BGR <-> RGB handling

[bugzilla-daemon at bugzilla.gnome.org]

Please DO NOT reply to this by email. All additional comments should be made in
the comments box of this bug report.

 http://bugzilla.gnome.org/show_bug.cgi?id=164268
 GStreamer | gst-plugins | Ver: HEAD CVS





------- Additional Comments From Gergely Nagy  2005-01-17 04:18 -------
I think we do not need to rearrange the RGB bytes to BGR, but handle the
RGB<->BGR stuff on the caps level, by setting red_mask and blue_mask
appropriately.

This works fine for me with patched pngdec (which supports only BGR and BGRA on
its srcpad) and ximagesink (which supports only RGB555 on my system).

Lets see... say, we have an E1 ! ffmpegcolorspace ! E2 pipeline, where E1's
srcpad emits RGB24, and E2's sink accepts BGR24 only. The difference between the
two is that red_mask and blue_mask are swapped. We can handle that on the caps
level, no need to rearrange the bytes. This works the other way around too. And
RGB32->BGR24 is the same as RGB32->RGB24 AND red_mask/blue_mask swapping at the
caps level.

All in all, I do not see the need to support rearranging RGB bytes to BGR, since
the recommended way to access component bytes is to use the _mask properties.

This patch removes the byte rearranging-foo, but the caps-level support is still
in there.

------- You are receiving this mail because: -------
You are the assignee for the bug.
You are the QA contact for the bug.