Merging and Separating Multiple Independent Pipelines.

Sebastian Dröge sebastian at centricular.com
Sat Jan 16 00:07:49 PST 2016


On Fr, 2016-01-15 at 12:40 -0500, Nicolas Dufresne wrote:
> Le vendredi 15 janvier 2016 à 12:04 -0500, Stirling Westrup a écrit :
> > My boss has just floated the idea of having me write an AV Router
> > using gstreamer. This would be a program that would be able to take
> > multiple input AV streams (video files, capture cards, broadcast
> > streams) and mix, match and combine them, and route the multiple
> > results to multiple output streams (display monitors, save files,
> > broadcast transmission) and be able to be reconfigured dynamically
> > while running.
> > 
> > Thus we might have multiple pipelines in a single program, and those
> > pipelines might need to suddenly be combined or separated.
> > 
> > For example, imagine we have two independent video streams, each with
> > its own pipeline. We're taking two video files, decoding them, and
> > sending the results to two monitors. Then a user asks for the two
> > monitors to be combined into one using picture-in-picuture.
> > 
> > Suddenly, without stopping anything, the code needs to be able to
> > merge the two pipelines using some sort of overlay element. And,
> > naturally, we may later decide to undo that operation and have two
> > separate pipelines again.
> > 
> > Is this even possible in the current framework?
> 
> I would rather suggest to use a single pipeline. You can have
> independent graph within the same pipeline. Otherwise, you'd have to
> multiplex the sources/sinks (using intervideosrc/intervideosink) which
> is less convenient. You also want to share the same latency across the
> graphs as you changing the latency is not gap-less. The technique I
> use, is to fix a maximum latency for my system and I make sure that my
> worst case graph have less or equal amount of latency.

Or you actually use separate pipelines and combine them with the
elements you mentioned, or in many cases it's more convenient to
combine them with an appsink/appsrc combination or custom sink/src
elements.
Getting the timing and latency right with separate pipelines is also
not rocket science, it's the same approach you would do for
synchronizing pipelines on multiple devices.

If using one or multiple pipelines makes sense depends on your exact
use case, but one reason why multiple might be a better choice would be
that they are completely independent and not interferring with each
other at all other than exchanging actual data. You won't have to do
anything complicated to catch errors in parts of a single huge
pipeline, safely remove elements but instead would just have to tear
down one separate pipeline whenever something goes wrong.

-- 
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/20160116/f31e6dbc/attachment-0001.sig>


More information about the gstreamer-devel mailing list