GNOME Bugzilla – Bug 617512
[alpha] should work in passthrough in all formats if alpha == 1.0
Last modified: 2010-06-01 09:24:25 UTC
alpha always converts the incoming gstreamer to an alpha variant, regardless of whether it will need to apply alpha or not. It should be able to passthrough the input buffer without any modifications if the following conditions are met: * method == 'set' * alpha == 1.0 This would allow having the following pipeline push out I420 all the way: videotestsrc ! video/x-raw-yuv,format=I420 ! alpha alpha=1.0 ! video/x-raw-yuv,format={ AYUV, I420 } ! fakesink The caps should be re-negotiated the moment alpha modification is needed (i.e. if you have a running pipeline as above, and you change alpha to 0.99999).
Wouldn't that mean the caps are dependant on when the alpha value was last set - i.e. if you started with alpha=0.9 and while the pipeline ran set it to 1.0 you'd get AYUV, but if you started with alpha=1.0 and didn't set it you'd end up with I420? Or would that mean that for a controlled channel with a tween from 1.0 to 0.0 you'd get I420 in the beginning and AYUV when the tween starts changing the alpha value? Would that mean pipelines that miss a colorspace element could error out half-way through? So in short I think it's a bad idea to make the negotiated caps depend on a controllable (i.e. settable while the pipeline runs) property.
(In reply to comment #1) > Wouldn't that mean the caps are dependant on when the alpha value was last set > - i.e. if you started with alpha=0.9 and while the pipeline ran set it to 1.0 > you'd get AYUV It will start with AYUV, but the moment you set it to 1.0 it should attempt to renegotiate caps (which might or might not end up in pushing out AYUV, depending on what downstream can accept). , but if you started with alpha=1.0 and didn't set it you'd end > up with I420? yes > > Or would that mean that for a controlled channel with a tween from 1.0 to 0.0 > you'd get I420 in the beginning and AYUV when the tween starts changing the > alpha value? yes Would that mean pipelines that miss a colorspace element could > error out half-way through? yes, no big problem there imho. > > So in short I think it's a bad idea to make the negotiated caps depend on a > controllable (i.e. settable while the pipeline runs) property. You do realize you don't need a GstController to change that property ? Changing caps at runtime isn't a problem with other elements (videoscale does that fine), why should it be a problem now ?
(In reply to comment #2) > > So in short I think it's a bad idea to make the negotiated caps depend on a > > controllable (i.e. settable while the pipeline runs) property. > > You do realize you don't need a GstController to change that property ? > Changing caps at runtime isn't a problem with other elements (videoscale does > that fine), why should it be a problem now ? ...only that videoscale changes the caps only if a downstream or upstream element provides new caps. But videobox does what you said and nobody ever complained :) I think it's a good idea to support this in the alpha element too, but maybe make it an extra property. The element's documentation says that the element will add an alpha channel, which it definitely wouldn't with your proposed change.
Created attachment 162008 [details] [review] alpha: Add property to allow passthrough mode This passthrough mode is used if the alpha method is "set" and the alpha value is 1.0. Fixes bug #617512.
commit ab3b4bc82f09204c6a8f694a70ec4ac197267d21 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Wed May 26 13:13:44 2010 +0200 alpha: Add property to allow passthrough mode This passthrough mode is used if the alpha method is "set" and the alpha value is 1.0. Fixes bug #617512.