Hanging branch -- dynamically changing (rtpjitterbuffer & compositor)

[Dimitrios Katsaros]

My guess would be that the new stream is starting from a running time of 0,
which is not the running time of the original pipeline. so if you leave the
original pipe running for e.g. 10 seconds and then add the new branch. the
pipe is at 10 and the original is at 0. So the new pipeline needs to "catch
up" to the original pipeline.

There are a couple of things that come to mind. Try adding an identity with
sync=1 and single-segment=1. That may help with timestamp correction. Also
for debugging set the 'eos' parameter to false. If the timestamps are out
of range for the sink position, the eos may be discarding frames further
upstream and it becomes a pain to figure out where exactly those frames are
being dropped. Also the compositor has the "start-time-selection" flag. Try
changing that and see if it has an impact on the output.

dmt


On Thu, Mar 30, 2017 at 12:40 AM, keepingitneil <neil at bebo.com> wrote:

> Hey everyone,
>
> I've been having an issue when changing pipeline dynamically. Here is the
> pipeline I start with:http://imgur.com/KhaXTB1
>
> I remove a branch by blocking the relevant src pads, sending an eos through
> until the compositor, and removing the elements in response to a custom bus
> event. Here's what the pipeline looks like after doing that:
> http://imgur.com/3L4dUtP
>
> Finally, I add in a similar branch on the still-playing pipeline. This is
> the pipeline after adding that branch: http://imgur.com/fGfS9D6
>
> The problem occurs in this third step. The branch I added back in is
> frozen.
> It will start playing eventually but can take minutes (seems to be a
> function of how long the pipeline has been playing). I've tried to play
> with
> tf-offsets and such in the new rtpjitterbuffer with no luck. Timestamp
> overlays show that is indeed hanging. After time, the timestamp would jump
> ahead to what the other branch's timestamps are and would start playing
> again.
>
> Here's a video demonstrating the problem: https://youtu.be/T83uOomIKJI
>
> I've tried after disabling audio. No luck. So definitely a video thing.
> I've tried same pipeline with videotestsrc instead of rtp. Seems to work so
> not likely to be the compositor.
> I've tried different clock modes on the rtpjitterbuffer. I remember "None"
> helping in some specific circumstance but ultimately didn't work in the
> more
> complicated pipeline I'm trying to create (simplified experiment shown
> above)
>
> Any ideas?
>
>
>
> --
> View this message in context: http://gstreamer-devel.966125.
> n4.nabble.com/Hanging-branch-dynamically-changing-
> rtpjitterbuffer-compositor-tp4682452.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170330/3739aa42/attachment.html>