How to force a GstBufferPool flush?

[Jorge]

Hi all!

I'm using an old 1.4.5 gstreamer release. I have sometimes a deadlock in the 'default_acquire_buffer()' method from gstbufferpool.c when a video playing is

already ended. The code has a comment:

    /* now we release the control socket, we wait for a buffer release or
     * flushing */
    gst_poll_read_control (pool->priv->poll);
    GST_LOG_OBJECT (pool, "waiting for free buffers or flushing");
    gst_poll_wait (priv->poll, GST_CLOCK_TIME_NONE);
    gst_poll_write_control (pool->priv->poll);

and I would like to know how to force a flush in order to get the control back to my application.

In the same file is the 'gst_buffer_pool_set_flushing' method. What's the way to get a flush done?

With gst_event_new_flush_start()/stop() methods? With 'gst_bus_set_flushing()'?

Thanks!

Jorge

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

[Nicolas Dufresne-5]

Le mardi 25 avril 2017 à 10:49 +0000, Jorge Fernandez Monteagudo a
écrit :
> Hi all!
>
> I'm using an old 1.4.5 gstreamer release. I have sometimes a deadlock
> in the 'default_acquire_buffer()' method from gstbufferpool.c when a
> video playing is
> already ended. The code has a comment:

Since 1.4, we added the method gst_buffer_pool_set_flushing(). Setting
the flusing state to TRUE will unblock all calls to acquire, and will
make future acquire() call to return GST_FLOW_FLUSHING. This was added
since previously the only way to unblock a pool was
gst_buffer_set_active(), which has the side effect of freeing all the
buffers. You have to be own of the pool (that element that activated
that pool) to do so. In general, you will combined this with
implementation of unclock/unclock_stop method in various base classes.

>
>     /* now we release the control socket, we wait for a buffer
> release or
>      * flushing */
>     gst_poll_read_control (pool->priv->poll);
>     GST_LOG_OBJECT (pool, "waiting for free buffers or flushing");
>     gst_poll_wait (priv->poll, GST_CLOCK_TIME_NONE);
>     gst_poll_write_control (pool->priv->poll);
>
> and I would like to know how to force a flush in order to get the
> control back to my application.
> In the same file is the 'gst_buffer_pool_set_flushing' method. What's
> the way to get a flush done?
> With gst_event_new_flush_start()/stop() methods? With
> 'gst_bus_set_flushing()'?
>
> Thanks!
> Jorge
> _______________________________________________
> 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

[Jorge]

>Since 1.4, we added the method gst_buffer_pool_set_flushing(). Setting
>the flusing state to TRUE will unblock all calls to acquire, and will
>make future acquire() call to return GST_FLOW_FLUSHING. This was added
>since previously the only way to unblock a pool was
>gst_buffer_set_active(), which has the side effect of freeing all the
>buffers. You have to be own of the pool (that element that activated
>that pool) to do so. In general, you will combined this with
>implementation of unclock/unclock_stop method in various base classes.

Two questions:

1) I'm not implementing any gstreamer component, the last sentence about

unclock/unclock_stop don't apply, right?

2) How can I access the bufferpool?? My pipeline is something like:

gst-launch-1.0 filesrc location=$1 typefind=true ! video/quicktime ! qtdemux ! vpudec ! appsink

In gdb the backtrace for the locked thread I see this call chain:

gst_poll_wait at gstpoll.c:1248
default_acquire_buffer at gstbufferpool.c:1120
gst_buffer_pool_acquire_buffer at gstbufferpool.c:1209
gst_video_decoder_allocate_output_buffer at gstvideodecoder.c:3520
gst_vpu_dec_object_get_gst_buffer at gstvpudecobject.c:1006
gst_vpu_dec_object_decode at gstvpudecobject.c:1231
gst_video_decoder_decode_frame at gstvideodecoder.c:3015
gst_video_decoder_chain_forward at gstvideodecoder.c:1882
gst_video_decoder_chain at gstvideodecoder.c:2183
gst_pad_push_data at gstpad.c:3830
gst_pad_push_data at gstpad.c:4063
gst_pad_push at gstpad.c:4174
gst_qtdemux_decorate_and_push_buffer at qtdemux.c:4139
gst_qtdemux_loop at qtdemux.c:4286
gst_qtdemux_loop at qtdemux.c:4363
gst_task_func at gsttask.c:316
g_thread_pool_thread_proxy at gthreadpool.c:307
g_thread_proxy at gthread.c:764
start_thread at pthread_create.c:338

