[Bug 693993] [subtitleoverlay] deadlock with mp4 file during preroll

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Sun Mar 3 12:28:19 PST 2013


https://bugzilla.gnome.org/show_bug.cgi?id=693993
  GStreamer | gst-plugins-base | 1.x

Tim-Philipp Müller <t.i.m> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |t.i.m at zen.co.uk
     Ever Confirmed|0                           |1

--- Comment #2 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2013-03-03 20:28:14 UTC ---
Pipeline to see how packets are being pushed out:

  gst-launch-1.0 souphttpsrc location=http://192.168.0.10/Escargot.mp4 !
qtdemux name=d  \
      d.subtitle_0 ! fakesink silent=false async=false name=textsink \
      d.audio_0 ! fakesink silent=false async=false name=audiosink \
      d.video_0 ! fakesink silent=false async=false name=videosink

Shows this, in push mode:

videosink:sink dts: 0:00:24.920000000, duration: 0:00:00.040000000
 textsink:sink dts: 0:00:00.000000000, duration: 0:00:25.080000000
audiosink:sink dts: 0:00:24.917333333, duration: 0:00:00.021333333

videosink:sink dts: 0:05:31.960000000, duration: 0:00:00.040000000
 textsink:sink dts: 0:00:25.080000000, duration: 0:05:07.040000000
videosink:sink dts: 0:05:32.000000000, duration: 0:00:00.040000000

but this in pull mode (with queue2 ring-buffer-max-size=500000 before qtdemux):

 textsink:sink dts: 0:00:00.000000000, duration: 0:00:25.080000000
audiosink:sink dts: 0:00:00.021333333, duration: 0:00:00.021333333
videosink:sink dts: 0:00:00.120000000, duration: 0:00:00.040000000

videosink:sink dts: 0:00:25.080000000, duration: 0:00:00.040000000
 textsink:sink dts: 0:00:25.080000000, duration: 0:05:07.040000000
audiosink:sink dts: 0:00:25.002666666, duration: 0:00:00.021333334


This might be due to the way the two text samples are packed:

   chunk offset (stco)
      total_entries 2
       offset 0 6994308 (6ab984)
       offset 1 31545768 (1e159a8) 

So it seems that in push mode the first packet of the text stream is only
pushed out after the other streams have seen already ~25 seconds worth of the
stream. That probably doesn't play too well with $something, though I would've
expected multiqueue to just ignore this stream then once the other streams are
filled up enough. Which seems to be what happens:

  gst-launch-1.0 -v souphttpsrc location=http://192.168.0.10/Escargot.mp4 !
qtdemux name=d  \
    multiqueue name=mq  \
    d.subtitle_0 ! mq.sink_0  mq.src_0 ! fakesink silent=false async=false
name=textsink   \
    d.audio_0 ! mq.sink_1 mq.src_1 ! fakesink silent=false name=audiosink   \
    d.video_0 ! mq.sink_2  mq.src_2 ! fakesink silent=false  name=videosink

so the issue must be somewhere else, maybe in subtitleoverlay as you say.

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