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

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.