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 752573 - ximagesrc+pulsesrc dropped samples
ximagesrc+pulsesrc dropped samples
Status: RESOLVED DUPLICATE of bug 710323
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.4.5
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-07-18 22:36 UTC by Francesco Frassinelli
Modified: 2015-07-21 20:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Francesco Frassinelli 2015-07-18 22:36:35 UTC
Command:
LC_ALL=C GST_DEBUG="*:3" gst-launch-1.0 \
    oggmux name=mux ! \
        queue ! \
        filesink location=meeting.ogv \
    ximagesrc ! \
        videorate ! video/x-raw,framerate=25/1 ! \
        vaapipostproc ! \
        queue ! \
        theoraenc bitrate=1000 ! \
        queue ! \
        mux. \
   pulsesrc ! \
        queue ! \
        opusenc bitrate=32768 ! \
        queue ! \
        mux.

Output:
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_38
libva info: va_openDriver() returns 0
Setting pipeline to PAUSED ...
0:00:00.038045323  4817      0x119f4a0 FIXME                default gstutils.c:3643:gst_pad_create_stream_id_internal:<pulsesrc0:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
Pipeline is live and does not need PREROLL ...
Got context from element 'vaapipostproc0': gst.vaapi.Display=context, display=(GstVaapiDisplay)NULL;
0:00:00.038243943  4817      0x1213280 FIXME                default gstutils.c:3643:gst_pad_create_stream_id_internal:<ximagesrc0:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
Setting pipeline to PLAYING ...
New clock: GstPulseSrcClock
Redistribute latency...
0:00:00.228456538  4817      0x119f680 FIXME               basesink gstbasesink.c:3064:gst_base_sink_default_event:<filesink0> stream-start event without group-id. Consider implementing group-id handling in the upstream elements
0:00:35.962090167  4817      0x119f4a0 WARN            audiobasesrc gstaudiobasesrc.c:858:gst_audio_base_src_create:<pulsesrc0> create DISCONT of 1072320 samples at sample 1723680
0:00:35.962175971  4817      0x119f4a0 WARN            audiobasesrc gstaudiobasesrc.c:863:gst_audio_base_src_create:<pulsesrc0> warning: Can't record audio fast enough
0:00:35.962193547  4817      0x119f4a0 WARN            audiobasesrc gstaudiobasesrc.c:863:gst_audio_base_src_create:<pulsesrc0> warning: Dropped 1072320 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.
WARNING: from element /GstPipeline:pipeline0/GstPulseSrc:pulsesrc0: Can't record audio fast enough
Additional debug info:
gstaudiobasesrc.c(863): gst_audio_base_src_create (): /GstPipeline:pipeline0/GstPulseSrc:pulsesrc0:
Dropped 1072320 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.
0:01:48.692676164  4817      0x119f4a0 WARN            audiobasesrc gstaudiobasesrc.c:858:gst_audio_base_src_create:<pulsesrc0> create DISCONT of 3392160 samples at sample 5214720
0:01:48.692728186  4817      0x119f4a0 WARN            audiobasesrc gstaudiobasesrc.c:863:gst_audio_base_src_create:<pulsesrc0> warning: Can't record audio fast enough
0:01:48.692744854  4817      0x119f4a0 WARN            audiobasesrc gstaudiobasesrc.c:863:gst_audio_base_src_create:<pulsesrc0> warning: Dropped 3392160 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.
WARNING: from element /GstPipeline:pipeline0/GstPulseSrc:pulsesrc0: Can't record audio fast enough
Additional debug info:
gstaudiobasesrc.c(863): gst_audio_base_src_create (): /GstPipeline:pipeline0/GstPulseSrc:pulsesrc0:
Dropped 3392160 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.
0:05:21.623086685  4817      0x119f4a0 WARN            audiobasesrc gstaudiobasesrc.c:858:gst_audio_base_src_create:<pulsesrc0> create DISCONT of 10121760 samples at sample 15435360
0:05:21.623123764  4817      0x119f4a0 WARN            audiobasesrc gstaudiobasesrc.c:863:gst_audio_base_src_create:<pulsesrc0> warning: Can't record audio fast enough
0:05:21.623134596  4817      0x119f4a0 WARN            audiobasesrc gstaudiobasesrc.c:863:gst_audio_base_src_create:<pulsesrc0> warning: Dropped 10121760 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.
WARNING: from element /GstPipeline:pipeline0/GstPulseSrc:pulsesrc0: Can't record audio fast enough
Additional debug info:
gstaudiobasesrc.c(863): gst_audio_base_src_create (): /GstPipeline:pipeline0/GstPulseSrc:pulsesrc0:
Dropped 10121760 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:05:49.563093587
Setting pipeline to PAUSED ...
0:05:49.604279721  4817 0x7fe160002f20 WARN                audiosrc gstaudiosrc.c:244:audioringbuffer_thread_func:<pulsesrc0> error reading data -1 (reason: Success), skipping segment
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

