[Bug 684237] videomixer: Caps negotiation does not always work

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #3 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2012-09-18 10:28:52 UTC ---
I believe the remaining problem is as explained as follows.

A few relevant caps when it works:
/GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc1.GstPad:src: caps =
video/x-raw, format=(string)AYUV, width=(int)320, height=(int)240,
framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/GstVideoMixer2:mix.GstPad:src: caps = video/x-raw,
format=(string)AYUV, width=(int)320, height=(int)240,
pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive,
colorimetry=(string)bt601, framerate=(fraction)30/1
/GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0.GstPad:src: caps =
video/x-raw, format=(string)AYUV, width=(int)320, height=(int)240,
pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive,
colorimetry=(string)bt601, framerate=(fraction)30/1

Note that one videotestsrc started out with 'minimal' caps fields, then mixer
src pad added some fields (as created by standard videoinfo), and these got
propagated back to the other videotestsrc producing 'full' caps.

What happens in failing run:
videotestsrc1 tries to set 'minimal' caps and these fail to make it through:
0:00:00.107385029 11113      0x2375cf0 DEBUG               GST_CAPS
../../gstreamer/gst/gstpad.c:4696:pre_eventfunc_check:<
alpha0:sink> caps video/x-raw, format=(string)AYUV, width=(int)320,
height=(int)240, framerate=(fraction)30/1, pixel-aspect
-ratio=(fraction)1/1 not accepted

And afaics this fails because the above caps are not considered a subset (as
checked by the default accept_caps) of the following get_caps returned by alpha
(in turn originating from the 'full' caps from videomixer src pad):
video/x-raw, format=(string)AYUV, width=(int)[ 1, 2147483647 ], height=(int)[
1, 2147483647 ], pixel-aspect-ratio=(fraction)1/1,
interlace-mode=(string)progressive, colorimetry=(string)bt601,
framerate=(fraction)[ 0/1
, 2147483647/1 ]; video/x-raw, width=(int)[ 1, 2147483647 ], height=(int)[ 1,
2147483647 ], pixel-aspect-ratio=(fraction)1/1,
interlace-mode=(string)progressive, framerate=(fraction)[ 0/1, 2147483647/1 ],
format=(string){ AYUV, ARGB, BGRA, ABGR, RGBA, Y444, xRGB, BGRx, xBGR, RGBx,
RGB, BGR, Y42B, YUY2, YVYU, UYVY, I420, YV12, Y41B }

In summary, it seems to come down to caps not considered a subset of caps with
some more fields.  So, maybe videomixer has to strip the returned get_caps some
more.  Btw, any ideas why videomixer has a separate accept_caps that seems to
do what the default one does anyway ?

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