[Bug 722666] New: avoid decoding not-linked streams

[GStreamer (bugzilla.gnome.org)]

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

           Summary: avoid decoding not-linked streams
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: All
            Status: UNCONFIRMED
          Severity: enhancement
          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: ---


Since the 0.10 -> 1.0 move, the feature that was used to make not-linked
streams skip decoding until linked again is gone.

It was done by input-selector returning not-linked on pad-allocs and the
decoder would drop that buffer and return not-linked. Nothing has replaced this
behavior in 1.0 (yet).

This can be easily demonstrated with the following scenario:

1) Create a test clip with multiple videos:
gst-launch-1.0 videotestsrc num-buffers=500 pattern=0 ! x264enc ! qtmux name=m
! filesink location=3video.mov videotestsrc num-buffers=500 pattern=1 ! x264enc
! m. videotestsrc num-buffers=500 pattern=18 ! x264enc ! m.

2) Play the clip and look at the debug logs for the video decoders:
GST_DEBUG=*videodec*:9,*avdec*:9 gst-launch-1.0 playbin
uri=file:///path/to/3video.mov


A similar scenario is solved in dash/mss demuxers using the not-linked return
and reconfigure events to stop/reactivate those streams. The use case is a bit
different but I guess the mechanism can work the same.

Possible issues:
1) Is this a behavior break?
2) How to avoid dropping buffers that are ahead of the current play position?
It would be better if the decoder would only drop a buffer to avoid decoding
when it knew that this buffer is too late to be used.
3) How does this interfere with the buffer pools and allocation queries?

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