# `Membrane.Endpoint`
[🔗](https://github.com/membraneframework/membrane-core/blob/v1.3.1/lib/membrane/endpoint.ex#L1)

Module defining behaviour for endpoints - elements consuming and producing data.

Behaviours for endpoints are specified, besides this place, in modules
`Membrane.Element.Base`,
`Membrane.Element.WithOutputPads`,
and `Membrane.Element.WithInputPads`.

Endpoint can have both input and output pads. Job of usual endpoint is both, to
receive some data on input pads and consume it (write to a soundcard, send through
TCP etc.) and to produce some data (read from soundcard, download through HTTP,
etc.) and send on output pads. If the pad has the flow control set to
`:manual`, then endpoint is also responsible for receiving demands on the output
pad and requesting them on the input pad (for more details, see
`c:Membrane.Element.WithOutputPads.handle_demand/5` callback).
Endpoints, like all elements, can of course have multiple pads if needed to
provide more complex solutions.

Although Endpoints may seem similair to [Filters](`m:Membrane.Filter`) - they both have
input and output pads - there are some important differences. While Filters can
be thought as parts of a Pipeline that 
take in data, process it in some way, and then pass it along, Endpoints create 
"holes" in the pipeline. They behave more like a [Sink](`m:Membrane.Sink`) and a 
[Source](`m:Membrane.Source`) combined in a single element - media they consume
and produce are parts of different streams. 

For instance, while a typical Filter would only modify
the input stream and then forward it, a typical Endpoint would consume the input stream
(e.g. send it to some external receiver) and produce a completely separate output stream 
(e.g. receive it from some external sender).

The main consequence of this is the fact that 
they separate the flow control of the pipeline ahead of them and behind them, 
as their input pads behave like those of a Sink, and their output pads behave
like those of a Source: 
  * A Filter can have `:flow_control` set to `:auto` on its output pads, an Endpoint cannot - just like a Source.
  * A Filter cannot return `:redemand` action in `handle_demand` callback, an Endpoint can - just like a Source.

## List of available callbacks
Below there is a list of all the callbacks available in a module, that implements `Membrane.Endpoint` behaviour.
We have put it for your convenience, as some of these callbacks aren't directly defined in that module and
their specification is available in different modules.

The callbacks available in `Membrane.Endpoint` behaviour:

`Membrane.Element.Base`
* `c:Membrane.Element.Base.__struct__/0`
* `c:Membrane.Element.Base.__struct__/1`
* `c:Membrane.Element.Base.handle_event/4`
* `c:Membrane.Element.Base.handle_info/3`
* `c:Membrane.Element.Base.handle_init/2`
* `c:Membrane.Element.Base.handle_pad_added/3`
* `c:Membrane.Element.Base.handle_pad_removed/3`
* `c:Membrane.Element.Base.handle_parent_notification/3`
* `c:Membrane.Element.Base.handle_playing/2`
* `c:Membrane.Element.Base.handle_setup/2`
* `c:Membrane.Element.Base.handle_terminate_request/2`
* `c:Membrane.Element.Base.handle_tick/3`

`Membrane.Element.WithInputPads`
* `c:Membrane.Element.WithInputPads.handle_buffer/4`
* `c:Membrane.Element.WithInputPads.handle_end_of_stream/3`
* `c:Membrane.Element.WithInputPads.handle_start_of_stream/3`
* `c:Membrane.Element.WithInputPads.handle_stream_format/4`

`Membrane.Element.WithOutputPads`
* `c:Membrane.Element.WithOutputPads.handle_demand/5`

# `__using__`
*macro* 

Brings all the stuff necessary to implement a endpoint element.

Options:
  - `:bring_pad?` - if true (default) requires and aliases `Membrane.Pad`
  - `:flow_control_hints?` - if true (default) generates compile-time warnings     if the number, direction, and type of flow control of pads are likely to cause unintended     behaviours.

---

*Consult [api-reference.md](api-reference.md) for complete listing*