The qtdemux object is waiting for a buffer from the buffer pool.

The complete gdb backtrace is:

[Switching to thread 2 (Thread 0x39300410 (LWP 989))]
#0  0x75cc0394 in __GI_ppoll (fds=0x51038820, nfds=1, timeout=<optimized out>, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:56
56    ../sysdeps/unix/sysv/linux/ppoll.c: No such file or directory.
(gdb) bt
#0  0x75cc0394 in __GI_ppoll (fds=0x51038820, nfds=1, timeout=<optimized out>, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:56
#1  0x761bac48 in gst_poll_wait (set=0x51084008, timeout=<optimized out>)
    at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0/1.4.5-r0/gstreamer-1.4.5/gst/gstpoll.c:1248
#2  0x7616f318 in default_acquire_buffer (pool=0x510ae360 [GstVideoBufferPool], buffer=0x392ff794, params=0x76360de4 <allocator>)
    at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0/1.4.5-r0/gstreamer-1.4.5/gst/gstbufferpool.c:1120
#3  0x76170c04 in gst_buffer_pool_acquire_buffer (pool=0x510ae360 [GstVideoBufferPool], buffer=0x392ff794, buffer@entry=0x392ff78c, params=params@entry=0x0)
    at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0/1.4.5-r0/gstreamer-1.4.5/gst/gstbufferpool.c:1209
#4  0x747813b8 in gst_video_decoder_allocate_output_buffer (decoder=decoder@entry=0x50ca2138 [GstVpuDec])
    at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/gstreamer1.0-plugins-base/1.4.5-r0/gst-plugins-base-1.4.5/gst-libs/gst/video/gstvideodecoder.c:3520
#5  0x7464d348 in gst_vpu_dec_object_get_gst_buffer (bdec=0x50ca2138 [GstVpuDec], bdec@entry=0x7615d0f8, vpu_dec_object=vpu_dec_object@entry=0x50ca7118 [GstVpuDecObject])
    at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-imx6unidesa-fb/tmp/work/imx6unidesa-poky-linux-gnueabi/gst1.0-fsl-plugin/4.0.8-r0/gst1.0-fsl-plugins-4.0.8/plugins/vpu/gstvpudecobject.c:1006
#6  0x7464fce8 in gst_vpu_dec_object_decode (vpu_dec_object=0x50ca7118 [GstVpuDecObject], bdec=0x7615d0f8, frame=0x74656268 <__FUNCTION__.23893>)
    at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-imx6unidesa-fb/tmp/work/imx6unidesa-poky-linux-gnueabi/gst1.0-fsl-plugin/4.0.8-r0/gst1.0-fsl-plugins-4.0.8/plugins/vpu/gstvpudecobject.c:1231
#7  0x74778750 in gst_video_decoder_decode_frame (decoder=decoder@entry=0x50ca2138 [GstVpuDec], frame=0x5103dc98)
    at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/gstreamer1.0-plugins-base/1.4.5-r0/gst-plugins-base-1.4.5/gst-libs/gst/video/gstvideodecoder.c:3015
#8  0x74778a88 in gst_video_decoder_chain_forward (decoder=decoder@entry=0x50ca2138 [GstVpuDec], buf=buf@entry=0x5103e730, at_eos=at_eos@entry=0)
    at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/gstreamer1.0-plugins-base/1.4.5-r0/gst-plugins-base-1.4.5/gst-libs/gst/video/gstvideodecoder.c:1882
#9  0x7477b298 in gst_video_decoder_chain (pad=<optimized out>, parent=0x50ca2138 [GstVpuDec], buf=0x5103e730)
    at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/gstreamer1.0-plugins-base/1.4.5-r0/gst-plugins-base-1.4.5/gst-libs/gst/video/gstvideodecoder.c:2183
#10 0x761a40f0 in gst_pad_push_data (data=0x5103e730, type=4112, pad=0x50c8d540 [GstPad])
    at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0/1.4.5-r0/gstreamer-1.4.5/gst/gstpad.c:3830
