Membrane Core v0.5.0 Membrane.Pad View Source
Pads are units defined by elements and bins, allowing them to be linked with their siblings. 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
For bins there are exactly the same options for both directions. Demand unit is derived from the first element inside the bin linked to the given input.
Pad options used in spec_t/0
Type describing a pad. Contains data parsed from spec_t/0
Defines possible pad directions
Possible id of dynamic pad
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 or bin.
Functions
Returns pad availability mode for given availability.
Returns the name for the given pad reference
Creates a static pad reference.
Creates a dynamic pad reference.
Link to this section Types
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 executinghandle_pad_added
andhandle_pad_removed
callbacks, respectively).
Values used when defining pad availability:
:always
- a static pad, which can remain unlinked instopped
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 bins there are exactly the same options for both directions. Demand unit is derived from the first element inside the bin linked to the given input.
common_spec_options_t()
View Sourcecommon_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
description_t()
View Sourcedescription_t() :: %{ :availability => availability_t(), :mode => mode_t(), :name => name_t(), :caps => Membrane.Caps.Matcher.caps_specs_t(), optional(:demand_unit) => Membrane.Buffer.Metric.unit_t(), :direction => direction_t(), :options => nil | Keyword.t(), :bin? => boolean() }
Type describing a pad. Contains data parsed from spec_t/0
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.
Possible id of dynamic pad
input_spec_t()
View Sourceinput_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.
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 byMembrane.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 Membrane.Source
,
Membrane.Filter
, Membrane.Sink
.
Defines the name of pad or group of dynamic pads
output_spec_t()
View Sourceoutput_spec_t() :: {name_t(), [common_spec_options_t()]}
Describes how an output pad should be declared inside an element.
ref_t()
View Sourceref_t() :: name_t() | {Membrane.Pad, name_t(), dynamic_id_t()}
Defines the term by which the pad instance is identified.
Describes how a pad should be declared in element or bin.
Link to this section Functions
availability_mode(atom)
View Sourceavailability_mode(availability_t()) :: availability_mode_t()
Returns pad availability mode for given availability.
Returns the name for the given pad reference
opposite_direction(atom)
View Sourceopposite_direction(direction_t()) :: direction_t()
Creates a static pad reference.
Creates a dynamic pad reference.