[gst-devel] RGB mimetyping in gstreamer & lcs

[David Schleef]

On Tue, Jul 15, 2003 at 01:14:10PM +0200, Ronald Bultje wrote:
> xvideosink, for example, is actually heavily broken. It
> doesn't check rgb_masks at all! And most plugins don't! And we never
> intended them to do so, imo.

Yes, these have all just been broken.  For the most part, _nothing_
has ever worked with RGB on PowerPC, at least on my machine.

> Ok, so what I want to use in GStreamer is to go back to the
> bpp/depth/endianness defines, and no more. So RGB24BE in GStreamer would
> then look like this:
> 
> video/x-raw-rgb
> endianness=G_BIG_ENDIAN
> bpp=24
> depth=24
> 
> And now that we know the depth+endianness, we automatically know that
> the corresponding LCS-tag is "RGB24".

How does this differentiate between x1r5g5b5_le and x1b5g5r5_le?
Do we not support BGR formats?  It's marginal, but still useful.
I'm not going to complain about not supporting RBG formats, though.

Currently, I'm interested in exploring how well a text string
describing the bit order would work, similar to the string above.
The string "x1r5g5b5" would indicate 16-bit-depth, 15-bit-per-pixel
xRRRRRGG GGGBBBBB.

> For small-scale and simple
> stuff, we can just define new RGB types and add them to the list of
> supported formats in LCS and in docs/random/mimetypes, and we'll have a
> new format either way.

The idea was to get away from having a registry of formats.  Working
under the assumption that the GStreamer universe is larger than just
gstreamer and gst-plugins, then having a registry of formats means
that someone has to keep track of all the formats out there, in all
the different GStreamer-based plugin packages.  IMO, it's better to
have a very flexible system that supports everything that people can
imagine.  But yes, that's more complex.

FWIW, I'm not entirely comfortable with the current fourcc system
for YUV for this reason.  There's no fourcc for planar non-subsampled
8-bit YUV, or for any >8-bit YUV.  This is a problem.  Do we try to
register new fourccs, or just squat?

Alternatively, we could separate video/x-raw-rgb and video/x-raw-yuv
each into 2 media types, one for "registry" formats, and one for a
generic description of the format.  Everything existing for YUV would
go to video/x-raw-yuv-registry, and we could create a registry of
interesting RGB formats for video/x-raw-rgb-registry.  And then use
video/x-raw-yuv-generic for planar 8-bit and 10-bit formats, and use
video/x-raw-rgb-generic for all those silly RGB formats that I pretend
to be concerned about.

> For GStreamer, it will be much simpler. The
> disadvantage is that we're giving up our byte-wise approach of RGB24/32,
> but I never liked that anyway, since it's specific to 8bpc RGB and won't
> work for 5/6/10/16bpc RGB (note: 16bpc in our current approach has
> endianness issues *per component*! That's fixed here, too).

You'll see no tears here.



dave...