Dynamically changing a live pipeline with live sinks

Sérgio Agostinho sergio.r.agostinho at gmail.com
Thu Nov 27 04:15:50 PST 2014


Let me build on this case. I gave it another test, this time with different
elements

v4l2src ! tee name=t \

t. ! queue ! xvimagesink \

t. ! queue ! x264enc ! rtph264pay ! udpsink

Once more, shutting down the udpsink branch, makes the feed in xvimagesink
freeze, even though I explicitly enforce and check that the pipeline is in
playing state. Adding and linking all elements back in the updsink branch,
makes xvimagesink resume the normal behavior.

With this test I can narrow that the issue must be on the way I'm removing
my elements from the stream. Let me provide some additional insight on how
that's being made, once more considering the example of removing the
udpsink branch:

- I first install an event probe in udpsink's pad listening for eos.
(GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM)
- I then block tee src_1 pad. (GST_PAD_PROBE_TYPE_BLOCK_DOWNSTREAM)
- Upon entering the block callback, I send and eos event through the
peer_pad, i. e. through queue_1 sink pad. Note that I do not unblock the
pad (drop the probe) at this point and I do not release the request pad
from the tee element.
- Once the eos is received on udpsink's pad, I drop the event probe, unlink
all the elements belonging to the branch, set their state to NULL and
remove them from the pipeline.
- At this point, the video feed in xvimagesink freezes
- To restore the udpsink branch, I start by adding the elements back to the
pipeline
- I link them all
- I remove the blocking probe from the tee
- I send the entire pipeline to PAUSE and then to PLAY. I'm being forced to
send it to pause first because otherwise the livesinks refuse to transition
to play.

Cheers,
Sérgio

2014-11-25 15:16 GMT+01:00 Sérgio Agostinho <sergio.r.agostinho at gmail.com>:

> Hello,
>
> I'm currently trying to build a pipeline that is changed upon request.
> Most (if not all) of the work has been based on the guidelines provided in
> this example from the manual
> <http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-dynamic-pipelines.html#section-dynamic-changing>.
> For now I'm working with the following setup
>
> pulsesrc ! tee name=t \
>
> t. ! queue ! faac ! rtpmp4apay ! udpsink \
>
> t. ! queue ! audioresample ! tcpserversink
>
>
> My idea is to able to active/deactivate each one of these sinks (and the
> required upstream elements) as needed, while the pipeline is live in
> playing state. Currently I'm facing some issues when I need to disable and
> remove one of the sinks/branches. Every time one of the sinks is not
> needed, I block the corresponding srcpad on the tee element, unlink all
> elements in that branch of the pipeline and remove them from the pipeline,
> set them to a NULL state. When I do that (e.g. udpsink branch), I've
> noticed that the other branch (tcpsink brnahc) stops streaming data. To be
> honest, it is more like it pauses, because once I activate the other one
> again (udpsink branch), it (tcpsink branch) resumes streaming from exactly
> the point it initially stopped. It is as if the tcp branch was buffering
> but not sending data while the udpsink was off.
>
> Any hints on what might be happening?
>
> Sérgio
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20141127/606bfb2c/attachment.html>


More information about the gstreamer-devel mailing list