Pads are used to negotiate links and data flow
between elements in GStreamer. A pad can be viewed as a
"plug" or "port" on an element where
links may be made with other elements, and through which data can
flow to or from those elements. Pads have specific data handling
capabilities: A pad can restrict the type of data that flows
through it. Links are only allowed between two pads when the
allowed data types of the two pads are compatible. Data types are
negotiated between pads using a process called caps
negotiation. Data types are described as a
GstCaps.

An analogy may be helpful here. A pad is similar to a plug or jack on a
physical device. Consider, for example, a home theater system consisting
of an amplifier, a DVD player, and a (silent) video projector. Linking
the DVD player to the amplifier is allowed because both devices have audio
jacks, and linking the projector to the DVD player is allowed because
both devices have compatible video jacks. Links between the
projector and the amplifier may not be made because the projector and
amplifier have different types of jacks. Pads in GStreamer serve the
same purpose as the jacks in the home theater system.

For the most part, all data in GStreamer flows one way through a link
between elements. Data flows out of one element through one or more
source pads, and elements accept incoming data
through one or more sink pads. Source and sink
elements have only source and sink pads, respectively. Data usually
means buffers (described by the GstBuffer
object) and events (described by the
GstEvent object).