[gstreamer-bugs] [Bug 621332] New: BaseTransform should disable proxy alloc if downstream changes caps

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri Jun 11 15:45:29 PDT 2010


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

           Summary: BaseTransform should disable proxy alloc if downstream
                    changes caps
    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: tester at tester.ca
         QAContact: gstreamer-bugs at lists.sourceforge.net
                CC: youness.alaoui at collabora.co.uk
      GNOME target: ---
     GNOME version: ---


If I have a pipeline like  src ! caps1 ! transform ! caps1 ! sink and I replace
caps1 by a different caps2. Then basetransform keeps on trying to do pad alloc
and a gst_pad_accept_caps() for each buffer. This can be very slow (and is
useless). 

I quickly tried to hack GstBaseTransform to make it work by doing
priv->proxy_alloc = FALSE if the gst_pad_accept_caps() fails, but it doesn't
re-start proxying when the downstream caps change.

Anyway, this caps/suggest/alloc/etc crap in BaseTransform is a disaster.


Minimal example program:
import gst, time, sys

p = gst.parse_launch("audiotestsrc is-live=1 ! audio/x-raw-int, rate=8000 !
audioresample ! capsfilter name=c ! fakesink");
c = p.get_by_name("c")
p.set_state(gst.STATE_PLAYING)
time.sleep(2)
# After this is it start doing too many caps nego after each alloc call
c.set_property("caps", gst.caps_from_string("audio/x-raw-int, rate=16000"))
time.sleep(2) 
# After this, it should get back to proxying pad alloc
c.set_property("caps", gst.caps_from_string("ANY"))
time.sleep(2)
p.set_state(gst.STATE_NULL)

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




More information about the Gstreamer-bugs mailing list