Read the *:5 log then, it almost always is in there somewhere.

To clarify. In most cases its not all fields that fail to negotiate. It would be helpful if the LOG justs says e.g.:
Could not negotiate caps: formats [RGB] <> [I420, UVYV]

marking as enhancement: need a global pipeline caps introspection and debugging tool.

Some more thoughts: The problem in e.g. basesrc is that is e.g. uses gst_base_src_default_negotiate() which only returns a boolean. So the caller gst_base_src_start() cannot give any details. Now inside gst_base_src_default_negotiate() its gst_caps_intersect() that does the work. This cannot log a warning as it doesn't know the use case (wheter no intersect found is good or not).

What about having:
gchar *gst_debug_caps_intersect_failure_reason(GstCaps *caps1,GstCaps *caps2);
so that in high level code (e.g. basesrc) one can write:

if (icaps = gst_caps_intersect (thiscaps, peercaps)) {
  /* success, go on */
}
#ifdef GST_DEBUG
else {
  gchar *reason=gst_debug_caps_intersect_failure_reason(thiscaps, peercaps);
  GST_WARNNG_OBJECT (basesrc, "no common caps: %s",reason);
  g_free(reason);
}
#endif

The implementation would
* first check both caps for EMPTY
* if not, check if they have common mediatypes
* and if they have, it needs to check for missing fields or fields with not maching ranges/values

An other concrete illustration of this problem (from gst-devel mailing list) :

* Julien Isorce wrote:

If my X11 settings are 32 bpp then an annoying thing is that running "gst-launch-0.10 videotestsrc ! "video/x-raw-rgb, bpp=16, depth=16" ! ximagesink" gives me an error from videotestsrc : 

"videotestsrc0 : Could not negotiate format"

But this is not really true, actually the fault is from ximagesink.

Because in ximagesink::gst_ximagesink_getcaps, the xcontext->caps is setup to bpp=32 and depth=24, so I think at this point ximagesink should check that this is not compatible with the required caps from my capfilter.

And so the error should be at least: "ximagesink0 : Could not negotiate format"


* Tim wrote

Well, yes. We should find a way to report errors like this better, no
doubt. Currently there's no way to communicate error state to the
upstream element that drives the pipeline and eventually errors out
though, it just knows the flow return and that's that.

Cheers
 -Tim

The capsdebug element does most of what you'd want here.

Example showing the complete negotiation between videotestsrc and xvimagesink:

  GST_DEBUG=default:3 gst-launch videotestsrc ! capsdebug ! xvimagesink

In Julien's case, first try:


  GST_DEBUG=default:3 gst-launch-0.10 videotestsrc ! capsdebug ! "video/x-raw-rgb, bpp=16, depth=16" ! ximagesink

This gives:

0:00:00.069300550   897  0x8ea2070 INFO                 default gstcapsdebug.c:235:gst_caps_debug_getcaps: downstream returned EMPTY

Try again, with capsdebug in a different spot:

  GST_DEBUG=default:3 gst-launch-0.10 videotestsrc ! "video/x-raw-rgb, bpp=16, depth=16" ! capsdebug ! ximagesink

This gives:

0:00:00.048809149   904  0x8ce1070 INFO                 default gstcapsdebug.c:230:gst_caps_debug_getcaps: downstream called getcaps
0:00:00.052694563   904  0x8ce1070 INFO                 default gstcapsdebug.c:235:gst_caps_debug_getcaps: upstream returned video/x-raw-rgb, bpp=(int)16, endianness=(int)1234, depth=(int)16, red_mask=(int)63488, green_mask=(int)2016, blue_mask=(int)31, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]
Setting pipeline to PAUSED ...
0:00:00.059975304   904  0x8ce1070 INFO                 default gstcapsdebug.c:230:gst_caps_debug_getcaps: upstream called getcaps
0:00:00.060033064   904  0x8ce1070 INFO                 default gstcapsdebug.c:235:gst_caps_debug_getcaps: downstream returned video/x-raw-rgb, bpp=(int)32, depth=(int)24, endianness=(int)4321, red_mask=(int)65280, green_mask=(int)16711680, blue_mask=(int)-16777216, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ], pixel-aspect-ratio=(fraction)1/1


capsdebug doesn't specifically tell you that these aren't compatible, but it's not too hard to figure that out.

I think we could and should do better than that. This is such a basic thing, and our error reporting in these cases is really really bad. It's one of the biggest issues for newcomers too, they just get cryptic failures from completely unrelated elements (e.g. source, when something failed ten elements down the line) and are then expected to dig through megabytes of debug spew. Not cool.

There's no reason why we can't report better which pad and error originated from, for example, or why not-negotiated was returned. I've got some ideas on how to do this better, so I'd like to keep this bug open.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/6.