@type accepted_format_t() :: module() | (pattern :: term())

Describes pattern, that should be matched by stream format send by element on specific pad. Will not be evaluated during runtime, but used for matching struct passed in :stream_format action. Can be a module name, pattern describing struct, or call to any_of function, which arguments are such patterns or modules names. If a module name is passed to the :accepted_format option or is passed to any_of, it will be converted to the match on a struct defined in that module, eg. accepted_format: My.Format will have this same effect, as accepted_format: %My.Format{} and accepted_format: any_of(My.Format, %My.Another.Format{field: value} when value in [:some, :enumeration]) will have this same effect, as accepted_format: any_of(%My.Format{}, %My.Another.Format{field: value} when value in [:some, :enumeration])

@type 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).

@type availability_t() :: :always | :on_request

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.

@type bin_spec_t() :: {name_t(), [common_spec_options_t()]}

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.

@type common_spec_options_t() ::
  {:availability, availability_t()}
  | {:accepted_format, accepted_format_t()}
  | {:mode, mode_t()}
  | {:options, Keyword.t()}

Pad options used in spec_t/0

@type demand_mode_t() :: :manual | :auto

Defines the mode of handling and requesting demand on pads.

• :manual - demand is manually handled and requested. See Membrane.Element.Action.demand_t, Membrane.Element.Action.redemand_t, Membrane.Element.WithOutputPads.handle_demand/5
• :auto - demand is managed automatically: the core ensures that there's demand on each input pad (that has demand_mode set to :auto) whenever there's demand on all output pads (that have demand_mode set to :auto). Currently works only for Membrane.Filters.

@type description_t() :: %{
  :availability => availability_t(),
  :mode => mode_t(),
  :name => name_t(),
  :accepted_formats_str => [String.t()],
  optional(:demand_unit) => Membrane.Buffer.Metric.unit_t(),
  :direction => direction_t(),
  :options => nil | Keyword.t(),
  optional(:demand_mode) => demand_mode_t()
}

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

@type 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.

@type dynamic_id_t() :: any()

Possible id of dynamic pad

@type input_spec_t() ::
  {name_t(),
   [
     common_spec_options_t()
     | {:demand_mode, demand_mode_t()}
     | {:demand_unit, Membrane.Buffer.Metric.unit_t()}
   ]}

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

@type 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.
• :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. In such case, however, error will be raised whenever too many buffers accumulate on the input pad, waiting to be processed.

For more information on transfering data and demands, see demand_mode_t/0, Membrane.Source, Membrane.Filter, Membrane.Endpoint, Membrane.Sink.

@type name_t() :: atom()

Defines the name of pad or group of dynamic pads

@type output_spec_t() ::
  {name_t(), [common_spec_options_t() | {:demand_mode, demand_mode_t()}]}

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

@type ref_t() :: name_t() | {Membrane.Pad, name_t(), dynamic_id_t()}

Defines the term by which the pad instance is identified.

@type spec_t() :: output_spec_t() | input_spec_t() | bin_spec_t()

Describes how a pad should be declared in element or bin.