[gstreamer-bugs] [Bug 421543] [GstPad] Doesn't check if pad accepts caps after caps change

GStreamer (bugzilla.gnome.org) bugzilla-daemon at bugzilla.gnome.org
Sun Mar 25 08:42:30 PDT 2007


Do NOT reply to this via email (we are currently unable to handle email
responses and they WILL be discarded).

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=421543.
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

  GStreamer | gstreamer (core) | Ver: HEAD CVS


Sebastian Dröge changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #85253|0                           |1
        is obsolete|                            |




------- Comment #9 from Sebastian Dröge  2007-03-25 15:40 UTC -------
Created an attachment (id=85265)
 --> (http://bugzilla.gnome.org/attachment.cgi?id=85265&action=view)
caps-compatible.diff

Ok, here it is...
"test_push_negotiation_setcaps" tests the original bug:
src, sink get compatible, non-fixed caps, are linked and the sink pad gets a
setcaps function. Then the src caps are fixed  incompatible with the sink caps
and a buffer with no caps is pushed. This should _fail_ with
GST_FLOW_NOT_NEGOTIATED as the src pad caps and sink pad caps are now
incompatible and no buffer caps assumes that the buffer has the same caps as
the src pad.
Then a buffer with caps == src pad caps is pushed. This should fail for the
same reason.

"test_push_negotiation" tests another bug (IMHO):
it does exactly the same but with no setcaps function set.


All cases except "no setcaps & buffer has caps" are currently working although
they shouldn't.

Wim, are any of my assumptions wrong?




More information about the Gstreamer-bugs mailing list