[Bug 704910] sync/ Error creating thread/Segmentation fault

Fri Jul 26 01:12:00 PDT 2013

https://bugzilla.gnome.org/show_bug.cgi?id=704910
  GStreamer | don't know | 1.1.2

--- Comment #4 from troy <765621965 at qq.com> 2013-07-26 08:11:52 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > hi all:
> >    I recently development a project by python gstreamer.It is an recording
> > server. I use udpsrc and rtpbin to recieve audio stream and video stream ,and
> > then push them to 'mp4mux' ,finaly push the stream to 'filesink'. .The pipeline
> > is probably like this :
> >  udpsrc-->rtpbin--->rtph264depay--->h264parse-->mp4mux(video_0)--
> >                                                                  |-->***.mp4
> >  udpsrc-->rtpbin--->...--->faac---------------->mp4mux(audio_0)--
> > 
> >    And I use 'sip' message to control the pipelne,e.g. when I use 'Linphone' to
> > call the server ,the program will set the pipeline to PLAY state. 
> >    There are two serious problems:
> > 
> > 1.audio/video not sync. The '**.mp4' is sync only in 'vlc' player,others player
> > audio will delay about 1s.But when I replace the 'mp4mux' to 'matroskamux',and
> > get the '**.mkv',it is sync with every players.Then I test
> > 'avimux','3gpmux'...they are the same with 'mp4mux',then I am confused...
> 
> Can you attach such a recording as MP4 (with the A/V sync issue), and as MKV
> (with A/V correct)? You probably want to put queues right before both muxer
> sinkpads btw.
> 
> 3gpmux/qtmux/mp4mux are all the same code, just outputting a different variant
> btw.
> 
> > 2.I write an test program to test the server.When I simulated 40  'Linphone' to
> > call the server ,an error accured :
> > (python:15406): GStreamer-WARNING **: failed to create thread: Error creating
> > thread: Resource temporarily unavailable  
> > Segmentation fault (core dumped)
> 
> Can you get with gdb a) a backtrace of the segfault and b) of the warning (for
> that set G_DEBUG=fatal_warnings)

(In reply to comment #1)
> (In reply to comment #0)
> > hi all:
> >    I recently development a project by python gstreamer.It is an recording
> > server. I use udpsrc and rtpbin to recieve audio stream and video stream ,and
> > then push them to 'mp4mux' ,finaly push the stream to 'filesink'. .The pipeline
> > is probably like this :
> >  udpsrc-->rtpbin--->rtph264depay--->h264parse-->mp4mux(video_0)--
> >                                                                  |-->***.mp4
> >  udpsrc-->rtpbin--->...--->faac---------------->mp4mux(audio_0)--
> > 
> >    And I use 'sip' message to control the pipelne,e.g. when I use 'Linphone' to
> > call the server ,the program will set the pipeline to PLAY state. 
> >    There are two serious problems:
> > 
> > 1.audio/video not sync. The '**.mp4' is sync only in 'vlc' player,others player
> > audio will delay about 1s.But when I replace the 'mp4mux' to 'matroskamux',and
> > get the '**.mkv',it is sync with every players.Then I test
> > 'avimux','3gpmux'...they are the same with 'mp4mux',then I am confused...
> 
> Can you attach such a recording as MP4 (with the A/V sync issue), and as MKV
> (with A/V correct)? You probably want to put queues right before both muxer
> sinkpads btw.
> 
> 3gpmux/qtmux/mp4mux are all the same code, just outputting a different variant
> btw.
> 
> > 2.I write an test program to test the server.When I simulated 40  'Linphone' to
> > call the server ,an error accured :
> > (python:15406): GStreamer-WARNING **: failed to create thread: Error creating
> > thread: Resource temporarily unavailable  
> > Segmentation fault (core dumped)
> 
> Can you get with gdb a) a backtrace of the segfault and b) of the warning (for
> that set G_DEBUG=fatal_warnings)
Thank you and the gdb information is as follw ,what the problem is :

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xbba4db40 (LWP 4001)]
__memset_sse2 () at ../sysdeps/i386/i686/multiarch/memset-sse2.S:364
364    ../sysdeps/i386/i686/multiarch/memset-sse2.S: 沒有此一檔案或目錄.
(gdb) bt
#0  __memset_sse2 () at ../sysdeps/i386/i686/multiarch/memset-sse2.S:364
#1  0xb542a9d9 in faacEncOpen () from /usr/lib/libfaac.so.0
#2  0xb6020115 in gst_faac_open_encoder (faac=0x9d9eb28, info=<optimized out>)
at gstfaac.c:479
#3  0xb6020cb2 in gst_faac_configure_source_pad (info=0xbba4bea8,
faac=0x9d9eb28) at gstfaac.c:555
#4  gst_faac_set_format (enc=0x9d9eb28, info=0xbba4bea8) at gstfaac.c:395
#5  0xb54bb668 in gst_audio_encoder_sink_setcaps (enc=0x9d9eb28,
caps=0x703584f0) at gstaudioencoder.c:1282
#6  0xb54daa57 in gst_audio_encoder_chain (pad=0x9e74c38, parent=0x9d9eb28,
buffer=0x26a6c730) at gstaudioencoder.c:1055
#7  0xb694edd5 in gst_pad_chain_data_unchecked (pad=0x9e74c38, type=4112,
data=0x26a6c730) at gstpad.c:3718
#8  0xb694f75a in gst_pad_push_data (pad=0x9e74b00, type=4112, data=0x26a6c730)
at gstpad.c:3948
#9  0xb5edbe21 in gst_base_transform_chain (pad=0x9e749c8, parent=0x9824d78,
buffer=0x26a6c730) at gstbasetransform.c:2215
#10 0xb694edd5 in gst_pad_chain_data_unchecked (pad=0x9e749c8, type=4112,
data=0x26a6c730) at gstpad.c:3718
#11 0xb694f75a in gst_pad_push_data (pad=0x9e74890, type=4112, data=0x26a6c730)
at gstpad.c:3948
#12 0xb54ca81a in gst_audio_decoder_push_forward (dec=0x9df9c00,
buf=0x26a6c730) at gstaudiodecoder.c:873
#13 0xb54caa41 in gst_audio_decoder_output (dec=0x9df9c00, buf=<optimized out>)
at gstaudiodecoder.c:949
#14 0xb54d166c in gst_audio_decoder_finish_frame (dec=0x9df9c00, buf=<optimized
out>, frames=<optimized out>) at gstaudiodecoder.c:1152
#15 0xb69f58a7 in gst_mulawdec_handle_frame (dec=0x9df9c00, buffer=0x8736820)
at mulaw-decode.c:129
#16 0xb54cb621 in gst_audio_decoder_handle_frame (dec=0x9df9c00,
buffer=0x8736820, klass=<optimized out>) at gstaudiodecoder.c:1199
#17 0xb54cb9cb in gst_audio_decoder_push_buffers (dec=0x9df9c00, force=0) at
gstaudiodecoder.c:1297
#18 0xb54cbec3 in gst_audio_decoder_chain_forward (dec=0x9df9c00, buffer=0x0)
at gstaudiodecoder.c:1400
#19 0xb54cf6eb in gst_audio_decoder_chain (pad=0x9e74758, parent=0x9df9c00,
buffer=0x8736820) at gstaudiodecoder.c:1668
#20 0xb694edd5 in gst_pad_chain_data_unchecked (pad=0x9e74758, type=4112,
data=0x8736820) at gstpad.c:3718
#21 0xb694f75a in gst_pad_push_data (pad=0x9d069c0, type=4112, data=0x8736820)
at gstpad.c:3948
#22 0xb6046bc4 in gst_rtp_base_depayload_push (filter=0x26a94d40,
out_buf=0x8736820) at gstrtpbasedepayload.c:607
#23 0xb6047369 in gst_rtp_base_depayload_chain (pad=0x9d06888,
parent=0x26a94d40, in=0x9052708) at gstrtpbasedepayload.c:355
#24 0xb694edd5 in gst_pad_chain_data_unchecked (pad=0x9d06888, type=4112,
data=0x9052708) at gstpad.c:3718
#25 0xb694f75a in gst_pad_push_data (pad=0x318008, type=4112, data=0x9052708)
at gstpad.c:3948
#26 0xb693ef72 in gst_proxy_pad_chain_default (pad=0x9f45a78, parent=0x318008,
buffer=0x9052708) at gstghostpad.c:128
#27 0xb694edd5 in gst_pad_chain_data_unchecked (pad=0x9f45a78, type=4112,
data=0x9052708) at gstpad.c:3718
#28 0xb694f75a in gst_pad_push_data (pad=0x9d2f4e0, type=4112, data=0x9052708)
at gstpad.c:3948
#29 0xb60891b1 in gst_rtp_pt_demux_chain (pad=0x9fdb890, parent=0x9a64678,
buf=0x9052708) at gstrtpptdemux.c:446
#30 0xb694edd5 in gst_pad_chain_data_unchecked (pad=0x9fdb890, type=4112,
data=0x9052708) at gstpad.c:3718
#31 0xb694f75a in gst_pad_push_data (pad=0x9fdb620, type=4112, data=0x9052708)
at gstpad.c:3948
#32 0xb60815aa in gst_rtp_jitter_buffer_loop (jitterbuffer=0x9fb5020) at
gstrtpjitterbuffer.c:1949
#33 0xb6980e38 in gst_task_func (task=0x597d26e0) at gsttask.c:316
#34 0xb6982098 in default_func (tdata=0x9d8f638, pool=0x859a008) at
gsttaskpool.c:70
#35 0xb6d29047 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#36 0xb6d286b3 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#37 0xb771ed4c in start_thread (arg=0xbba4db40) at pthread_create.c:308
#38 0xb743bdde in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.