After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 525922 - The recording pipeline stop is so slow
The recording pipeline stop is so slow
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.17
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-04-03 09:35 UTC by Wang Diancheng
Modified: 2008-06-28 02:31 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Wang Diancheng 2008-04-03 09:35:13 UTC
Please describe the problem:
I use following pipeline to record video(I developed program base on
gstreamer python binding.):

        gst-launch v4l2src name=videosrc queue-size=2 ! 
        image/jpeg,width=640,height=480 ! tee name=vsrc vsrc. ! queue 
        ! jpegdec ! ffmpegcolorspace ! timeoverlay ! gconfvideosink 
        vsrc. ! queue !  muxer. avimux name=muxer !  filesink
        location=x.avi alsasrc name=audiosrc !
        'audio/x-raw-int,rate=8000,channels=1,width=8,signed=false' !
        queue ! muxer.

but when I stop recording, it consume so much time(more than 30 seconds
sometimes). I used following code to stop recording:
        # stop v4l2src
        videosrc = self.recorder.get_by_name("videosrc")
        videosrc.set_state(gst.STATE_NULL)
        videosrc.set_locked_state(True)
        # stop alsasrc        
        audiosrc = self.recorder.get_by_name("audiosrc")
        audiosrc.set_state(gst.STATE_NULL)
        audiosrc.set_locked_state(True)

following is the gdb backtrace when the pipeline is stopping:

  • #0 __kernel_vsyscall
  • #1 __lll_lock_wait
    from /lib/i686/cmov/libpthread.so.0
  • #2 _L_lock_95
    from /lib/i686/cmov/libpthread.so.0
  • #3 pthread_mutex_lock
    from /lib/i686/cmov/libpthread.so.0
  • #4 gst_base_src_set_playing
    at gstbasesrc.c line 2453
  • #5 gst_base_src_change_state
    at gstbasesrc.c line 2652
  • #6 gst_element_change_state
    at gstelement.c line 2410
  • #7 gst_element_set_state_func
    at gstelement.c line 2360
  • #8 gst_element_set_state
    at gstelement.c line 2263


Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Wang Diancheng 2008-06-28 02:31:59 UTC
sorry, I use a videorate element in pipeline, It is OK now. following is current pipeline, but I patched videorate make it support image/jpeg, maybe someone need it, I also attach it here.

pipeline:
        gst-launch v4l2src queue-size=2 !
        image/jpeg,width=640,height=480 ! tee name=vsrc vsrc. ! queue
        ! jpegdec ! ffmpegcolorspace ! timeoverlay ! gconfvideosink
        vsrc. ! videorate ! queue !  muxer. avimux name=muxer !  filesink
        location=x.avi alsasrc !
        'audio/x-raw-int,rate=8000,channels=1,width=8,signed=false' !
         audiorate ! queue ! muxer.

videorate patch:

--- gst-plugins-base-0.10.19/gst/videorate/gstvideorate.c       2007-08-10 18:08:05.000000000
 +0800
+++ gst-plugins-base-0.10.19.new/gst/videorate/gstvideorate.c   2008-06-12 14:06:40.000000000
 +0800
@@ -120,14 +120,14 @@
     GST_STATIC_PAD_TEMPLATE ("src",
     GST_PAD_SRC,
     GST_PAD_ALWAYS,
-    GST_STATIC_CAPS ("video/x-raw-yuv; video/x-raw-rgb")
+    GST_STATIC_CAPS ("video/x-raw-yuv; video/x-raw-rgb; image/jpeg")
     );

 static GstStaticPadTemplate gst_video_rate_sink_template =
     GST_STATIC_PAD_TEMPLATE ("sink",
     GST_PAD_SINK,
     GST_PAD_ALWAYS,
-    GST_STATIC_CAPS ("video/x-raw-yuv; video/x-raw-rgb")
+    GST_STATIC_CAPS ("video/x-raw-yuv; video/x-raw-rgb; image/jpeg")
     );

 static void gst_video_rate_swap_prev (GstVideoRate * videorate,