<div dir="ltr"><div><div>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. <br><br></div>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. <br><br></div>dmt<br><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 30, 2017 at 12:40 AM, keepingitneil <span dir="ltr"><<a href="mailto:neil@bebo.com" target="_blank">neil@bebo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey everyone,<br>
<br>
I've been having an issue when changing pipeline dynamically. Here is the<br>
pipeline I start with:<a href="http://imgur.com/KhaXTB1" rel="noreferrer" target="_blank">http://imgur.com/KhaXTB1</a><br>
<br>
I remove a branch by blocking the relevant src pads, sending an eos through<br>
until the compositor, and removing the elements in response to a custom bus<br>
event. Here's what the pipeline looks like after doing that:<br>
<a href="http://imgur.com/3L4dUtP" rel="noreferrer" target="_blank">http://imgur.com/3L4dUtP</a><br>
<br>
Finally, I add in a similar branch on the still-playing pipeline. This is<br>
the pipeline after adding that branch: <a href="http://imgur.com/fGfS9D6" rel="noreferrer" target="_blank">http://imgur.com/fGfS9D6</a><br>
<br>
The problem occurs in this third step. The branch I added back in is frozen.<br>
It will start playing eventually but can take minutes (seems to be a<br>
function of how long the pipeline has been playing). I've tried to play with<br>
tf-offsets and such in the new rtpjitterbuffer with no luck. Timestamp<br>
overlays show that is indeed hanging. After time, the timestamp would jump<br>
ahead to what the other branch's timestamps are and would start playing<br>
again.<br>
<br>
Here's a video demonstrating the problem: <a href="https://youtu.be/T83uOomIKJI" rel="noreferrer" target="_blank">https://youtu.be/T83uOomIKJI</a><br>
<br>
I've tried after disabling audio. No luck. So definitely a video thing.<br>
I've tried same pipeline with videotestsrc instead of rtp. Seems to work so<br>
not likely to be the compositor.<br>
I've tried different clock modes on the rtpjitterbuffer. I remember "None"<br>
helping in some specific circumstance but ultimately didn't work in the more<br>
complicated pipeline I'm trying to create (simplified experiment shown<br>
above)<br>
<br>
Any ideas?<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://gstreamer-devel.966125.n4.nabble.com/Hanging-branch-dynamically-changing-rtpjitterbuffer-compositor-tp4682452.html" rel="noreferrer" target="_blank">http://gstreamer-devel.966125.<wbr>n4.nabble.com/Hanging-branch-<wbr>dynamically-changing-<wbr>rtpjitterbuffer-compositor-<wbr>tp4682452.html</a><br>
Sent from the GStreamer-devel mailing list archive at Nabble.com.<br>
______________________________<wbr>_________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.<wbr>freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/gstreamer-<wbr>devel</a><br>
</blockquote></div><br></div>