No pad block on GST_PAD_PROBE_TYPE_IDLE used

[llama]

Hello,

I am trying to get pad block for a very short time, but with no success.

I am using stream with videotestsrc ! ..... ! appsink. I see those frames on API and blayback is smooth.

After a while of streaming i call function to add probe on videotestsrc src pad like this :

auto pad = gst_element_get_static_pad(element, direction.c_str()); // this is not null, returned pad of src type
gulong id = gst_pad_add_probe (pad, GST_PAD_PROBE_TYPE_IDLE, // id = 1
     (GstPadProbeCallback)&Pipe::cb_blocked, (gpointer)this, NULL);

It calls Pipe::cb_blocked and it executes this code :
std::this_thread::sleep_for(std::chrono::microseconds(20000));
return GST_PAD_PROBE_REMOVE;

I expect that for 2s i will have stalled video on API.
But i never get stalled video.

I also checked my pad : bool block = gst_pad_is_blocking(pad); in the same callback.
But ir returns false.

What is wrong with my probe on pad ?
Thanks in advance! :)

[Nicolas Dufresne-5]

Le vendredi 17 février 2017 à 12:28 -0800, LC a écrit :

> Hello,
>
> I am trying to get pad block for a very short time, but with no
> success. 
>
> I am using stream with videotestsrc ! ..... ! appsink. I see those
> frames on
> API and blayback is smooth.
>
> After a while of streaming i call function to add probe on
> videotestsrc src
> pad like this : 
>
> /auto pad = gst_element_get_static_pad(element, direction.c_str());
> // this
> is not null, returned pad of src type
> gulong id = gst_pad_add_probe (pad, GST_PAD_PROBE_TYPE_IDLE, // id =
> 1
>      (GstPadProbeCallback)&Pipe::cb_blocked, (gpointer)this, NULL);/
>
> It calls Pipe::cb_blocked and it executes this code : 
> /std::this_thread::sleep_for(std::chrono::microseconds(20000));
> return GST_PAD_PROBE_REMOVE;/
>
> *I expect that for 2s i will have stalled video on API. *
> But i never get stalled video. 

This is totally normal. As you have non-live source, you will not loose
2 second, you will simply add a 2s delay between two frames. If you
want to drop 2 second of data, you are better with a data probe, and
return GST_PAD_PROBE_DROP, for the duration of two seconds. You'll need
a state for that, since the callback will be called for each buffers.

>
> I also checked my pad : bool block = gst_pad_is_blocking(pad); in the
> same
> callback. 
> But ir returns false.

That is normal, as this state will only be set if you return
GST_PAD_PROBE_OK from a blocking probe callback.

>
> What is wrong with my probe on pad ?
> Thanks in advance! :)

In your case it does not matter the type of probe, since you block
inside the callback. The blocking aspect of the probe is about it's
persistance after you have returned from this function (return
GST_PAD_PROBE_OK). If it's blocking (IDLE or BLOCKING), the pipeline
will stay blocked until you call gst_pad_probe_remove() with the
appropriate pad probe handle. Though, be aware of an implementation bug
in IDLE probe that existed prior to 1.8.2.

https://bugzilla.gnome.org/show_bug.cgi?id=766002

>
>
>
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble
> .com/No-pad-block-on-GST-PAD-PROBE-TYPE-IDLE-used-tp4681929.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel