[gst-devel] Debugging a blocked GStreamer pipeline

[Stefan Kost]

Am 02.09.2010 04:15, schrieb Todd Fischer:
> Hi,
> 
> We are seeing a behavior where we run a GStreamer application (doing audio /
> video decoding), that runs continuously for several days, then suddenly locks up
> in the middle of an A/V stream.  Our best guess is there is a defect in the ALSA
> output driver.  We believe this because if we exit the application and try
> aplay, it doesn't work.
> 
> I am wondering if there is a debug GStreamer logger element in existence or if
> one is even possible or helpful.  Such a logger element could be put anywhere in
> the pipeline. The logger would have circular buffers to keep track of all
> potentially interesting recent history, such as pad activity, bus activity, and
> any other relevant information. The circular buffer entries would all be
> timestamped. When some event occurs (a file exists, a message/signal is
> received, etc), the element would dump the history, and continue capturing new data.
> 
> This idea is after the pipeline locks up, you could cause the history logger to
> dump it data, and then get an idea of what is suppose to be happening that isn't
> not occurring.
> 
> Does such a logging element exist?  If not, does it make any sense to develop?

You can use gst-tracelib. It is a ld-preload thing for linux boxes. It can log
all dataflow (buffers, events, messages and queries) as well as structural
changes. Logging can be file, memory or socket.

Stefan

> 
> Todd
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
> 
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> 
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel