Skip to content

Commit f9ca403

Browse files
Pawel BalaPawel Bala
Pawel Bala
authored and
Pawel Bala
committed
consistent sytnax highliting
1 parent c77b338 commit f9ca403

16 files changed

+74
-74
lines changed

Diff for: basic_pipeline/01_Introduction.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -35,7 +35,7 @@ Below you can see an exemplary frame sent by one peer to the other. It gets frag
3535

3636
Here is how each packet looks like:
3737

38-
```Elixir
38+
```elixir
3939
[seq:<sequence_id>][frameid:<frame_id>][timestamp:<timestamp>]<text>
4040
```
4141

Diff for: basic_pipeline/03_Source.md

+6-6
Original file line numberDiff line numberDiff line change
@@ -20,7 +20,7 @@ Let's start with specifying that our module will implement the `Membrane.Source`
2020

2121
**_`lib/elements/Source.ex`_**
2222

23-
```Elixir
23+
```elixir
2424
defmodule Basic.Elements.Source do
2525
use Membrane.Source
2626
alias Membrane.Buffer
@@ -35,7 +35,7 @@ Later on, we will make use of [macros](https://elixir-lang.org/getting-started/m
3535

3636
**_`lib/elements/Source.ex`_**
3737

38-
```Elixir
38+
```elixir
3939
defmodule Basic.Elements.Source do
4040
...
4141
def_options location: [type: :string, description: "Path to the file"]
@@ -47,7 +47,7 @@ end
4747
The first macro, `def_options` allows us to define the parameters which are expected to be passed while instantiating the element. The parameters will be passed as an automatically generated structure `%Basic.Elements.Source{}`. In our case, we will have a `:location` field inside of that structure. This parameter is about to be a path to the files which will contain input [packets](../glossary/glossary.md#packet).
4848
Later on, while instantiating the Source element, we will be able to write:
4949

50-
```Elixir
50+
```elixir
5151
%Basic.Elements.Source{location: "input.A.txt"}
5252
```
5353

@@ -63,7 +63,7 @@ Let's define our first callback! Why not start with [`handle_init/1`](https://he
6363

6464
**_`lib/elements/Source.ex`_**
6565

66-
```Elixir
66+
```elixir
6767
defmodule Basic.Elements.Source do
6868
...
6969
@impl true
@@ -94,7 +94,7 @@ The callbacks we are about to implement will be called once the transition betwe
9494

9595
**_`lib/elements/Source.ex`_**
9696

97-
```Elixir
97+
```elixir
9898
defmodule Basic.Elements.Source do
9999
...
100100
@impl true
@@ -126,7 +126,7 @@ Once the succeeding element requests for the data, the `handle_demand/4` callbac
126126

127127
**_`lib/elements/Source.ex`_**
128128

129-
```Elixir
129+
```elixir
130130
defmodule Basic.Elements.Source do
131131
...
132132

Diff for: basic_pipeline/04_Caps.md

+4-4
Original file line numberDiff line numberDiff line change
@@ -27,7 +27,7 @@ Here is how you define a caps specification:
2727

2828
1. First you need to specify the format module
2929

30-
```Elixir
30+
```elixir
3131
defmodule Formats.Raw do
3232
defstruct [:pixel_format, :framerate, :width, :height]
3333
end
@@ -42,7 +42,7 @@ Module name defines the type of the caps, however it is possible to pass some ot
4242

4343
2. We specify the pad of the element with the format we have just defined, using the `:caps` option. For the purpose of an example, let it be the `:input` pad:
4444

