About how to use gst-debug="*CAPS*:7"

[Antonio Ospite]

On Tue, 17 Apr 2018 19:10:56 -0700 (MST)
"Erickson.LU" <ericksonlushan at gmail.com> wrote:

> Hi everyone , I thought gstreamer is so powerful, and i really like it. But i
> got some problems.
>
> I will show you 3 pipeline and its log:
> (1)gst-launch-1.0 v4l2src ! videoconvert ! "video/x-raw,format=(string)BGR, width=(int)640, height=(int)480" ! autovideosink
>

Put "videoconvert" right before the sink element, like:

  gst-launch-1.0 v4l2src ! "video/x-raw,format=(string)BGR, width=(int)640, height=(int)480" ! videoconvert ! autovideosink

Or do not specify the format explicitly and let GStreamer see if there
is any compatible format between the source and the sink.

But in general using videoconvert is more robust.

You can also use videotestsrc to split the problem space; for example,
another non-working pipeline is:

  gst-launch-1.0 videotestsrc ! "video/x-raw,format=(string)BGR, width=(int)640, height=(int)480" ! autovideosink

Which may help you to see more clearly that the problem is the sink
not supporting BGR, because you eliminated v4l2src from your problem.

The log might have confused you because it mentioned v4l2src0, but the
meaning is that the v4l2src element caps are not compatible with the
downstream elements, see
https://gstreamer.freedesktop.org/documentation/design/negotiation.html

[...]
> (2)gst-launch-1.0 v4l2src ! capsfilter caps="video/x-raw, format=BGR, width=640, height=480" ! autovideosink
[...]

Same here.

[...]
> (3)gst-launch-1.0 --gst-debug="*CAPS*:7" v4l2src ! capsfilter caps="video/x-raw, format=BGR, width=640, height=480" ! xvimagesink
[...]

Same here.

The logs show you that:

[...]
> 0:00:00.045450312  1227       0xdec890 DEBUG               GST_CAPS gstutils.c:2847:gst_pad_query_caps:<capsfilter0:src> query returned video/x-raw, format=(string)BGR, width=(int)640, height=(int)480, framerate=(fraction)[ 0/1, 2147483647/1 ]

You requested format=(string)BGR 

> 0:00:00.045503789  1227       0xdec890 DEBUG               GST_CAPS gstutils.c:2847:gst_pad_query_caps:<xvimagesink0:sink> query returned video/x-raw, framerate=(fraction)[ 0/1, 2147483647/1 ], width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ]

xvimagesink do not have a filter on format, so any format *might* be
compatible.

I guess what format is actually supported depends on the hardware or on
some lower level detail which cannot be exposed statically in CAPS
declaration. I am not sure about that.

> 0:00:00.045524399  1227       0xdec890 DEBUG               GST_CAPS gstpad.c:2215:gst_pad_link_check_compatible_unlocked:<capsfilter0:src> src caps video/x-raw, format=(string)BGR, width=(int)640, height=(int)480, framerate=(fraction)[ 0/1, 2147483647/1 ]
> 0:00:00.045546267  1227       0xdec890 DEBUG               GST_CAPS gstpad.c:2217:gst_pad_link_check_compatible_unlocked:<xvimagesink0:sink> sink caps video/x-raw, framerate=(fraction)[ 0/1, 2147483647/1 ], width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ]
> 0:00:00.045581859  1227       0xdec890 DEBUG               GST_CAPS gstpad.c:2235:gst_pad_link_check_compatible_unlocked: caps are compatible 

And in fact the first check above succeeds.

> 0:00:00.484770761  1227       0xfe3050 DEBUG               GST_CAPS gstutils.c:2893:gst_pad_peer_query_caps:<capsfilter0:src> peer query returned video/x-raw, format=(string)YUY2, width=(int)[ 1, 16384 ], height=(int)[ 1, 16384 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw, format=(string)YV12, width=(int)[ 1, 16384 ], height=(int)[ 1, 16384 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw, format=(string)I420, width=(int)[ 1, 16384 ], height=(int)[ 1, 16384 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw, format=(string)UYVY, width=(int)[ 1, 16384 ], height=(int)[ 1, 16384 ], framerate=(fraction)[ 0/1, 2147483647/1 ]

However, when asked what the downstream peer can *actually* do, BGR is
not there.

> streaming task paused, reason not-negotiated (-4)

So playback cannot be started.

The problem is that the caps of upstream elements have to be compatible
with those of *downstream* elements.

Ciao,
  Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?