Playbin with a passthrough sink.

[Tim-Philipp Müller]

On Thu, 2013-01-03 at 18:24 +0000, Nox Deleo wrote:

> I'm trying to use playbin in an unconventional way at the moment.
> Because of its built in functionality, it's ideal for me to use as a
> source that spits out raw audio from a continuous playlist without
> having to reinvent the wheel with different parts. I'm trying to get a
> ghost pad on the outer layer of playbin that I can hook into the rest
> of my pipeline, rather than playbin's 'playsink' being the end of the
> graph.
>
> Looking at a debug graph, it looks like I would have to add ghost pads
> to the 'audio-sink' element I specify, all the way up through a
> GstBin, a GstPlaySink to the PlayBin itself. This is a pretty ugly
> hack, and I don't really like the idea of messing with playbin
> internals, so I'm wondering if anyone knows a better way of doing
> this?

You could use appsink elements to extract the data and then feed them to
another pipeline (set sync=true on the sinks to make them sync against
the clock).

You might possibly also find the inter{audio,video}sink elements useful
(in combination with an inter{audios,video}src in another pipeline.

> Also, out of interest, is there any reason why I can't link a pad
> embedded in several layers of bins to another outside of these? It
> complains about 'no common ancestor' at the moment, but I'm just
> curious as to the reason.

Not sure what you're doing with ghost pads tbh, it just sounds wrong.
You can supply your own sink element, or a bin containing other elements
and ending in a sink (then you need to create a ghost pad for the bin
that points to the first element in the chain inside it). But just
adding ghostpads won't achieve anything.

No common ancestore usually either means you're trying to link an
element that's not inside a pipeline/bin yet, or they're not at the same
level inside the bin/pipeline hierarchy (the reasons ghostpads exist, so
you can expose pads from inside a bin at the one-up bin level).

Cheers
 -Tim