# Pads

As we have seen in , the pads are the element's interface to the outside world.

The specific type of media that the element can handle will be exposed by the pads. The description of this media type is done with capabilities(see )

Pads are either source or sink pads. The terminology is defined from the view of the element itself: elements accept data on their sink pads, and send data out on their source pads. Sink pads are drawn on the left, while source pads are drawn on the right of an element. In general, data flows from left to right in the graph. In reality, there is no objection to data flowing from a source pad to the sink pad of an element upstream. Data will, however, always flow from a source pad of one element to the sink pad of another.

## Types of pads

### Dynamic pads

Some elements might not have all of their pads when the element is created. This can happen, for example, with an MPEG system demultiplexer. The demultiplexer will create its pads at runtime when it detects the different elementary streams in the MPEG system stream.

Running gst-inspect mpegdemux will show that the element has only one pad: a sink pad called 'sink'. The other pads are "dormant". You can see this in the pad template because there is an 'Exists: Sometimes' property. Depending on the type of MPEG file you play, the pads will be created. We will see that this is very important when you are going to create dynamic pipelines later on in this manual.

### Request pads

An element can also have request pads. These pads are not created automatically but are only created on demand. This is very useful for multiplexers, aggregators and tee elements.

The tee element, for example, has one input pad and a request padtemplate for the output pads. Whenever an element wants to get an output pad from the tee element, it has to request the pad.

## Capabilities of a pad

Since the pads play a very important role in how the element is viewed by the outside world, a mechanism is implemented to describe the data that can flow through the pad by using capabilities.

We will briefly describe what capabilities are, enough for you to get a basic understanding of the concepts. You will find more information on how to create capabilities in the Plugin Writer's Guide.

### Capabilities

Capabilities are attached to a pad in order to describe what type of media the pad can handle.

Capabilities is shorthand for "capability chain". A capability chain is a chain of one capability or more.

The basic entity is a capability, and is defined by a name, a MIME type and a set of properties. A capability can be chained to another capability, which is why we commonly refer to a chain of capability entities as "capabilities". It is important to understand that the term "capabilities" refers to a chain of one capability or more. This will be clearer when you see the structure definition of a `GstCaps` element.

Below is a dump of the capabilities of the element mad, as shown by `gst-inspect`. You can see two pads: sink and src. Both pads have capability information attached to them.

The sink pad (input pad) is called 'sink' and takes data of MIME type 'audio/mp3'. It also has three properties: layer, bitrate and framed.

The source pad (output pad) is called 'src' and outputs data of MIME type 'audio/raw'. It also has four properties: format, depth, rate and channels.

    Pads:
      SINK template: 'sink'
        Availability: Always
        Capabilities:
          'mad_sink':
            MIME type: 'audio/mp3':

      SRC template: 'src'
        Availability: Always
        Capabilities:
          'mad_src':
            MIME type: 'audio/raw':
            format: String: int
            endianness: Integer: 1234
            width: Integer: 16
            depth: Integer: 16
            channels: Integer range: 1 - 2
            law: Integer: 0
            signed: Boolean: TRUE
            rate: Integer range: 11025 - 48000

### What are properties ?

Properties are used to describe extra information for capabilities. A property consists of a key (a string) and a value. There are different possible value types that can be used:

- basic types:

  - an integer value: the property has this exact value.

  - a boolean value: the property is either TRUE or FALSE.

  - a fourcc value: this is a value that is commonly used to describe an encoding for video, as used for example by the AVI specification. fourcc values consist of four bytes. The FOURCC Definition List is the most complete resource on the allowed fourcc values.

  - a float value: the property has this exact floating point value.

  - a string value.

- range types:

  - an integer range value: the property denotes a range of possible integer. For example, the wavparse element has a source pad where the "rate" property can go from 8000 to 48000.

  - a float range value: the property denotes a range of possible floating point values.

- a list value: the property can take any value from a list of basic value types or range types.

### What capabilities are used for

Capabilities describe in great detail the type of media that is handled by the pads. They are mostly used for:

- Autoplugging: automatically finding plugins for a set of capabilities

- Compatibility detection: when two pads are linked, GStreamer can verify if the two pads are talking about the same media types. The process of linking two pads and checking if they are compatible is called "caps negotiation".