Membrane Core v0.3.0 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 availability mode of a created pad

Values used when defining pad availability

Pad options used in spec_t/0

Type describing a pad. Contains data parsed from spec_t/0

Defines possible pad directions

Describes how an input pad should be declared inside an element

Describes how an element sends and receives data. Modes are strictly related to pad directions

Defines the name of pad or group of dynamic pads

Describes how an output pad should be declared inside an element

Defines the term by which the pad instance is identified

Describes how a pad should be declared in element

Functions

Returns pad availability mode for given availability

Returns pad availability mode based on pad reference

Returns the name for the given pad reference

Link to this section Types

Link to this type

availability_mode_t() View Source
availability_mode_t() :: :static | :dynamic

Type describing availability mode of a created pad:

  • :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

Values used when defining pad availability:

  • :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.
Link to this type

common_spec_options_t() View Source
common_spec_options_t() ::
  {:availability, availability_t()}
  | {:mode, mode_t()}
  | {:caps, Membrane.Caps.Matcher.caps_specs_t()}
  | {:options, Keyword.t()}

Pad options used in spec_t/0

Link to this type

description_t() View Source
description_t() :: %{
  :availability => availability_t(),
  :mode => mode_t(),
  :caps => Membrane.Caps.Matcher.caps_specs_t(),
  optional(:demand_unit) => Membrane.Buffer.Metric.unit_t(),
  :direction => direction_t(),
  :options => nil | Keyword.t()
}

Type describing a pad. Contains data parsed from spec_t/0

Link to this type

direction_t() View Source
direction_t() :: :output | :input

Defines possible pad directions:

  • :output - data can only be sent through such pad,
  • :input - data can only be received through such pad.

One cannot link two pads with the same direction.

Link to this type

input_spec_t() View Source
input_spec_t() ::
  {name_t(),
   [common_spec_options_t() | {:demand_unit, Membrane.Buffer.Metric.unit_t()}]}

Describes how an input pad should be declared inside an element.

Link to this type

mode_t() View Source
mode_t() :: :push | :pull

Describes how an element sends and receives data. Modes are strictly related to pad directions:

  • :push output pad - element can send data through such pad whenever it wants.
  • :push input 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 output 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.Core.InputBuffer.
  • :pull input 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 output pad working in push mode, and input in pull mode. Moreover, toilet mode of Membrane.Core.InputBuffer has to be enabled then.

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

Defines the name of pad or group of dynamic pads

Link to this type

output_spec_t() View Source
output_spec_t() :: {name_t(), [common_spec_options_t()]}

Describes how an output pad should be declared inside an element.

Link to this type

ref_t() View Source
ref_t() :: atom() | {:dynamic, atom(), non_neg_integer()}

Defines the term by which the pad instance is identified.

Describes how a pad should be declared in element.

Link to this section Functions

Link to this function

availability_mode(atom) View Source
availability_mode(availability_t()) :: availability_mode_t()

Returns pad availability mode for given availability.

Link to this function

availability_mode_by_ref(ref) View Source
availability_mode_by_ref(ref_t()) :: availability_mode_t()

Returns pad availability mode based on pad reference.

Link to this macro

is_availability(term) View Source (macro)

Link to this macro

is_availability_dynamic(availability) View Source (macro)

Link to this macro

is_availability_static(availability) View Source (macro)

Link to this macro

is_pad_name(term) View Source (macro)

Link to this macro

is_pad_ref(term) View Source (macro)

Returns the name for the given pad reference