Update return values in callbacks to reflect 1.0 spec#103
Merged
kidq330 merged 5 commits intomembraneframework:mainfrom Feb 2, 2026
Merged
Update return values in callbacks to reflect 1.0 spec#103kidq330 merged 5 commits intomembraneframework:mainfrom
kidq330 merged 5 commits intomembraneframework:mainfrom
Conversation
varsill
approved these changes
Jan 26, 2026
basic_pipeline/07_Redemands.md
Outdated
| In the [source elements](../glossary/glossary.md#source), there is a "side-channel", from which we can receive data. That "side-channel" can be, as in the exemplary [pipeline](../glossary/glossary.md#pipeline) we are working on, in form of a file, from which we are reading the data. In real-life scenarios it could be also, i.e. an [RTP](../glossary/glossary.md#rtp) stream received via the network. Since we have that "side-channel", there is no need to receive data via the input [pad](../glossary/glossary.md#pad) (that is why we don't have it in the source element, do we?). | ||
| The whole logic of fetching the data can be put inside the `handle_demand/5` callback - once we are asked to provide the [buffers](../glossary/glossary.md#buffer), the `handle_demand/5` callback gets called and we can provide the desired number of buffers from the "side-channel", inside the body of that callback. No processing occurs here - we get asked for the buffer and we provide the buffer, simple as that. | ||
| The redemand mechanism here lets you focus on providing a single buffer in the `handle_demand/5` body - later on, you can simply return the `:redemand` action and that action will invoke the `handle_demand/5` once again, with the updated number of buffers which are expected to be provided. Let's see it in an example - we could have such a `handle_demand/5` definition (and it wouldn't be a mistake!): | ||
| In the [source elements](../glossary/glossary.md#source), there is a "side-channel", from which we can receive data. That "side-channel" can be, as in the example [pipeline](../glossary/glossary.md#pipeline) we are working on, in the form of a file, from which we are reading the data. In real-life scenarios it could also be, i.e. an [RTP](../glossary/glossary.md#rtp) stream received via the network. Since we have that "side-channel", there is no need to receive data via the input [pad](../glossary/glossary.md#pad) (that is why we don't have it in the source element). |
Collaborator
There was a problem hiding this comment.
Suggested change
| In the [source elements](../glossary/glossary.md#source), there is a "side-channel", from which we can receive data. That "side-channel" can be, as in the example [pipeline](../glossary/glossary.md#pipeline) we are working on, in the form of a file, from which we are reading the data. In real-life scenarios it could also be, i.e. an [RTP](../glossary/glossary.md#rtp) stream received via the network. Since we have that "side-channel", there is no need to receive data via the input [pad](../glossary/glossary.md#pad) (that is why we don't have it in the source element). | |
| In the [source elements](../glossary/glossary.md#source), there is a "side-channel", from which we can receive data. That "side-channel" can be, as in the example [pipeline](../glossary/glossary.md#pipeline) we are working on, in the form of a file, from which we are reading the data. In real-life scenarios it could also be, e.g. an [RTP](../glossary/glossary.md#rtp) stream received via the network. Since we have that "side-channel", there is no need to receive data via the input [pad](../glossary/glossary.md#pad) (that is why we don't have it in the source element). |
I just spotted this one as well :D
varsill
requested changes
Jan 26, 2026
Collaborator
varsill
left a comment
varsill
left a comment
There was a problem hiding this comment.
Ups, sorry for the last comment, I haven't noticed that there are still these old API leftovers in the code :D
broadcasting/05_RTMP_Pipeline.md
Outdated
Comment on lines
+14
to
+22
| children: %{ | ||
| src: %Membrane.RTMP.SourceBin{port: 9009}, | ||
| sink: %Membrane.HTTPAdaptiveStream.SinkBin{ | ||
| manifest_module: Membrane.HTTPAdaptiveStream.HLS, | ||
| target_window_duration: 20 |> Membrane.Time.seconds(), | ||
| muxer_segment_duration: 8 |> Membrane.Time.seconds(), | ||
| storage: %Membrane.HTTPAdaptiveStream.Storages.FileStorage{directory: "output"} | ||
| } | ||
| }, |
Collaborator
There was a problem hiding this comment.
we don't use the children map anymore in the ChildrenSpec
broadcasting/05_RTMP_Pipeline.md
Outdated
Comment on lines
+45
to
+53
| links: [ | ||
| link(:src) | ||
| |> via_out(:audio) | ||
| |> via_in(Pad.ref(:input, :audio), options: [encoding: :AAC]) | ||
| |> to(:sink), | ||
| link(:src) | ||
| |> via_out(:video) | ||
| |> via_in(Pad.ref(:input, :video), options: [encoding: :H264]) | ||
| |> to(:sink) |
Collaborator
There was a problem hiding this comment.
This one is also unfortunately outdated, we don't use links list at there is no more link/1 nor to/1 functions
broadcasting/05_RTMP_Pipeline.md
Outdated
| @impl true | ||
| def handle_init(_opts) do | ||
| ... | ||
| {[spec: spec, playback: :playing], %{}} |
Collaborator
There was a problem hiding this comment.
We don't have :playback action anymore, you can just remove it as we go to :playing playback right away if it's not explicitly specified not to do so
Co-authored-by: Łukasz Kita <lukasz.kita0@gmail.com>
varsill
approved these changes
Jan 29, 2026
Collaborator
varsill
left a comment
varsill
left a comment
There was a problem hiding this comment.
I left two minor comments but generally - 🥇
broadcasting/05_RTMP_Pipeline.md
Outdated
| We refer to previously defined elements using `get_child` to also configure the `:video` pads, using `:H264` as the preferred encoding and a segment duration of 4 seconds. | ||
|
|
||
| The final thing that is done in the `handle_init/1` callback's implementation is returning the desired actions: | ||
| The final thing that is done in the `handle_init/1` callback's implementation is returning the pipeline structure through the `:spec` action: |
Collaborator
There was a problem hiding this comment.
It's handle_init/2 right now as now all the callbacks have context as their argument.
broadcasting/05_RTMP_Pipeline.md
Outdated
| manifest_module: Membrane.HTTPAdaptiveStream.HLS, | ||
| target_window_duration: 20 |> Membrane.Time.seconds(), | ||
| muxer_segment_duration: 8 |> Membrane.Time.seconds(), | ||
| target_window_duration: :infinity, |
Collaborator
There was a problem hiding this comment.
why do we want to change it?
Contributor
Author
There was a problem hiding this comment.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.