rtpjitterbuffer - dynamically changing pipeline - Bug?

[keepingitneil]

I have a pipeline that looks something like this:

udpsrc0 -> rtpjitterbuffer0 -> rtp_foo_depay -> some more elements ->
compositor
udpsrc1 -> rtpjitterbuffer1 -> rtp_foo_depay -> some more elements ->
compositor
udpsrc2 -> rtpjitterbuffer2 -> rtp_foo_depay -> some more elements ->
compositor
etc.

I'm trying to remove one of these branches from the compositor dynamically
on a live pipeline. Here's my recipe:
1) BLOCKING probe on udpsrc (not BLOCK, for some reason that didn't work on
udpsrc but worked on videotestsrc)
2) When udpsrc probe is blocked, add eos event on all other elements' src
pads
3) listen for eos event on all of the elements' sinks via EVENT_DOWNSTREAM |
BLOCK
4) as eos signals come in, set element state to NULL, remove from pipeline
5) on eos signal for last element leading up to compositor, set udpsrc state
to NULL, remove from pipeline, release sink pad into compositor

Critical issue:
rtpjitterbuffer gives me the "You cannot change the state of an element from
its streaming thread" deadlock error.

Questions?
1) why BLOCKING, not BLOCK
2) why does rtpjitterbuffer get the signal on it's streaming thread while
all others in the branch do not?
3) is this flow generally correct?

Thanks,
Neil



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/rtpjitterbuffer-dynamically-changing-pipeline-Bug-tp4681576.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.