#11 0x761a40f0 in gst_pad_push_data (pad=0x5112a1c0 [GstPad], type=type@entry=4112, data=<optimized out>, data@entry=0x5103e730)
    at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0/1.4.5-r0/gstreamer-1.4.5/gst/gstpad.c:4063
#12 0x761aca50 in gst_pad_push (pad=<optimized out>, buffer=buffer@entry=0x5103e730)
    at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0/1.4.5-r0/gstreamer-1.4.5/gst/gstpad.c:4174
#13 0x74816550 in gst_qtdemux_decorate_and_push_buffer (qtdemux=0x50c9c070 [GstQTDemux], qtdemux@entry=0x11493, stream=stream@entry=0x51057e00, buf=0x5103e730, dts=400000000,
    dts@entry=2908, pts=400000000, pts@entry=8513413256590654664, duration=40000000, duration@entry=5821135582436642820, keyframe=0,
    keyframe@entry=40000000, position=position@entry=400000000, byte_position=<optimized out>)
    at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0-plugins-good/1.4.5-r0/gst-plugins-good-1.4.5/gst/isomp4/qtdemux.c:4139
#14 0x7482b988 in gst_qtdemux_loop (qtdemux=0x11493)
    at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0-plugins-good/1.4.5-r0/gst-plugins-good-1.4.5/gst/isomp4/qtdemux.c:4286
#15 0x7482b988 in gst_qtdemux_loop (pad=0x76239220)
    at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0-plugins-good/1.4.5-r0/gst-plugins-good-1.4.5/gst/isomp4/qtdemux.c:4363
#16 0x761db6ec in gst_task_func (task=0x3bffe568 [GstTask])
    at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0/1.4.5-r0/gstreamer-1.4.5/gst/gsttask.c:316
#17 0x762b3230 in g_thread_pool_thread_proxy (data=<optimized out>)
    at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/glib-2.0/1_2.42.1-r0/glib-2.42.1/glib/gthreadpool.c:307
#18 0x762b2704 in g_thread_proxy (data=0x50c9ad80)
    at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/glib-2.0/1_2.42.1-r0/glib-2.42.1/glib/gthread.c:764
#19 0x76995de0 in start_thread (arg=0x39300410) at pthread_create.c:338
#20 0x75cccfa0 in  () at ../sysdeps/unix/sysv/linux/arm/clone.S:89

Thanks!

---

De: gstreamer-devel <[hidden email]> en nombre de Nicolas Dufresne <[hidden email]>
Enviado: martes, 25 de abril de 2017 16:35:15
Para: Discussion of the development of and with GStreamer
Asunto: [SENDER UNVERIFIED]Re: How to force a GstBufferPool flush?

 

Le mardi 25 avril 2017 à 10:49 +0000, Jorge Fernandez Monteagudo a
écrit :
> Hi all!
>
> I'm using an old 1.4.5 gstreamer release. I have sometimes a deadlock
> in the 'default_acquire_buffer()' method from gstbufferpool.c when a
> video playing is
> already ended. The code has a comment:

Since 1.4, we added the method gst_buffer_pool_set_flushing(). Setting
the flusing state to TRUE will unblock all calls to acquire, and will
make future acquire() call to return GST_FLOW_FLUSHING. This was added
since previously the only way to unblock a pool was
gst_buffer_set_active(), which has the side effect of freeing all the
buffers. You have to be own of the pool (that element that activated
that pool) to do so. In general, you will combined this with
implementation of unclock/unclock_stop method in various base classes.

>
>     /* now we release the control socket, we wait for a buffer
> release or
>      * flushing */
>     gst_poll_read_control (pool->priv->poll);
>     GST_LOG_OBJECT (pool, "waiting for free buffers or flushing");
>     gst_poll_wait (priv->poll, GST_CLOCK_TIME_NONE);
>     gst_poll_write_control (pool->priv->poll);
>
> and I would like to know how to force a flush in order to get the
> control back to my application.
> In the same file is the 'gst_buffer_pool_set_flushing' method. What's
> the way to get a flush done?
> With gst_event_new_flush_start()/stop() methods? With
> 'gst_bus_set_flushing()'?
>
> Thanks!
> Jorge
> _______________________________________________
> 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

