[gstreamer-bugs] [Bug 619522] New: basetransform fix for upstream caps-renegotiation

[GStreamer (bugzilla.gnome.org)]

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

           Summary: basetransform fix for upstream caps-renegotiation
    Classification: Desktop
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: rob at ti.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


If initially pass-through caps are negotiated between a transform element's
sink and src pads, but then the downstream element returns different caps
on a buffer from pad_alloc(), basetransform gets stuck with proxy_alloc=TRUE
even though the upstream peer doesn't accept the caps, causing
gst_pad_peer_accept_caps() to be called on each buffer in _buffer_alloc():

    if (!gst_caps_is_equal (newcaps, caps)) {
      GST_DEBUG_OBJECT (trans, "caps are new");
      /* we have new caps, see if we can proxy downstream */
>>    if (gst_pad_peer_accept_caps (pad, newcaps)) {
        /* peer accepts the caps, return a buffer in this format */
        GST_DEBUG_OBJECT (trans, "peer accepted new caps");

which is taking ~40ms/frame.

This patch does two things.  (1) if the buffer returned from pad_alloc() has
new caps, trigger the decision whether to proxy the buffer-alloc to be
revisited, and (2) disable proxy if peer does not accept new caps.  (The first
part may not be strictly needed, but seemed like a good idea.)

Note that this issue would not arise except in case of downstream elements
who have on their template-caps, some that would be suitable for pass-through,
but at runtime pick more restrictive caps (for ex, after querying a driver for
what formats it actually supports).

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