System information:
$ cat /etc/system-release
Fedora release 22 (Twenty Two)
$ rpm -q gstreamer1
gstreamer1-1.4.5-1.fc22.x86_64

Additional information:
1. If use shout2send instead of filesink, gst-launch closes itself after a while
2. It doesn't happen every time
3. It doesn't seem to be related with CPU or bandwith usage
4. I can reproduce it using very different bitrates and framerates
Comment 1 Tim-Philipp Müller 2015-07-19 17:57:28 UTC
Not clear to me that this is a bug in GStreamer (other than ximagesrc performance being poor perfhaps).

Have you tried making the audio queue after pulsesrc unlimited, e.g. queue max-size-bytes=0 max-size-buffers=0 max-size-time=0 ?
Comment 2 Francesco Frassinelli 2015-07-20 06:53:51 UTC
(In reply to Tim-Philipp Müller from comment #1)
> Not clear to me that this is a bug in GStreamer (other than ximagesrc
> performance being poor perfhaps).

I decided to report this bug after many tests because none of my cpu cores goes to 90~100 %, so I though that it could be something not related with performances (it happens even if I reduce the framerate).

> Have you tried making the audio queue after pulsesrc unlimited, e.g. queue
> max-size-bytes=0 max-size-buffers=0 max-size-time=0 ?

Yes, and the error disappears. Many video frames are still dropped:
$ LC_ALL=C GST_DEBUG="*:3" gst-launch-1.0 filesrc location=meeting.ogv ! decodebin ! autovideosink
Setting pipeline to PAUSED ...
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_38
libva info: va_openDriver() returns 0
0:00:00.026917898  3004      0x2603760 WARN                 basesrc gstbasesrc.c:3470:gst_base_src_start_complete:<filesrc0> pad not activated yet
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:05.311774556  3004 0x7f8774002d40 WARN               theoradec gsttheoradec.c:737:theora_handle_data_packet:<theoradec0> dropping frame because of QoS
0:00:05.311948733  3004 0x7f8774002d40 WARN            videodecoder gstvideodecoder.c:2503:gst_video_decoder_prepare_finish_frame:<theoradec0> decreasing timestamp (0:00:02.640000000 < 0:00:05.160000000)
0:00:05.531908640  3004 0x7f8774002d40 WARN               theoradec gsttheoradec.c:737:theora_handle_data_packet:<theoradec0> dropping frame because of QoS
0:00:05.531942533  3004 0x7f8774002d40 WARN            videodecoder gstvideodecoder.c:2503:gst_video_decoder_prepare_finish_frame:<theoradec0> decreasing timestamp (0:00:02.920000000 < 0:00:05.400000000)
0:00:06.047547359  3004 0x7f8774002d40 WARN               theoradec gsttheoradec.c:737:theora_handle_data_packet:<theoradec0> dropping frame because of QoS
0:00:06.047607410  3004 0x7f8774002d40 WARN            videodecoder gstvideodecoder.c:2503:gst_video_decoder_prepare_finish_frame:<theoradec0> decreasing timestamp (0:00:03.480000000 < 0:00:05.920000000)
0:00:06.447494394  3004 0x7f8774002d40 WARN               theoradec gsttheoradec.c:737:theora_handle_data_packet:<theoradec0> dropping frame because of QoS
Comment 3 Francesco Frassinelli 2015-07-21 20:08:06 UTC
use-damage=false seems to fix the problem.

*** This bug has been marked as a duplicate of bug 710323 ***