[Nicolas Dufresne-5]

Le mercredi 26 avril 2017 à 05:59 +0000, Jorge Fernandez Monteagudo a
écrit :

> >Since 1.4, we added the method gst_buffer_pool_set_flushing().
> Setting
> >the flusing state to TRUE will unblock all calls to acquire, and
> will
> >make future acquire() call to return GST_FLOW_FLUSHING. This was
> added
> >since previously the only way to unblock a pool was
> >gst_buffer_set_active(), which has the side effect of freeing all
> the
> >buffers. You have to be own of the pool (that element that activated
> >that pool) to do so. In general, you will combined this with
> >implementation of unclock/unclock_stop method in various base
> classes.
>
>
> Two questions:
>
> 1) I'm not implementing any gstreamer component, the last sentence
> about
> unclock/unclock_stop don't apply, right?

Being stuck on a buffer pool is an internal issue.

>
> 2) How can I access the bufferpool?? My pipeline is something like:

You don't access buffer pools from your application.

>
> gst-launch-1.0 filesrc location=$1 typefind=true ! video/quicktime !
> qtdemux ! vpudec ! appsink

If you are using appsink, doing unref on the GstBuffer you hold on
should unblock the bufferpool as it will return back the memory.

>
> In gdb the backtrace for the locked thread I see this call chain:
>
> gst_poll_wait at gstpoll.c:1248
> default_acquire_buffer at gstbufferpool.c:1120
> gst_buffer_pool_acquire_buffer at gstbufferpool.c:1209
> gst_video_decoder_allocate_output_buffer at gstvideodecoder.c:3520
> gst_vpu_dec_object_get_gst_buffer at gstvpudecobject.c:1006
> gst_vpu_dec_object_decode at gstvpudecobject.c:1231
> gst_video_decoder_decode_frame at gstvideodecoder.c:3015
> gst_video_decoder_chain_forward at gstvideodecoder.c:1882
> gst_video_decoder_chain at gstvideodecoder.c:2183
> gst_pad_push_data at gstpad.c:3830
> gst_pad_push_data at gstpad.c:4063
> gst_pad_push at gstpad.c:4174
> gst_qtdemux_decorate_and_push_buffer at qtdemux.c:4139
> gst_qtdemux_loop at qtdemux.c:4286
> gst_qtdemux_loop at qtdemux.c:4363
> gst_task_func at gsttask.c:316
> g_thread_pool_thread_proxy at gthreadpool.c:307
> g_thread_proxy at gthread.c:764
> start_thread at pthread_create.c:338
>
> The qtdemux object is waiting for a buffer from the buffer pool.

This is incorrect, it's VpuDec that waits for a buffers to come back.
This means you application is keeping all the buffers since you are
using appsink.

