Abuse of intervideosrc/sink to ease pipeline manipulation

[superlou]

Catastrophically dumb idea or just inefficient:

I'm making generic while-playing-pluggable elements (devices, subclassing a
bin) by giving everything "ports" that are "in" or "out" using
intervideosrc/sinks where each channel is a UUID.  Then I found out that
since you can't change the channel property of the intervideosrc/sinks
without setting the element states to null then playing again, I am making
generic links that are are just a bin of intervideosrc->intervideosink where
the channels of the link ends match the UUID channels for the desired
devices to connect.

Is this going to be so inefficient as to ruin the concept, or is it just
inelegant?  I think the alternative is to use pad blocking as described
(http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-dynamic-pipelines.html)
to block the port intervideosink/src pads, then change the channel, set the
element to null, set it back to playing, then release the pad block. 
However, if the extra set of intervideosrc/sink elements making up a link
isn't going to be a huge penalty, I'll stick with that as it seems easier to
implement.



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Abuse-of-intervideosrc-sink-to-ease-pipeline-manipulation-tp4664844.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.