Dynamically changing a live pipeline with live sinks

[Sérgio Agostinho]

I found the culprit.

The block pad that I installed in the tee's src pad was blocking data flow
for the entire element and not simply the pad it was assigned to. So once
the data flow is blocked simply unlink the desired branch downstream of the
tee and then drop the probe.

I initially thought that having data flowing out of unlinked pads would
cause problems, but apparently not.

Sérgio

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

> 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/20141129/5beaaf6b/attachment.html>