Hanging branch -- dynamically changing (rtpjitterbuffer & compositor)

[keepingitneil]

Hey everyone,

I've been having an issue when changing pipeline dynamically. Here is the pipeline I start with:http://imgur.com/KhaXTB1.png

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.png

Finally, I add in a similar branch on the still-playing pipeline. This is the pipeline after adding that branch: http://imgur.com/fGfS9D6.png

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?

(edited post to have more palatable image links)

[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 <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel