This is probably a case of not large enough queues, by default x264enc has a pretty large latency, try to either increase the size of the queues or set tune=zerolatency

Setting to NEEDINFO for now, please let us know whether that fixed it :)

My impression is that we already address this in https://bugzilla.gnome.org/show_bug.cgi?id=789467

With adding QoS to the encoder. A leaky queue could also work, but may not drop the appropriate frames.

(In reply to Nicolas Dufresne (stormer) from comment #2)
> My impression is that we already address this in
> https://bugzilla.gnome.org/show_bug.cgi?id=789467
> 
> With adding QoS to the encoder. A leaky queue could also work, but may not
> drop the appropriate frames.

Hm maybe, what I observe here with videotestsrc is simply that the pipeline fails to preroll with:

gst-launch-1.0 videotestsrc ! tee name=teebranch ! queue ! autovideosink teebranch. ! queue ! x264enc ! fakesink

because the video sink branch prerolls then blocks, and the encoder branch never pushes a buffer because its latency is superior to 1 second :)

Hi
this latest case is close to original issue.
I mean originally instead x264enc I did use my custom OpenCV plugin.

So does any body know why pipe freezes and how it could be resolved?
I mean probably somehow allow to drop frames or other things... ???

(In reply to Alex from comment #4)
> Hi
> this latest case is close to original issue.
> I mean originally instead x264enc I did use my custom OpenCV plugin.
> 
> So does any body know why pipe freezes and how it could be resolved?

There may be multiple reasons for that, as we do not know the implementation of your custom plugin, we can only guess: does your plugin need more than one second of buffers before it outputs something ? If you know exactly what latency it introduces, you can use that to set a higher max-size-time on the queues. Alternatively, you could also set async=false on the fakesink.

> I mean probably somehow allow to drop frames or other things... ???

It really depends on what the problem is, we can't really know that for your custom element. For the pipeline with an x264enc , you can use either of the solutions I pointed out earlier (larger queues, tune=zerolatency).

Hi
Yes my plugin sometime takes more than one second but
1) when I did try to use sleep(1) for one second. I scan see messages of the gstreamer-bus about dropped frames
2) But when I did try to use CPU overloaded like:

    static int val =0;
    ++val;
    if(val > 40)
    {
        val = 0;
        for(int i = 0;  i< 4000; ++i)
        {
            sleep(0);
        }
    }
pipe freezes

If you cannot provide more information about how to reproduce the issue, I'm afraid I'm going to have to close this as INVALID. Please feel free to come and discuss the implementation of your custom plugin in our IRC, or on the mailing list :)