[gstreamer-bugs] [Bug 600648] New: [multiqueue] Queues up too much data

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Wed Nov 4 01:31:29 PST 2009


https://bugzilla.gnome.org/show_bug.cgi?id=600648
  GStreamer | gstreamer (core) | git

           Summary: [multiqueue] Queues up too much data
    Classification: Desktop
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: slomo at circular-chaos.org
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


Hi,
first of all, I'm not sure if this is really a problem with multiqueue or just
how it's used in decodebin2.

The problem is, that for some reason multiqueue queues up far too much data. In
my specific case (
http://samples.mplayerhq.hu/Matroska/subtitles/SSA_15subtitles.mkv ) I have a
Matroska file with 15 subtitle streams, one audio and one video stream. This is
all handled correctly by decodebin2 and it exposes the pads.

Unfortunately now the problems begin, the video and audio streams are pushed
downstream more or less synchronized while the subtitle streams get buffers
pushed with timestamps of ~20 seconds at the time where the video is at ~6
seconds. This sounds like a problem in the file itself but when looking at the
debug output of matroskademux or pipeline2 below it should be clear that this
is not the case.

pipeline1 to reproduce the problem:
gst-launch-0.10 -v filesrc location=SSA_15subtitles.mkv ! decodebin2
caps="application/x-ssa; video/x-raw-yuv" name=dbin  dbin. ! "video/x-raw-yuv"
! fakesink  dbin.src5 ! "application/x-ssa" ! fakesink

pipeline2 that does not have the problem:
gst-launch-0.10 -v filesrc location=SSA_15subtitles.mkv ! matroskademux
name=demux ! queue ! fakesink   demux.subtitle_05 ! queue ! "application/x-ssa"
! fakesink

The problem comes visible from looking at the chain output of fakesink's
verbose mode:
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* <
(460800 bytes, timestamp: 0:00:06.256000000, duration: 0:00:00.041708299,
offset: -1, offset_end: -1, flags: 256) 0x7f2fd817dd30"
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* <
(460800 bytes, timestamp: 0:00:06.297000000, duration: 0:00:00.041708299,
offset: -1, offset_end: -1, flags: 256) 0x7f2fd800d690"
/GstPipeline:pipeline0/GstFakeSink:fakesink1: last-message = "chain   ******* <
(   20 bytes, timestamp: 0:00:19.620000000, duration: 0:00:01.130000000,
offset: -1, offset_end: -1, flags: 0) 0x7f2fd804acb0"
/GstPipeline:pipeline0/GstFakeSink:fakesink1: last-message = "chain   ******* <
(   24 bytes, timestamp: 0:00:20.840000000, duration: 0:00:02.630000000,
offset: -1, offset_end: -1, flags: 0) 0x7f2fd804ac30"

-- 
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.




More information about the Gstreamer-bugs mailing list