[gstreamer-bugs] [Bug 579912] New: [decodebin2] multiqueue is too small in time (interleave issues)

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=579912

  GStreamer | gst-plugins-base | Ver: git
           Summary: [decodebin2] multiqueue is too small in time (interleave
                    issues)
           Product: GStreamer
           Version: git
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: blocker
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: bilboed at gmail.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


Now that totem uses playbin2 (and decodebin2), an issue I never noticed has
just popped up.

In decodebin2, during preroll (filling up the stream groups) the max-size-time
of the multiqueue is 5s, allowing pretty much every heavily interleaved file to
be prerolled correctly...

... but then when that group is exposed, the max-size-time is set back to 2s
... which makes all files with an interleave greater than 2s screw up massively
(read: qos kicks in, stuttery playback with low bandwith/cpu-usage but high
interleave files/streams).

The max-size-time limit is too low for most files.

My proposal is, when exposing the gruops, to *not* modify the max-size-time
(i.e. leaving it at the 5s initial value) but still reduce the
max-size-buffer/max-size-bytes sizes.

With that modification, the 100+ files I tested which have that regression now
work fine.

I'm marking this as a blocker, otherwise we're going to have a *really* bad
experience with playbin2 (and totem now it supports it) for the next 3 months.

This doesn't prevent us from doing the *proper* fix which is for demuxers to
output GST_EVENT_BUFFER_SIZE events with their interleave parameters and
multiqueue taking them into account for its limits (i.e. ending up with the
perfect multiqueue limits).


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=579912.