"GStreamer Development" GStreamer Basic tutorial 06--Media format and pad capabilities

Goal
The pad's capabilities is the basis of a GSTREAMER element because the framework is automatically processed most of the time, so we almost don't feel it exists. This tutorial compares the principle of bias, introduces:
What is pad capabilities
How to get this thing
When should I get this thing?
Why do you need to know them?

Introduced
Pads
Pads allows information to enter or leave a element--as if it had been shown. This capabilities (or simply called caps) specifies what information can be transmitted through the pad. For example: "RGB video, size 320x200 and 30 frames per second" or "16-bit audio sampling, 5.1 channels, sample 44.1k per second" can even be a compression format similar to mp3/h264.
Pads supports multiple capabilities (for example, a video's sink can support RGB output or YUV output), capabilities can specify a range without having to be a specific value (for example, an audio sink can support sample rates from 1~48000). However, when data is flowing from one pad to another, it must be a format that both sides can support. One form of data is supported by two pads, so that the pads capabilities is fixed (with a number of clocks and no longer a data range), a process known as negotiation. The following example will explain this more clearly.
For the two element to be connected, they must have a common subset of capabilities (otherwise they certainly cannot connect to each other). This is the main purpose of the existence of capabilities.
As an application developer, we usually use the method of connecting element to build pipeline. In this example, you need to know the caps of the pad of the element you are using.
Pad templates
Pad is created by the pad template, the template will list a pad all possible capabilities. Templates are helpful for creating several similar pads, but it's also a long-established decision about whether the two element can be connected: if you don't have a common subset of two pad templates, there's no need for deeper negotiation.
Pad template checking is the first step in the negotiation process. As the process progresses, pads are formally initialized and their capability will be determined (unless the negotiation fails).

capabilities Example

[Plain] view plain copy   sink template:  ' SINK '      Availability:  always     Capabilities:       audio/x-raw-int                  signed: true                     width: 16                    depth: 16                     rate: [ 1, 2147483647 ]                 channels: [ 1, 2 ]        audio/x-raw-int                   signed: false                    width: 8                    depth: 8                     rate: [ 1, 2147483647 ]                 channels: [ 1,  2 ]         This is a permanent sink pad for element. It supports 2 media formats, all of which are audio raw (audio/x-raw-int), 16-bit symbols, and 8-bit unsigned numbers. Square brackets denote a range, for example, the range of channels (channels) is 1 to 2.

[Plain] view plain copy   src template:  ' SRC '      availability: always      Capabilities:       video/x-raw-yuv                    width: [ 1 , 2147483647 ]                   height: [ 1, 2147483647 ]                framerate: [ 0/1, 2147483647/1 ]                  format: {  i420, nv12, nv21, yv12, yuy2, y42b, y444, yuv9, yvu9, y41b,  Y800, Y8  , GREY, Y16 , UYVY, YVYU, IYU1, V308, AYUV,  a420 }          Video/x-raw-yur indicates that the source pad outputs video in YUV format. It supports a wide range of dimensions and frame rates, and a series of YUV formats (listed in curly braces). All of these formats show different image packaging and sub-sampling levels.

The final summary

You can use the Gst-inspect-0.10 tool (described later in this tutorial) to look at the caps of element.

Remember that some element looks at the underlying hardware to determine the supported format and the caps of the pad that can be provided (usually in the ready or later state). As a result, the display caps are different depending on the platform, and may not even be the same at every run (this is rare).

This tutorial creates 2 element, displays their respective pad template, connects and sets the pipeline to play status. During each state switch, the pad capabilities of the sink element is displayed, so you can see how the negotiation process is going, and how the last pad caps are fixed.

A simple pad capabilities example

[OBJC] view plain copy   #include  <gst/gst.h>       /*  Functions below print the capabilities in a human-friendly format  */   static gboolean print_field  (Gquark field, const gvalue &NBSP;*&NBSP;VALUE,&NBSP;GPOINTER&NBSP;PFX)  {     gchar *str = gst_ value_serialize  (value);          g_print  ("%s  %15s :  %s\n ",  (gchar *)  pfx, g_quark_to_string  (field),  str);      g_free  (str);     return TRUE;  }         static void print_caps  (const gstcaps * caps, const gchar * &NBSP;PFX)  {     guint i;          g_return _if_fail (caps !=