Strange issue with pipeline

[Pedro Côrte-Real]

On Sun, Dec 29, 2013 at 5:50 PM, Andrey Utkin
<andrey.krieger.utkin at gmail.com> wrote:
> Does your source provide really parsed stream, with property
> "parsed=true" set? If it is not parsed, then you need to insert parser
> element or autoconvert element configured appropriately (with
> factories property set to a set of parsing-capable element factories).

The source is uridecodebin so it will insert the parser on its own if
I require "parsed=true" in the caps.  I'm basically listening to the
autoplug-continue signal with this code:

g_signal_connect (source, "autoplug-continue", G_CALLBACK(uriplug), NULL);

gboolean uriplug (GstElement *bin, GstPad *pad, GstCaps *caps, gpointer ud) {
  return !gst_caps_is_subset(caps,
                             gst_caps_from_string ("video/x-h264,
parsed=true"));
}

And I then react to the pad-added signal and connect the src pad to
the rest of my pipeline. With "video/x-h264, parsed=true" I can accept
h264 from any source but I'd like to be able to support any video type
that can be streamed into a matroskamux. I'd like something like
"video/*, parsed=true". For my usecase I can probably just accept h264
or mpeg4 or jpeg and cover 90% of the cases.

>> 3) Issue: My pipeline stops writing completely sometimes with no error
>> message and while continuing to spend CPU
>
> Do you check output generated by env variable GST_DEBUG=something (try
> 3 or higher values)?

There is almost no output generated. However at level 4 the final line
before it hangs seems to be:

0:00:02.270669280 12073 0xb640cd50 INFO         rtpjitterbuffer
gstrtpjitterbuffer.c:2607:do_deadline_timeout:<rtpjitterbuffer0> got
deadline timeout

This probably means the buffering wasn't big enough and the pipeline
stalled. When I connect with VLC I see it buffering after a few
moments so that's probably it.

> You can also dump pipeline diagram and check elements states and connections.

How is that done?

Pedro