Conversation
| * their pads cannot use manual demands | ||
| * the first filter must make demands in buffers | ||
| """ | ||
| @moduledoc deprecated: "This module is deprecated, use Membrane.Bin instead" |
There was a problem hiding this comment.
[NIT] I am not sure, but I feel like it requires a little bit more of a context, something like: "if you need to aggregate children into a single component, use Membrane.Bin.
(the point is that' I am not sure if it's always a valid clue to use Membrane.Bin when one tried using the FilterAggregator)
| "This action cannot be returned by a #{element_type |> Atom.to_string() |> String.capitalize()}." | ||
| end | ||
|
|
||
| defp format_reason({:invalid_element_callback_combination, element_type, callback}) do |
There was a problem hiding this comment.
Shouldn't it be more like component_type, to make it generic for elements/bins/pipelines?
| Although Endpoints may seem similair to [Filters](`m:Membrane.Filter`), 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`) in a single element - media they consume and produce are | ||
| parts of different streams. The main consequence of this is the fact that | ||
| they separate the flow control of the pipeline ahead of them and behind them, | ||
| and in turn their input pads behave like ones of a Sink, and their output pads behave | ||
| like ones of a Source. |
There was a problem hiding this comment.
| Although Endpoints may seem similair to [Filters](`m:Membrane.Filter`), 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`) in a single element - media they consume and produce are | |
| parts of different streams. The main consequence of this is the fact that | |
| they separate the flow control of the pipeline ahead of them and behind them, | |
| and in turn their input pads behave like ones of a Sink, and their output pads behave | |
| like ones of a Source. | |
| Although Endpoints may seem similair to [Filters](`m:Membrane.Filter`), 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. 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. |
| "Invalid config keys:\n" <> invalid_keys_reasons | ||
|
|
||
| other -> | ||
| "Invalid pad config: #{other}" |
There was a problem hiding this comment.
| "Invalid pad config: #{other}" | |
| "Invalid pad config: #{inspect(other)}" |
| "Duplicate keys in pad config: #{inspect(duplicates)}" | ||
|
|
||
| {:config_field, {:key_not_found, :flow_control}} | ||
| when component != :filter and direction == :output -> |
There was a problem hiding this comment.
[JUST A THOUGHT :D] It looks as if we are repeating the conditions specified in parse_pad_spec() - perhaps Bunch.Config.parse() should accept error message as one of its arguments?
| if type == :sink do | ||
| raise ActionError, action: action, reason: {:invalid_element, type} | ||
| else |
There was a problem hiding this comment.
It looks as if there is a plenty of places where you check if type == <some element type> and then you raise {:invalid_element, type} - wouldn't it be possible to add guards checking expected types of elements in these handle_action clauses (just as it use to be) and raise invalid_element in fallback handle_action implementation?
2 participants
No description provided.