Something relatively simple that may help is a "buffers_received" integer property that keeps track of how many buffers have passed through an element.  With that users could see which element the stream was halting on.  It could also help detect balance issues (say on a tee where one sink is too slow), or to see where frames are being dropped.<br>
<br><div class="gmail_quote">On Thu, Aug 9, 2012 at 3:02 PM, Stefan Sauer <span dir="ltr"><<a href="mailto:ensonic@hora-obscura.de" target="_blank">ensonic@hora-obscura.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div class="im">
    <div>On 08/09/2012 08:00 PM, Matt Pekar
      wrote:<br>
    </div>
    <blockquote type="cite">I run this in response to user input:
      <div><br>
      </div>
      <div>
        <div>void display_pipeline_in_chrome(GstElement *pipeline) {</div>
        <div><span style="white-space:pre-wrap"> </span>const
          char* temp_filename = "gst_bin_graph_tmp";</div>
        <div><br>
        </div>
        <div><span style="white-space:pre-wrap"> </span>char
          dot_command[1024];</div>
        <div><span style="white-space:pre-wrap"> </span>char
          chrome_command[1024];</div>
        <div><br>
        </div>
        <div><span style="white-space:pre-wrap"> </span>const
          char* DIR = getenv("GST_DEBUG_DUMP_DOT_DIR");</div>
        <div><span style="white-space:pre-wrap"> </span>//GstDebugGraphDetails
          output_flags =
          GstDebugGraphDetails(GST_DEBUG_GRAPH_SHOW_MEDIA_TYPE |
          GST_DEBUG_GRAPH_SHOW_STATES |
          GST_DEBUG_GRAPH_SHOW_NON_DEFAULT_PARAMS);</div>
        <div><span style="white-space:pre-wrap"> </span>GstDebugGraphDetails
          output_flags = GstDebugGraphDetails(GST_DEBUG_GRAPH_SHOW_ALL);</div>
        <div><span style="white-space:pre-wrap"> </span>GST_DEBUG_BIN_TO_DOT_FILE(GST_BIN(pipeline),
          output_flags, temp_filename);</div>
        <div><br>
        </div>
        <div><span style="white-space:pre-wrap"> </span>snprintf(dot_command,
          sizeof(dot_command), "dot -Tpng %s/%s.dot -o %s/%s.png", DIR,
          temp_filename, DIR, temp_filename);</div>
        <div>
          <span style="white-space:pre-wrap"> </span>snprintf(chrome_command,
          sizeof(chrome_command), "google-chrome %s/%s.png", DIR,
          temp_filename);</div>
      </div>
    </blockquote></div>
    FYI: you can also use xdg-open to open it with a suitable viewer.
    Also using svg is sometimes better when zooming.<div class="im"><br>
    <blockquote type="cite">
      <div>
        <div><br>
        </div>
        <div><span style="white-space:pre-wrap"> </span>system(dot_command);</div>
        <div><span style="white-space:pre-wrap"> </span>system(chrome_command);</div>
        <div>}</div>
        <div><br>
        </div>
        <div>It displays the whole pipeline as an image in Chrome, using
          the Gstreamer debug output from graphviz.</div>
      </div>
    </blockquote>
    <br></div>
    Thing worth looking for in the graph are:<br>
    * disconnected elements (obvious)<br>
    * pads with uppercase 'F' (= flushing) (missing flush stop or
    activation)<br>
    * not negotiated elements (some elements have a long list of caps,
    instead simple caps)<br>
    <br>
    If there are good ideas how, the graphs can be improved to highlight
    more issues, let us know.<span class="HOEnZb"><font color="#888888"><br>
    <br>
    Stefan</font></span><div><div class="h5"><br>
    <blockquote type="cite">
      <div>
        <div><br>
        </div>
        <div>However, that usually isn't enough to tell what's wrong.
           For example, I recently had a pipeline along these lines:</div>
        <div><br>
        </div>
        <div>appsrc ! ffmpegcolorspace ! theoraenc ! rtptheorapay !
          udpsink</div>
        <div><br>
        </div>
        <div>This pipeline looked fine in the graph output, so to debug
          it I used the GST_DEBUG environment variable on each element
          in the pipeline, starting at the top:</div>
        <div><br>
        </div>
        <div>GST_DEBUG=appsrc:5</div>
        <div>--kill and restart</div>
        <div>GST_DEBUG=ffmpegcolorspace:5</div>
        <div>--kill and restart</div>
        <div>GST_DEBUG=theoraenc:5</div>
        <div>--ahhh theoraenc is dropping buffers...</div>
        <div><br>
        </div>
        <div>Doing this one step at a time let me discover which element
          was blocking.  It turns out the problem was I wasn't
          timestamping the appsrc buffers, and therefore theoraenc was
          just dropping them.</div>
        <br>
        <div class="gmail_quote">On Thu, Aug 9, 2012 at 12:38 PM, Eric
          Montellese <span dir="ltr"><<a href="mailto:eric.montellese@videon-central.com" target="_blank">eric.montellese@videon-central.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Folks, in
            development I've run into various malformed or buggy
            pipelines that give this output:
            <div><br>
            </div>
            <div>
              <div>gst-launch  launch ! a ! pipeline</div>
              <div>Setting pipeline to PAUSED ...</div>
              <div>Pipeline is PREROLLING ...</div>
            </div>
            <div><br>
            </div>
            <div>Generally I have debugged these issues through a
              mixture of brute force and intuition (looking for common
              sorts of problems, etc).</div>
            <div><br>
            </div>
            <div>But perhaps there is a better way to determine which
              element has held up the pipeline?  Some swanky debug
              command I'm totally unaware of that shows the buffers
              in-flight perhaps?</div>
            <div><br>
            </div>
            <div>Any advice?</div>
            <div><br>
            </div>
            <div>Thanks,</div>
            <div>Eric</div>
            <br>
            _______________________________________________<br>
            gstreamer-devel mailing list<br>
            <a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
            <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
gstreamer-devel mailing list
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br></blockquote></div><br>