[Bug 719575] New: multiqueue: improve for adaptive scenario

[GStreamer (bugzilla.gnome.org)]

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

           Summary: multiqueue: improve for adaptive scenario
    Classification: Platform
           Product: GStreamer
           Version: unspecified
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: thiago.sousa.santos at collabora.co.uk
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


On adaptive scenario, there can be different multiqueues on the same
pipeline, and those can have a single input/output.

In those scenarios the multiqueue shouldn't have actions relying on having
multiple internal single queues.

For buffering, the multiqueue should post a 100% buffering message
whenever a single queue gets a NOT_LINKED return, just like it does
for EOS, so the pipeline can be unblocked if it is waiting for
buffering to finish.

During stream switching with input selector, the multiqueue will get
a reconfigure event and should awake the single queue for that stream.
Currently it waits for a NOT_LINKED return from the stream that was
deactivated. This can never happen in adaptive as there might be only
one stream on that multiqueue.

For reference, an example of a adaptive pipeline for a stream with
2 audios (different languages) can be:

<httpsrc> ! mssdemux name=d d. ! multiqueue name=m ! qtdemux ! multiqueue ! \
  <decoder> ! ... ! input-selector name=is ! ... ! sink \
  d. ! m. ! qtdemux ! multiqueue ! <decoder> ! ... ! is.

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