[Bug 677335] New: Incompatible caps can be accepted and dataflow happens

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=677335
  GStreamer | gstreamer (core) | 0.11.x

           Summary: Incompatible caps can be accepted and dataflow happens
    Classification: Platform
           Product: GStreamer
           Version: 0.11.x
        OS/Version: Linux
            Status: NEW
          Severity: blocker
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: slomo at circular-chaos.org
         QAContact: gstreamer-bugs at lists.freedesktop.org
                CC: wim.taymans at gmail.com
     GNOME version: ---


Hi,

currently it is possible in 0.10 and 0.11 that a pad accepts caps and buffers
with these caps although the acceptcaps function and the template caps of the
pad in question don't accept it.

A simple test case for 0.10 would be
gst-launch-0.10 audiotestsrc ! vorbisenc ! vorbisdec ! autoaudiosink
with only alsasink installed (alsasink does not accept float audio, vorbisdec
only outputs float audio). The pipeline is linked in NULL state, in READY state
the alsasink is instantiated and the ghostpad target is set and up to this
point no concrete caps are known (well, autoaudiosink could check the upstream
caps before setting the ghostpad target, does it need to? Or should the
ghostpad functions check for this?). Now the complete pipeline is linked.

When the first buffer from vorbisdec arrives at autoaudiosink,
gst_pad_configure_sink() is called on the sinkpad of autoaudiosink, this checks
the template caps (ANY caps) and then calls gst_pad_set_caps() on the sinkpad.
The ghostpad setcaps function now gets the target pad (alsasink's sinkpad) and
calls gst_pad_set_caps() on it without checking anything. alsasink's setcaps
function (well, baseaudiosink) assumes that the caps are compatible to the pad
caps at this point and just continues to set everything without failing. And
soon later buffers are pushed and buffers that are incompatible with alsasink
are accepted by alsasink.


1) A possible fix would be to call gst_pad_accept_caps() in
gst_pad_configure_sink() instead of just intersecting with the template caps,
but this would possibly be a performance problem as acceptcaps usually gathers
all caps further downstream through multiple elements. (Using acceptcaps here
will work because the ghostpad acceptcaps function proxies to the target and
alsasink's acceptcaps function will simply not accept the invalid caps.)

2) Another solution would be to let gst_proxy_pad_setcaps_default() not set the
caps on the target but only on the internal pad. And let caps propagation with
buffers happen as usual internally in gst_pad_chain_data_unchecked() with
gst_pad_configure_sink(). This still has the problem that incompatible caps
could be allowed though as gst_pad_configure_sink() only does a subset check on
the *template* caps (alsasink likely has much more restricted caps in states >=
READY than the template caps).


I tested both fixes and they both work in the above mentioned testcase. But 1)
has the mentioned performance problem (while it is the correct and bulletproof
solution) and 2) does not fix the bug completely (but has no performance
problems). 1) would also fix pads accepting wrong caps in other situations.



A similar problem also exists in 0.11. gstpad.c:pre_eventfunc_check() only does
a subset check with the template caps and the template caps could be more
liberal than the caps that are actually accepted by the pad at this point. The
subset-template check is done properly for ghostpads though, so in 0.11 the
state of this bug is basically the same as if it was "fixed" by 2) in 0.10.

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