gst-launcher-1.0 : setting pad offset

[Sebastian Dröge]

On So, 2015-06-07 at 20:19 +0000, philippe renon wrote:

>         
> Well I need to introduce the offset upstream of a compositor.
> I can always introduce a second compositor (with a single source) just
> to benefit from the fact that it exposes the pad offset to gst-launch
> (which I have to use at this stage...).
> Not very elegant but could work. 

Why can't you use the pad properties on compositor, but must do the
offset further upstream?

> Is it correct to say that, ideally, all elements should implement
> GstChildProxy and expose pad properties to gst-launch ?

No, and that's not even possible. For example every subclass of GstBin
currently exposes its child elements via GstChildProxy, the equalizer
elements expose the band objects via GstChildProxy, deinterlace exposes
the filter objects, etc.

What is exposed as a "child" of the element completely depends on the
element and its API. For compositor and similar elements it makes sense
to expose the pads, for others not.

> Is that in line with a hypothetical long term road map or would it
> just be plain stupid ?

Just write code in a proper programming language of your choice :)
gst-launch is limited in more than this way.

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150607/8f4b340c/attachment-0001.sig>