[gst-devel] Re: [gst-cvs] wtay gst-plugins: gst-plugins/ gst-plugins/gst-libs/gst/video/

[Ronald Bultje]

HHi,

On Fri, 16 Jul 2004, Benjamin Otte wrote:
> Quoting Ronald Bultje <rbultje at ronald.bitfreak.net>:
> > On Fri, 16 Jul 2004, Wim Taymans wrote:
> > > Log message:
> > >         * gst-libs/gst/video/video.h:
> > >         Added 32 bits RGBA. Not sure if we should use another mime-type
> > >         for alpha rgb. Currently the presence of the alpha_mask property
> > >         signals an alpha channel. Ronald?
> >
> > Yes, that's the current way. The good thing is that RGB readers can still
> > read RGBA and just discard the alpha-channel, so having the same mimetype
> > would make sense in a way. But it's suboptimal in another way, too. I
> > personally didn't really bother thinking too much about this because I
> > don't see too many RGBA videos nowadays.
> >
> The main reason for using a different mimetype is that it might result in
> issues when you link a sink element that requires an alpha channel with a
> source element that doesn't know about alpha channels. That way an alpha
> channel will be negotiated and the sink element will pretend to use it, while
> the source element fills the alpha bytes with random garbage.

That can never happen. The sink element has the alpha_mask property in its
pad template, and thus the source element's source pad is *required* to
explicitely contain an alpha_mask property in its negotiation caps. If it
doesn't, caps negotiation fails and that's exactly what *should* happen.

The other way around works fine too: if the source element does contain an
alpha_mask but the sink element doesn't use it, it just ignores this
property and thereby the alpha_mask.

So all should be fine.

Ronald