Pipeline Says it's Playing, but It's Not

[Wes Miller]

I have a C++ (0.10 Windows) pipeline that contains a gst-parse-launch()-ed
version of the GstRtpBin receiver from the examples.  It works very well.

I added a padprobe to the udpsrc element so that I can know when data starts
flowing and who it came from (I can get the Sender's IP address and his
port).  I can also get the timestamps of the received packets.  By watching
these timestamps I can detect that my remote udp sender had gone away.

Let me inject here, the goal of this exercise is to have a tool that detects
when the outside source of data has been interrupted.  With that I can halt
the pipeline and relaunch it waiting for a new talker to come on line.  

To the g_main_loop i added a timer that fires once each second.  In the
callback service routine for the timer, I check to see that the previous
packet's timestamp has advanced past the second previous timestamp and try
to handle the case where it doesn't .   In other words, I can tell when data
starts flowing (pipeline goes from ASYNC to PLAYING and the padprobe starts
generating messages containing advancing timestamps)  and I can tell when
the  data stops flowing (the padprobe message timestamps stop advancing).

Here is the problem.  When the padprobe is not detecting any packets and the
timestamps have halted, the behavior of the pipeline changes.  I detect the
stoppage, so I send an EOS to the pipeline.  It apparently does not
propagate!  I never get a message into my bus_message_callback() saying the
EOS was seen.

I find I can force the pipeline to stop by halting the loop, deref-ing the
pipeline then derefing the  loop.  

In trying this approach I used the GST_IS_ELEMENT macro to see if the
pipeline pointer was still valid and caused a critical warning/error to
popup (GST_IS_ELEMENT(element) failed, I think).  Took that back out and I
get no critical complaints.

So, can someone help me out here with an explanation of why the pipeline
misbehaves after the flow of udp packets is halted?  Or suggest a better
detector? Or a better way to halt and tear down a pipeline and loop?  

Thanks is advance,

Wes






--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Pipeline-Says-it-s-Playing-but-It-s-Not-tp4658881.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.