-
Notifications
You must be signed in to change notification settings - Fork 15
Update return values in callbacks to reflect 1.0 spec #103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
varsill
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🥇
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). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
| 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"} | ||
| } | ||
| }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we don't use the children map anymore in the ChildrenSpec
broadcasting/05_RTMP_Pipeline.md
Outdated
| 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) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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], %{}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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>
No description provided.