45-
```Elixir
45+
```elixir
4646
def_input_pad(:input,
4747
demand_unit: :buffers,
4848
caps: [
@@ -81,7 +81,7 @@ Imagine a pipeline, which starts with the source producing a video, which is the
8181
For the source element, we should have the `:output` pads caps which would allow us to send video in the higher and in the lower quality. The same caps should be specified on the input of the filter element. However, the caps on the output of the filter should accept only video in the lower quality.
8282
Here is the definition of the source element:
8383

84-
```Elixir
84+
```elixir
8585
# Source element
8686

8787
defmodule Source do
@@ -105,7 +105,7 @@ In fact, they will. The format matches (both in the caps being sent and in the c
105105
It means that the caps can be sent through the `:output` pad.
106106
Below there is the draft of the filter implementation:
107107

108-
```Elixir
108+
```elixir
109109
# Filter
110110

111111
defmodule Filter do

Diff for: basic_pipeline/05_Formats.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ We will put them in a separate directory - `lib/formats`. Let's start with the f
66

77
**_`lib/formats/PacketFormat.ex`_**
88

9-
```Elixir
9+
```elixir
1010
defmodule Basic.Formats.Packet do
1111
@moduledoc """
1212
A module describing the format of the packet.
@@ -21,7 +21,7 @@ In our [pipeline](../glossary/glossary.md#pipeline) we will also send another ty
2121

2222
**_`lib/formats/FrameFormat.ex`_**
2323

24-
```Elixir
24+
```elixir
2525
defmodule Basic.Formats.Frame do
2626
@moduledoc """
2727
A module describing the format of the frame.

Diff for: basic_pipeline/06_OrderingBuffer.md

+8-8
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ Because Ordering Buffer is a filtering element, we need to specify both the inpu
66

77
**_`lib/elements/OrderingBuffer.ex`_**
88

9-
```Elixir
9+
```elixir
1010
defmodule Basic.Elements.OrderingBuffer do
1111
use Membrane.Filter
1212
alias Basic.Formats.Packet
@@ -23,7 +23,7 @@ In the next step let's specify how we want the state of our element to look like
2323

2424
**_`lib/elements/OrderingBuffer.ex`_**
2525

26-
```Elixir
26+
```elixir
2727
defmodule Basic.Elements.OrderingBuffer do
2828
...
2929
@impl true
@@ -46,7 +46,7 @@ Handling demand is quite straightforward:
4646

4747
**_`lib/elements/OrderingBuffer.ex`_**
4848

49-
```Elixir
49+
```elixir
5050
defmodule Basic.Elements.OrderingBuffer do
5151
...
5252
@impl true
@@ -64,7 +64,7 @@ The purpose of this callback is to process the incoming buffer. It gets called o
6464

6565
**_`lib/elements/OrderingBuffer.ex`_**
6666

67-
```Elixir
67+
```elixir
6868
defmodule Basic.Elements.OrderingBuffer do
6969
...
7070
@impl true
@@ -96,7 +96,7 @@ Do you remember what our packet looks like?
9696
Above you can see an exemplary packet. We need to fetch the value of the sequence id (in our case it is equal to 7) and get the rest of the packet.
9797
Therefore we have defined the regex description as:
9898

99-
```Elixir
99+
```elixir
100100
~r/^\[seq\:(?<seq_id>\d+)\](?<data>.*)$/
101101
```
102102

@@ -114,7 +114,7 @@ Therefore we have defined the regex description as:
114114
115115
The result of `Regex.named_captures/2` applied to that regex description and the exemplary packet should be following:
116116

117-
```Elixir
117+
```elixir
118118
{"seq_id"=>7, "data"=>"[frameid:2][timestamp:3]data"}
119119
```
120120

@@ -125,7 +125,7 @@ Here comes the rest of the `handle_process/4` definition:
125125

126126
**_`lib/elements/OrderingBuffer.ex`_**
127127

128-
```Elixir
128+
```elixir
129129
defmodule Basic.Elements.OrderingBuffer do
130130
...
131131
def handle_process(:input, buffer, _context, state) do
@@ -155,7 +155,7 @@ However, in the first situation, we need to get the ready packet's sequence - th
155155

156156
**_`lib/elements/OrderingBuffer.ex`_**
157157

158-
```Elixir
158+
```elixir
159159
defmodule Basic.Elements.OrderingBuffer do
160160
...
161161
defp get_ready_packets_sequence([], acc) do

Diff for: basic_pipeline/07_Redemands.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,7 @@ In the [source elements](../glossary/glossary.md#source), there is a "side-chann
1414
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.
1515
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!):
1616

17-
```Elixir
17+
```elixir
1818
@impl true
1919
def handle_demand(:output, size, _unit, _context, state) do
2020
actions = for x <- 1..size do
@@ -30,7 +30,7 @@ You would need to take under the consideration all these situations and your cod
3030

3131
Wouldn't it be better to focus on a single buffer in each `handle_demand/5` call - and let the Membrane Framework automatically update the demand's size? This can be done in the following way:
3232

33-
```Elixir
33+
```elixir
3434
@impl true
3535
def handle_demand(:output, _size, unit, context, state) do
3636
payload = Input.get_next() #Input.get_next() is an exemplary function which could be providing data

Diff for: basic_pipeline/08_Depayloader.md

+10-10
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ Let's create a new module in the `lib/elements/Depayloader.ex` file:
77

88
**_`lib/elements/Depayloader.ex`_**
99

10-
```Elixir
10+
```elixir
1111
defmodule Basic.Elements.Depayloader do
1212
use Membrane.Filter
1313

@@ -20,7 +20,7 @@ What input data do we expect? Of course in `Basic.Format.Packet` format!
2020

2121
**_`lib/elements/Depayloader.ex`_**
2222

23-
```Elixir
23+
```elixir
2424
defmodule Basic.Elements.Depayloader do
2525
def_input_pad(:input, demand_unit: :buffers, caps: {Packet, type: :custom_packets})
2626
...
@@ -32,7 +32,7 @@ We need to specify it while defining the `:output` pad:
3232

3333
**_`lib/elements/Depayloader.ex`_**
3434

35-
```Elixir
35+
```elixir
3636
defmodule Basic.Elements.Depayloader do
3737
...
3838
def_output_pad(:output, caps: {Frame, encoding: :utf8})
@@ -44,7 +44,7 @@ We will also need a parameter describing how many packets should we request once
4444

4545
**_`lib/elements/Depayloader.ex`_**
4646

47-
```Elixir
47+
```elixir
4848
defmodule Basic.Elements.Depayloader do
4949
...
5050
def_options(
@@ -63,7 +63,7 @@ In the `handle_init/1` callback we are simply saving the value of that parameter
6363

6464
**_`lib/elements/Depayloader.ex`_**
6565

66-
```Elixir
66+
```elixir
6767
@impl true
6868
def handle_init(options) do
6969
{:ok,
@@ -80,7 +80,7 @@ As noted in the [chapter dedicated to the caps](04_Caps.md), since we are changi
8080

8181
**_`lib/elements/Depayloader.ex`_**
8282

83-
```Elixir
83+
```elixir
8484
@impl true
8585
def handle_caps(_pad, _caps, _context, state) do
8686
caps = %Frame{encoding: :utf8}
@@ -92,7 +92,7 @@ As in most elements, the `handle_demand/5` implementation is quite easy - what w
9292

9393
**_`lib/elements/Depayloader.ex`_**
9494

95-
```Elixir
95+
```elixir
9696
@impl true
9797
def handle_demand(_ref, size, _unit, _ctx, state) do
9898
{ {:ok, demand: {Pad.ref(:input), size * state.packets_per_frame} }, state}
@@ -103,7 +103,7 @@ There is nothing left apart from processing the input data - that is - the packe
103103

104104
**_`lib/elements/Depayloader.ex`_**
105105

106-
```Elixir
106+
```elixir
107107
@impl true
108108
def handle_process(_ref, buffer, _ctx, state) do
109109
packet = buffer.payload
@@ -124,7 +124,7 @@ Once we fetch the interesting values of the header's parameters, we can update t
124124

125125
**_`lib/elements/Depayloader.ex`_**
126126

127-
```Elixir
127+
```elixir
128128
@impl true
129129
def handle_process(_ref, buffer, _ctx, state) do
130130
...
@@ -147,7 +147,7 @@ If we have the 'ending' packet, we are making the `:buffer` action with the fram
147147

148148
**_`lib/elements/Depayloader.ex`_**
149149

150-
```Elixir
150+
```elixir
151151
defp prepare_frame(frame) do
152152
frame |> Enum.reverse() |> Enum.join("")
153153
end

Diff for: basic_pipeline/09_Mixer.md

+9-9
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ Once again we start with defining the initialization options and the pads of bot
55

66
**_`lib/elements/Mixer.ex`_**
77

8-
```Elixir
8+
```elixir
99
defmodule Basic.Elements.Mixer do
1010
@moduledoc """
1111
The element responsible for mixing the frames coming from two sources, based on their timestamps.
@@ -27,7 +27,7 @@ Each of these input pads will have a corresponding incoming [track](../glossary/
2727

2828
**_`lib/elements/Mixer.ex`_**
2929

30-
```Elixir
30+
```elixir
3131
defmodule Basic.Elements.Mixer do
3232
...
3333
defmodule Track do
@@ -55,7 +55,7 @@ The next step in our element implementation is quite an obvious one:
5555

5656
**_`lib/elements/Mixer.ex`_**
5757

58-
```Elixir
58+
```elixir
5959
defmodule Basic.Elements.Mixer do
6060
...
6161
@impl true
@@ -75,7 +75,7 @@ Following on the callbacks implementation, let's continue with `handle_process/4
7575

7676
**_`lib/elements/Mixer.ex`_**
7777

78-
```Elixir
78+
```elixir
7979
defmodule Basic.Elements.Mixer do
8080
...
8181
@impl true
@@ -96,7 +96,7 @@ What we do is that we are simply putting the incoming `buffer` into the `Track`
9696

9797
**_`lib/elements/Mixer.ex`_**
9898

99-
```Elixir
99+
```elixir
100100
defmodule Basic.Elements.Mixer do
101101
...
102102
@impl true
@@ -118,7 +118,7 @@ There is nothing left to do apart from defining the `handle_demand/5` itself!
118118

119119
**_`lib/elements/Mixer.ex`_**
120120

121-
```Elixir
121+
```elixir
122122
defmodule Basic.Elements.Mixer do
123123
...
124124
@impl true
@@ -144,7 +144,7 @@ Each of these steps has a corresponding private function.
144144

145145
**_`lib/elements/Mixer.ex`_**
146146

147-
```Elixir
147+
```elixir
148148
defmodule Basic.Elements.Mixer do
149149
...
150150
defp get_output_buffers_actions(state) do
@@ -186,7 +186,7 @@ Now let's focus on preparing `:end_of_stream` action:
186186

187187
**_`lib/elements/Mixer.ex`_**
188188

189-
```Elixir
189+
```elixir
190190
defmodule Basic.Elements.Mixer do
191191
...
192192
defp maybe_send_end_of_stream(state) do
@@ -206,7 +206,7 @@ This action needs to be sent if both the tracks are in the `:finished` state - s
206206

207207
**_`lib/elements/Mixer.ex`_**
208208

209-
```Elixir
209+
```elixir
210210
defmodule Basic.Elements.Mixer do
211211
...
212212
defp get_demand_actions(state, pads) do

0 commit comments

Comments
 (0)