[Bug 704427] New: Connecting multiple text stream -> funnel -> playsink is incredibly slow

[GStreamer (bugzilla.gnome.org)]

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

           Summary: Connecting multiple text stream -> funnel -> playsink
                    is incredibly slow
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: self at brendanlong.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=249453)
 --> (https://bugzilla.gnome.org/attachment.cgi?id=249453)
Pipeline used when this problem occurs

I'm kind of guessing on the component here. I think this is a bug in either
playsink or queue.

Note: You need to be on the latest version of gst-plugins-good from git for
qtdemux to expose both streams in the file I'm using as an example.

First, notice how this pipeline runs reasonably fast when streaming:

    gst-git gst-launch-1.0 uridecodebin \
       
uri=https://github.com/WebKit/webkit/raw/master/LayoutTests/media/content/counting-subtitled.m4v
name=d ! text/x-raw ! \
        funnel name=f ! s.text_sink d. ! s.video_sink playsink name=s \
        video-sink="fakesink" 'text-sink="fakesink dump=true"' d. ! \
        text/x-raw ! f.

Now download the file and play it locally and notice how it's so slow it seems
to be locked up:

    wget
https://github.com/WebKit/webkit/raw/master/LayoutTests/media/content/counting-subtitled.m4v
    gst-git gst-launch-1.0 uridecodebin \
        uri=file://$PWD/counting-subtitled.m4v name=d ! text/x-raw ! \
        funnel name=f ! s.text_sink d. ! s.video_sink playsink name=s \
        video-sink="fakesink" 'text-sink="fakesink dump=true"' d. ! \
        text/x-raw ! f.

The output is generally something like this:

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
00000000 (0x7fdea001ddf0): 4f 6e 65                                         One 
New clock: GstSystemClock
00000000 (0x7fdea0018340): 54 77 6f                                         Two
# hang for a long time, sometimes print the next subtitle eventually

Running it in gdb, I spend a bunch of time in `gst_queue_chain`, looping on
`while (gst_queue_is_filled (queue))`.

The confusing thing is that there's no reason for the queue to be full, since
there's only one queue in the pipeline, and it's connected to a fakesink, which
presumably can pull data pretty quickly.

I also see similar problems with appsink, so I'm guessing this is some sort of
timing issue with queue, but that seems unlikely since queue is such an
important element.

This problem doesn't occur if we use the default input-selector
text-stream-combiner.

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