Membrane Core v0.1.1 Membrane.Element.Pad View Source

Pads are units defined by each element, allowing it to be linked with another elements. This module consists of pads typespecs and utils.

Each pad is described by its name, direction, availability, mode and possible caps. For pads to be linkable, these properties have to be compatible. For more information on each of them, check appropriate type in this module.

Each link can only consist of exactly two pads.

Link to this section Summary

Types

Type describing pad availability modes:

  • :static - there always exist exactly one instance of such pad.
  • :dynamic - multiple instances of such pad may be created and removed (which entails executing handle_pad_added and handle_pad_removed callbacks, respectively)

Defines possible pad availabilities:

  • :always - a static pad, which can remain unlinked in stopped state only.
  • :on_request - a dynamic pad, instance of which is created every time it is linked to another pad. Thus linking the pad with k other pads, creates k instances of the pad, and links each with another pad. For information on static/dynamic pad modes, see availability_mode_t/0

Type defining possible caps that can be set on the pad. To link two pads, they need to have some common caps

Defines possible pad directions:

  • :source - data can only be sent through such pad,
  • :sink - data can only be received through such pad

Type describing possible pad modes. They are strictly related to pad directions:

  • :push source pad - element can send data through such pad whenever it wants.
  • :push sink pad - element has to deal with data whenever it comes through such pad, and do it fast enough not to let data accumulate on such pad, what may lead to overflow of element process erlang queue, which is highly unwanted.
  • :pull source pad - element can send data through such pad only if it have already received demand on the pad. Sending small, limited amount of undemanded data is supported and handled by Membrane.PullBuffer.
  • :pull sink pad - element receives through such pad only data that it has previously demanded, so that no undemanded data can arrive

Defines the term by which the pad is identified

Functions

Determines whether pad availability requires exactly one instance of a pad (static) or allows multiple ones (dynamic)

Link to this section Types

Link to this type availability_mode_t() View Source
availability_mode_t() :: :static | :dynamic

Type describing pad availability modes:

  • :static - there always exist exactly one instance of such pad.
  • :dynamic - multiple instances of such pad may be created and removed (which entails executing handle_pad_added and handle_pad_removed callbacks, respectively).
Link to this type availability_t() View Source
availability_t() :: :on_request | :always

Defines possible pad availabilities:

  • :always - a static pad, which can remain unlinked in stopped state only.
  • :on_request - a dynamic pad, instance of which is created every time it is linked to another pad. Thus linking the pad with k other pads, creates k instances of the pad, and links each with another pad. For information on static/dynamic pad modes, see availability_mode_t/0.
Link to this type caps_t() View Source
caps_t() :: Membrane.Element.Caps.Matcher.caps_spec_t()

Type defining possible caps that can be set on the pad. To link two pads, they need to have some common caps.

Link to this type direction_t() View Source
direction_t() :: :source | :sink

Defines possible pad directions:

  • :source - data can only be sent through such pad,
  • :sink - data can only be received through such pad.

One cannot link two pads with the same direction.

Link to this type mode_t() View Source
mode_t() :: :push | :pull

Type describing possible pad modes. They are strictly related to pad directions:

  • :push source pad - element can send data through such pad whenever it wants.
  • :push sink pad - element has to deal with data whenever it comes through such pad, and do it fast enough not to let data accumulate on such pad, what may lead to overflow of element process erlang queue, which is highly unwanted.
  • :pull source pad - element can send data through such pad only if it have already received demand on the pad. Sending small, limited amount of undemanded data is supported and handled by Membrane.PullBuffer.
  • :pull sink pad - element receives through such pad only data that it has previously demanded, so that no undemanded data can arrive.

Linking pads with different modes is possible, but only in case of source pad working in push mode, and sink in pull mode. Moreover, toilet mode of Membrane.PullBuffer has to be enabled then.

For more information on transfering data and demands, see docs for element callbacks in Membrane.Element.Base.*.

Link to this type name_t() View Source
name_t() :: atom() | {:dynamic, atom(), non_neg_integer()}

Defines the term by which the pad is identified.

Link to this section Functions

Link to this function availability_mode(atom) View Source
availability_mode(availability_t()) :: availability_mode_t()

Determines whether pad availability requires exactly one instance of a pad (static) or allows multiple ones (dynamic).

Link to this macro is_availability(term) View Source (macro)
Link to this macro is_pad_name(term) View Source (macro)