[Bug 742924] New: decodebin: Initial decoder negotiation will always fail

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=742924
  GStreamer | gst-plugins-base | git

           Summary: decodebin: Initial decoder negotiation will always
                    fail
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: bilboed at bilboed.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Introduced mostly by these commits:

commit 994680b04eb390a116a9b5bda2abd647df233be3
Author: Sebastian Dröge <sebastian at centricular.com>
Date:   Thu Jul 10 12:50:17 2014 +0200

    decodebin: Only link elements further after setting them to PAUSED

    They might fail to go to PAUSED, and when connecting them further
    we might already expose their srcpads on decodebin if we're unlucky.
    This prevents us to handle failures going to PAUSED gracefully.

commit 57999c28fd7720f5f3e9b3adf55528ddad21cc9c
Author: Sebastian Dröge <sebastian at centricular.com>
Date:   Thu Jul 10 12:51:22 2014 +0200

    decodebin: Send sticky events to the new element after setting it to PAUSED

    ... and if this fails for whatever reason we skip the element and instead
    try with the next element. This allows us to handle elements that fail
    when setting caps on them by just skipping to the next alternative element.


The problem is essentially that we can no longer do (proper/optimal/any)
initial negotiation in decoders.

Current status: When decoders are created, they are added to the bin, but not
linked, and we check that it can accept pending sticky events (i.e. CAPS). Only
after that will it be properly linked downstream.


It results in these issues.

1) When decoders receive CAPS_EVENT, they might need to query caps downstream
(which should eventually reach the actual sinks via the autoplug-query
decodebin2/playbin mechanism) to know
 1.1) *if* they can produce something compatible with downstream. This will not
be possible since the CAPS_QUERY will just return the source pad template (the
pad is not linked).
  ==> The commits were intended to avoid using elements that won't work later
on. This is impossible since they are not linked and the autoplug-query system
can't be used.

 1.2) and to figure out what downstream prefers (potentially including special
features (special memory, buffer type, ...))
  ==> This won't be possible (not linked), so they will always fallback to the
default behavior.
  ==> The decoder might even pick CAPS that are *not* compatible with
downstream.

  ==> QUERY_CAPS will never work before the element receives data (i.e. it's
been linked and the sinkpad stream lock has been released).
  ==> The CAPS selected might not be compatible with downstream, let alone the
optimal choice/features.

2) For decoders that need to configure themselves appropriately before they
consume any buffers (i.e. when receiving a CAPS event), they are no longer
guaranteed to be linked downstream after setting CAPS downstream (since they
are not linked). This was the case before these patches.
  Sending a NEGOTIATION query downstream will always fail (not linked)

  ==> QUERY_NEGOTIATION will never work before the elements 


While the intent of those commits is perfectly valid, we end up in a situation
where the only decoders that will be able to do optimal negotiations with sinks
are the ones that can reconfigure themselves after having consumed data. I
don't even think we have any of those ...

Maybe we should link the elements normally (like for parsers/converters/...)
BUT with the sinkpad stream lock taken, send the sticky events, and unroll the
chain if it fails ? At least elements will have a way of properly negotiating
like this.

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