Overrun issue in Decodebin2/Multiqueue

Stefan Sauer ensonic at hora-obscura.de
Thu Feb 2 05:05:41 PST 2012 

On 01/27/2012 07:48 AM, Jayanth K.P wrote:
> Hi,
>
>   When pipeline is getting stuck, attached the process to get the
> stack trace . The mail has the stack trace for your reference. 
> I request somebody to provide me pointers to resolve this issue as
> this is really blocking my development ..

(1) Is that happen for all files or just for a particular one.
(2) Do the file otherwise play fine?
(3) Can you mux the files that file to another format.
You need to narrow doen where the problem lies.
(1) could be badly muxed file (long audio segments) => raise multiqueue
buffer-time
(2) if not, file a bug and link to the file
(3) maybe a problem with the muxer

Stefan

>
> -Jayanth
>
> (gdb) t3
> #0  0x00002b2e73d5e1c6 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1  0x00002aaaab097bbc in gst_collect_pads_chain (pad=0xbbeb10,
> buffer=0x0) at gstcollectpads.c:1397
> #2  0x00002b2e7629931e in gst_pad_push (pad=0xbb63c0,
> buffer=0x2aaaacbe2e90) at gstpad.c:4665
> #3  0x00002b2e7627c9e6 in gst_proxy_pad_do_chain (pad=0xb6ca50,
> buffer=0x2aaaacbe2e90) at gstghostpad.c:163
> #4  0x00002b2e7629931e in gst_pad_push (pad=0xbbe690,
> buffer=0x2aaaacbe2e90) at gstpad.c:4665
> #5  0x00002aaaabb2b23b in gst_single_queue_push_one (mq=0xbbf000,
> sq=0xbd2600, object=0x2aaaacbe2e90) at gstmultiqueue.c:980
> #6  0x00002aaaabb2b9e3 in gst_multi_queue_loop (pad=0xbbe690) at
> gstmultiqueue.c:1178
> #7  0x00002b2e762c92da in gst_task_func (task=0xb94200) at gsttask.c:318
> #8  0x00002b2e762ca463 in default_func (tdata=0xb7e2b0, pool=0xb0a010)
> at gsttaskpool.c:70
> #9  0x00002b2e767ab411 in __gxx_personality_v0 () from
> /home/recordserver_rtm/recorder_package_6_17/recorder_package/recorder/libs/libglib-2.0.so.0
> #10 0x00002b2e767a9bd5 in __gxx_personality_v0 () from
> /home/recordserver_rtm/recorder_package_6_17/recorder_package/recorder/libs/libglib-2.0.so.0
> #11 0x00002b2e73d5a143 in start_thread () from /lib64/libpthread.so.0
> #12 0x00002b2e75d4974d in clone () from /lib64/libc.so.6
> #13 0x0000000000000000 in ?? ()
>
>
> (gdb) t 4
> [Switching to thread 4 (Thread 1124112704 (LWP 2469))]#0 
> 0x00002b2e73d5e1c6 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> (gdb) bt
> #0  0x00002b2e73d5e1c6 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1  0x00002aaaab09b188 in gst_data_queue_pop (queue=0xb74740,
> item=0x43009060) at gstdataqueue.c:501
> #2  0x00002aaaabb2b595 in gst_multi_queue_loop (pad=0xbbe210) at
> gstmultiqueue.c:1092
> #3  0x00002b2e762c92da in gst_task_func (task=0xb94100) at gsttask.c:318
> #4  0x00002b2e762ca463 in default_func (tdata=0xb92e80, pool=0xb0a010)
> at gsttaskpool.c:70
> #5  0x00002b2e767ab411 in __gxx_personality_v0 () from
> /home/recordserver_rtm/recorder_package_6_17/recorder_package/recorder/libs/libglib-2.0.so.0
> #6  0x00002b2e767a9bd5 in __gxx_personality_v0 () from
> /home/recordserver_rtm/recorder_package_6_17/recorder_package/recorder/libs/libglib-2.0.so.0
> #7  0x00002b2e73d5a143 in start_thread () from /lib64/libpthread.so.0
> #8  0x00002b2e75d4974d in clone () from /lib64/libc.so.6
> #9  0x0000000000000000 in ?? ()
>
>
> (gdb) t 5
> [Switching to thread 5 (Thread 1140898112 (LWP 2468))]#0 
> 0x00002b2e73d5e1c6 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> (gdb) bt
> #0  0x00002b2e73d5e1c6 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1  0x00002aaaab09ab14 in gst_data_queue_push (queue=0xb746c0,
> item=0x2aaab07b6760) at gstdataqueue.c:436
> #2  0x00002aaaabb2bc88 in gst_multi_queue_chain (pad=0xbbe510,
> buffer=0x2aaab07ade90) at gstmultiqueue.c:1253
> #3  0x00002b2e7629931e in gst_pad_push (pad=0xbbe390,
> buffer=0x2aaab07ade90) at gstpad.c:4665
> #4  0x00002aaaac1c0433 in gst_flv_parse_tag_audio () from
> /home/recordserver_rtm/recorder_package_6_17/recorder_package/recorder/libs/gst/libgstflv.so
> #5  0x00002aaaac1bac49 in __gxx_personality_v0 () from
> /home/recordserver_rtm/recorder_package_6_17/recorder_package/recorder/libs/gst/libgstflv.so
> #6  0x00002b2e7629931e in gst_pad_push (pad=0xb5e4b0,
> buffer=0x2aaab07d1920) at gstpad.c:4665
> #7  0x00002aaaabb47c09 in gst_type_find_element_chain (pad=0xb5e330,
> buffer=0x2aaab07d1920) at gsttypefindelement.c:765
> #8  0x00002b2e7629931e in gst_pad_push (pad=0xb6c030,
> buffer=0x2aaab07d1920) at gstpad.c:4665
> #9  0x00002b2e7627c9e6 in gst_proxy_pad_do_chain (pad=0xb6b000,
> buffer=0x2aaab07d1920) at gstghostpad.c:163
> #10 0x00002b2e762980be in gst_pad_chain_data_unchecked (pad=0xb6b000,
> is_buffer=1, data=0x2aaab07d1920, cache=0x0) at gstpad.c:4231
> #11 0x00002b2e76298bc7 in gst_pad_push_data (pad=0xb5e030,
> is_buffer=1, data=0x2aaab07d1920, cache=0x0) at gstpad.c:4463
> #12 0x00002b2e76299447 in gst_pad_push (pad=0xb5e030,
> buffer=0x2aaab07d1920) at gstpad.c:4685
> #13 0x00002aaaab0818c2 in gst_base_src_loop (pad=0xb5e030) at
> gstbasesrc.c:2508
> #14 0x00002b2e762c92da in gst_task_func (task=0xb94000) at gsttask.c:318
> #15 0x00002b2e762ca463 in default_func (tdata=0xb6deb0, pool=0xb0a010)
> at gsttaskpool.c:70
> #16 0x00002b2e767ab411 in __gxx_personality_v0 () from
> /home/recordserver_rtm/recorder_package_6_17/recorder_package/recorder/libs/libglib-2.0.so.0
> #17 0x00002b2e767a9bd5 in __gxx_personality_v0 () from
> /home/recordserver_rtm/recorder_package_6_17/recorder_package/recorder/libs/libglib-2.0.so.0
> #18 0x00002b2e73d5a143 in start_thread () from /lib64/libpthread.so.0
> #19 0x00002b2e75d4974d in clone () from /lib64/libc.so.6
> #20 0x0000000000000000 in ?? ()
>
>
>
>
>
>
> On Wed, Jan 25, 2012 at 4:53 PM, Jayanth K.P <kp.jayanth at gmail.com
> <mailto:kp.jayanth at gmail.com>> wrote:
>
>     Hi,
>
>     I am Using DecodeBin2 to transmux a FLV file into a MPEG-TS.
>     Application is using "*autoplug-continue*" event to select the
>     appropriate demuxer
>     and "*pad-added*" signal to link to sink pad of mpegTsMux.
>
>     During the transmuxing process, the Pipeline is getting stuck .
>     After enabling the gst debug(to level 5), we found that the
>     pipeline is getting stuck when the
>     Multiqueue is emitting either the underrun or overrun signal.
>
>     I had the following questions regarding the multiqueue/decodebin2 and
>     underrun/overrun
>
>     1.  Why does underrun and overrun happen in the multiqueue in this
>     kind of pipeline.
>     2.  What happens when underrun and overrun happens with respect to
>     decodebin2. ?
>     3.  What are properties (Like max-size-time, max-size-buffers,
>     max-size-bytes) of decodebin2 or multiqueue that can impact
>     overrun or underrun? .
>     4.  What should be done by the application when there is underrun
>     or overrun ?
>
>     Any help/pointers on this would be greatly appreciated.
>
>     Regards,
>     Jayanth
>
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20120202/7aa4fac6/attachment-0001.htm>

More information about the gstreamer-devel mailing list