[SENDER UNVERIFIED]Re: How to force a GstBufferPool flush?
Nicolas Dufresne
nicolas at ndufresne.ca
Thu Apr 27 16:25:04 UTC 2017
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 at 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 at 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 at entry=0x392ff78c, par
> ams=params at 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 at 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 at entry=0x7615d0f8, vpu_dec_object=vpu_dec_object at 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 at 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 at en
> try=0x50ca2138 [GstVpuDec], buf=buf at entry=0x5103e730, at_eos=at_eos at 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 at entry=4112, data=<optimized out>, data at 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 at 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 at entry=0x11493, stream=strea
> m at entry=0x51057e00, buf=0x5103e730, dts=400000000,
> dts at entry=2908, pts=400000000, pts at entry=8513413256590654664,
> duration=40000000, duration at entry=5821135582436642820, keyframe=0,
> keyframe at entry=40000000, position=position at 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 <gstreamer-devel-bounces at lists.freedesktop.org>
> en nombre de Nicolas Dufresne <nicolas at ndufresne.ca>
> 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
> > gstreamer-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170427/c8e2e68b/attachment.sig>
More information about the gstreamer-devel
mailing list