>
> The complete gdb backtrace is:
>
> [Switching to thread 2 (Thread 0x39300410 (LWP 989))]
> #0  0x75cc0394 in __GI_ppoll (fds=0x51038820, nfds=1,
> timeout=<optimized out>, sigmask=sigmask@entry=0x0) at
> ../sysdeps/unix/sysv/linux/ppoll.c:56
> 56    ../sysdeps/unix/sysv/linux/ppoll.c: No such file or directory.
> (gdb) bt
> #0  0x75cc0394 in __GI_ppoll (fds=0x51038820, nfds=1,
> timeout=<optimized out>, sigmask=sigmask@entry=0x0) at
> ../sysdeps/unix/sysv/linux/ppoll.c:56
> #1  0x761bac48 in gst_poll_wait (set=0x51084008, timeout=<optimized
> out>)
>     at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-
> imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-
> gnueabi/gstreamer1.0/1.4.5-r0/gstreamer-1.4.5/gst/gstpoll.c:1248
> #2  0x7616f318 in default_acquire_buffer (pool=0x510ae360
> [GstVideoBufferPool], buffer=0x392ff794, params=0x76360de4
> <allocator>)
>     at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-
> imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-
> gnueabi/gstreamer1.0/1.4.5-r0/gstreamer-
> 1.4.5/gst/gstbufferpool.c:1120
> #3  0x76170c04 in gst_buffer_pool_acquire_buffer (pool=0x510ae360
> [GstVideoBufferPool], buffer=0x392ff794, buffer@entry=0x392ff78c, par
> ams=params@entry=0x0)
>     at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-
> imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-
> gnueabi/gstreamer1.0/1.4.5-r0/gstreamer-
> 1.4.5/gst/gstbufferpool.c:1209
> #4  0x747813b8 in gst_video_decoder_allocate_output_buffer (decoder=d
> ecoder@entry=0x50ca2138 [GstVpuDec])
>     at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-
> imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-
> gnueabi/gstreamer1.0-plugins-base/1.4.5-r0/gst-plugins-base-
> 1.4.5/gst-libs/gst/video/gstvideodecoder.c:3520
> #5  0x7464d348 in gst_vpu_dec_object_get_gst_buffer (bdec=0x50ca2138
> [GstVpuDec], bdec@entry=0x7615d0f8, vpu_dec_object=vpu_dec_object@ent
> ry=0x50ca7118 [GstVpuDecObject])
>     at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-
> imx6unidesa-fb/tmp/work/imx6unidesa-poky-linux-gnueabi/gst1.0-fsl-
> plugin/4.0.8-r0/gst1.0-fsl-plugins-
> 4.0.8/plugins/vpu/gstvpudecobject.c:1006
> #6  0x7464fce8 in gst_vpu_dec_object_decode
> (vpu_dec_object=0x50ca7118 [GstVpuDecObject], bdec=0x7615d0f8,
> frame=0x74656268 <__FUNCTION__.23893>)
>     at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-
> imx6unidesa-fb/tmp/work/imx6unidesa-poky-linux-gnueabi/gst1.0-fsl-
> plugin/4.0.8-r0/gst1.0-fsl-plugins-
> 4.0.8/plugins/vpu/gstvpudecobject.c:1231
> #7  0x74778750 in gst_video_decoder_decode_frame (decoder=decoder@ent
> ry=0x50ca2138 [GstVpuDec], frame=0x5103dc98)
>     at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-
> imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-
> gnueabi/gstreamer1.0-plugins-base/1.4.5-r0/gst-plugins-base-
> 1.4.5/gst-libs/gst/video/gstvideodecoder.c:3015
> #8  0x74778a88 in gst_video_decoder_chain_forward (decoder=decoder@en
> try=0x50ca2138 [GstVpuDec], buf=buf@entry=0x5103e730, at_eos=at_eos@e
> ntry=0)
>     at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-
> imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-
> gnueabi/gstreamer1.0-plugins-base/1.4.5-r0/gst-plugins-base-
> 1.4.5/gst-libs/gst/video/gstvideodecoder.c:1882
> #9  0x7477b298 in gst_video_decoder_chain (pad=<optimized out>,
> parent=0x50ca2138 [GstVpuDec], buf=0x5103e730)
>     at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-
> imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-
> gnueabi/gstreamer1.0-plugins-base/1.4.5-r0/gst-plugins-base-
> 1.4.5/gst-libs/gst/video/gstvideodecoder.c:2183
> #10 0x761a40f0 in gst_pad_push_data (data=0x5103e730, type=4112,
> pad=0x50c8d540 [GstPad])
>     at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-
> imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-
> gnueabi/gstreamer1.0/1.4.5-r0/gstreamer-1.4.5/gst/gstpad.c:3830
> #11 0x761a40f0 in gst_pad_push_data (pad=0x5112a1c0 [GstPad], type=ty
> pe@entry=4112, data=<optimized out>, data@entry=0x5103e730)
>     at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-
> imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-
> gnueabi/gstreamer1.0/1.4.5-r0/gstreamer-1.4.5/gst/gstpad.c:4063
> #12 0x761aca50 in gst_pad_push (pad=<optimized out>, buffer=buffer@en
> try=0x5103e730)
>     at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-
> imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-
> gnueabi/gstreamer1.0/1.4.5-r0/gstreamer-1.4.5/gst/gstpad.c:4174
> #13 0x74816550 in gst_qtdemux_decorate_and_push_buffer
> (qtdemux=0x50c9c070 [GstQTDemux], qtdemux@entry=0x11493, stream=strea
> m@entry=0x51057e00, buf=0x5103e730, dts=400000000, 
>     dts@entry=2908, pts=400000000, pts@entry=8513413256590654664,
> duration=40000000, duration@entry=5821135582436642820, keyframe=0, 
>     keyframe@entry=40000000, position=position@entry=400000000,
> byte_position=<optimized out>)
>     at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-
> imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-
> gnueabi/gstreamer1.0-plugins-good/1.4.5-r0/gst-plugins-good-
> 1.4.5/gst/isomp4/qtdemux.c:4139
> #14 0x7482b988 in gst_qtdemux_loop (qtdemux=0x11493)
>     at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-
> imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-
> gnueabi/gstreamer1.0-plugins-good/1.4.5-r0/gst-plugins-good-
> 1.4.5/gst/isomp4/qtdemux.c:4286
> #15 0x7482b988 in gst_qtdemux_loop (pad=0x76239220)
>     at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-
> imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-
> gnueabi/gstreamer1.0-plugins-good/1.4.5-r0/gst-plugins-good-
> 1.4.5/gst/isomp4/qtdemux.c:4363
> #16 0x761db6ec in gst_task_func (task=0x3bffe568 [GstTask])
>     at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-
> imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-
> gnueabi/gstreamer1.0/1.4.5-r0/gstreamer-1.4.5/gst/gsttask.c:316
> #17 0x762b3230 in g_thread_pool_thread_proxy (data=<optimized out>)
>     at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-
> imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/glib-
> 2.0/1_2.42.1-r0/glib-2.42.1/glib/gthreadpool.c:307
> #18 0x762b2704 in g_thread_proxy (data=0x50c9ad80)
>     at /mnt/develop/imx6unidesa/yocto-unidesa-3.14.52-1.1.1/build-
> imx6unidesa-fb/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/glib-
> 2.0/1_2.42.1-r0/glib-2.42.1/glib/gthread.c:764
> #19 0x76995de0 in start_thread (arg=0x39300410) at
> pthread_create.c:338
> #20 0x75cccfa0 in  () at ../sysdeps/unix/sysv/linux/arm/clone.S:89
>
> Thanks!
>
> De: gstreamer-devel <[hidden email]>
> en nombre de Nicolas Dufresne <[hidden email]>
> Enviado: martes, 25 de abril de 2017 16:35:15
> Para: Discussion of the development of and with GStreamer
> Asunto: [SENDER UNVERIFIED]Re: How to force a GstBufferPool flush?
>  
> Le mardi 25 avril 2017 à 10:49 +0000, Jorge Fernandez Monteagudo a
> écrit :
> > Hi all!
> > 
> > I'm using an old 1.4.5 gstreamer release. I have sometimes a
> deadlock
> > in the 'default_acquire_buffer()' method from gstbufferpool.c when
> a
> > video playing is
> > already ended. The code has a comment:
>
> Since 1.4, we added the method gst_buffer_pool_set_flushing().
> Setting
> the flusing state to TRUE will unblock all calls to acquire, and will
> make future acquire() call to return GST_FLOW_FLUSHING. This was
> added
> since previously the only way to unblock a pool was
> gst_buffer_set_active(), which has the side effect of freeing all the
> buffers. You have to be own of the pool (that element that activated
> that pool) to do so. In general, you will combined this with
> implementation of unclock/unclock_stop method in various base
> classes.
>
> > 
> >     /* now we release the control socket, we wait for a buffer
> > release or
> >      * flushing */
> >     gst_poll_read_control (pool->priv->poll);
> >     GST_LOG_OBJECT (pool, "waiting for free buffers or flushing");
> >     gst_poll_wait (priv->poll, GST_CLOCK_TIME_NONE);
> >     gst_poll_write_control (pool->priv->poll);
> > 
> > and I would like to know how to force a flush in order to get the
> > control back to my application.
> > In the same file is the 'gst_buffer_pool_set_flushing' method.
> What's
> > the way to get a flush done?
> > With gst_event_new_flush_start()/stop() methods? With
> > 'gst_bus_set_flushing()'?
> > 
> > Thanks!
> > Jorge
> > _______________________________________________
> > 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

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