consistent sytnax highliting

Author: Pawel Bala

basic_pipeline/01_Introduction.md

@@ -35,7 +35,7 @@ Below you can see an exemplary frame sent by one peer to the other. It gets frag
 
 Here is how each packet looks like:
 
-```Elixir
+```elixir
 [seq:<sequence_id>][frameid:<frame_id>][timestamp:<timestamp>]<text>
 ```
 

basic_pipeline/03_Source.md

@@ -20,7 +20,7 @@ Let's start with specifying that our module will implement the `Membrane.Source`
 
 **_`lib/elements/Source.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.Source do
  use Membrane.Source
  alias Membrane.Buffer
@@ -35,7 +35,7 @@ Later on, we will make use of [macros](https://elixir-lang.org/getting-started/m
 
 **_`lib/elements/Source.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.Source do
  ...
  def_options location: [type: :string, description: "Path to the file"]
@@ -47,7 +47,7 @@ end
 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).
 Later on, while instantiating the Source element, we will be able to write:
 
-```Elixir
+```elixir
 %Basic.Elements.Source{location: "input.A.txt"}
 ```
 
@@ -63,7 +63,7 @@ Let's define our first callback! Why not start with [`handle_init/1`](https://he
 
 **_`lib/elements/Source.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.Source do
  ...
  @impl true
@@ -94,7 +94,7 @@ The callbacks we are about to implement will be called once the transition betwe
 
 **_`lib/elements/Source.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.Source do
  ...
  @impl true
@@ -126,7 +126,7 @@ Once the succeeding element requests for the data, the `handle_demand/4` callbac
 
 **_`lib/elements/Source.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.Source do
  ...
 

basic_pipeline/04_Caps.md

@@ -27,7 +27,7 @@ Here is how you define a caps specification:
 
 1. First you need to specify the format module
 
-```Elixir
+```elixir
 defmodule Formats.Raw do
   defstruct [:pixel_format, :framerate, :width, :height]
 end
@@ -42,7 +42,7 @@ Module name defines the type of the caps, however it is possible to pass some ot
 
 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:
 
-```Elixir
+```elixir
 def_input_pad(:input,
   demand_unit: :buffers,
   caps: [
@@ -81,7 +81,7 @@ Imagine a pipeline, which starts with the source producing a video, which is the
 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.
 Here is the definition of the source element:
 
-```Elixir
+```elixir
 # Source element
 
 defmodule Source do
@@ -105,7 +105,7 @@ In fact, they will. The format matches (both in the caps being sent and in the c
 It means that the caps can be sent through the `:output` pad.
 Below there is the draft of the filter implementation:
 
-```Elixir
+```elixir
 # Filter
 
 defmodule Filter do

basic_pipeline/05_Formats.md

@@ -6,7 +6,7 @@ We will put them in a separate directory - `lib/formats`. Let's start with the f
 
 **_`lib/formats/PacketFormat.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Formats.Packet do
  @moduledoc """
  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
 
 **_`lib/formats/FrameFormat.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Formats.Frame do
  @moduledoc """
  A module describing the format of the frame.

basic_pipeline/06_OrderingBuffer.md

@@ -6,7 +6,7 @@ Because Ordering Buffer is a filtering element, we need to specify both the inpu
 
 **_`lib/elements/OrderingBuffer.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.OrderingBuffer do
   use Membrane.Filter
   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
 
 **_`lib/elements/OrderingBuffer.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.OrderingBuffer do
   ...
   @impl true
@@ -46,7 +46,7 @@ Handling demand is quite straightforward:
 
 **_`lib/elements/OrderingBuffer.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.OrderingBuffer do
  ...
  @impl true
@@ -64,7 +64,7 @@ The purpose of this callback is to process the incoming buffer. It gets called o
 
 **_`lib/elements/OrderingBuffer.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.OrderingBuffer do
   ...
   @impl true
@@ -96,7 +96,7 @@ Do you remember what our packet looks like?
 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.
 Therefore we have defined the regex description as:
 
-```Elixir
+```elixir
 ~r/^\[seq\:(?<seq_id>\d+)\](?<data>.*)$/
 ```
 
@@ -114,7 +114,7 @@ Therefore we have defined the regex description as:
 
 The result of `Regex.named_captures/2` applied to that regex description and the exemplary packet should be following:
 
-```Elixir
+```elixir
 {"seq_id"=>7, "data"=>"[frameid:2][timestamp:3]data"}
 ```
 
@@ -125,7 +125,7 @@ Here comes the rest of the `handle_process/4` definition:
 
 **_`lib/elements/OrderingBuffer.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.OrderingBuffer do
   ...
   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
 
 **_`lib/elements/OrderingBuffer.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.OrderingBuffer do
   ...
   defp get_ready_packets_sequence([], acc) do

basic_pipeline/07_Redemands.md

@@ -14,7 +14,7 @@ In the [source elements](../glossary/glossary.md#source), there is a "side-chann
 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!):
 
-```Elixir
+```elixir
 @impl true
 def handle_demand(:output, size, _unit, _context, state) do
  actions = for x <- 1..size do
@@ -30,7 +30,7 @@ You would need to take under the consideration all these situations and your cod
 
 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:
 
-```Elixir
+```elixir
 @impl true
 def handle_demand(:output, _size, unit, context, state) do
  payload = Input.get_next() #Input.get_next() is an exemplary function which could be providing data

basic_pipeline/08_Depayloader.md

@@ -7,7 +7,7 @@ Let's create a new module in the `lib/elements/Depayloader.ex` file:
 
 **_`lib/elements/Depayloader.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.Depayloader do
  use Membrane.Filter
 
@@ -20,7 +20,7 @@ What input data do we expect? Of course in `Basic.Format.Packet` format!
 
 **_`lib/elements/Depayloader.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.Depayloader do
  def_input_pad(:input, demand_unit: :buffers, caps: {Packet, type: :custom_packets})
  ...
@@ -32,7 +32,7 @@ We need to specify it while defining the `:output` pad:
 
 **_`lib/elements/Depayloader.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.Depayloader do
  ...
  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
 
 **_`lib/elements/Depayloader.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.Depayloader do
  ...
  def_options(
@@ -63,7 +63,7 @@ In the `handle_init/1` callback we are simply saving the value of that parameter
 
 **_`lib/elements/Depayloader.ex`_**
 
-```Elixir
+```elixir
 @impl true
 def handle_init(options) do
 {:ok,
@@ -80,7 +80,7 @@ As noted in the [chapter dedicated to the caps](04_Caps.md), since we are changi
 
 **_`lib/elements/Depayloader.ex`_**
 
-```Elixir
+```elixir
 @impl true
 def handle_caps(_pad, _caps, _context, state) do
  caps = %Frame{encoding: :utf8}
@@ -92,7 +92,7 @@ As in most elements, the `handle_demand/5` implementation is quite easy - what w
 
 **_`lib/elements/Depayloader.ex`_**
 
-```Elixir
+```elixir
 @impl true
 def handle_demand(_ref, size, _unit, _ctx, state) do
  { {: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
 
 **_`lib/elements/Depayloader.ex`_**
 
-```Elixir
+```elixir
 @impl true
 def handle_process(_ref, buffer, _ctx, state) do
  packet = buffer.payload
@@ -124,7 +124,7 @@ Once we fetch the interesting values of the header's parameters, we can update t
 
 **_`lib/elements/Depayloader.ex`_**
 
-```Elixir
+```elixir
 @impl true
 def handle_process(_ref, buffer, _ctx, state) do
  ...
@@ -147,7 +147,7 @@ If we have the 'ending' packet, we are making the `:buffer` action with the fram
 
 **_`lib/elements/Depayloader.ex`_**
 
-```Elixir
+```elixir
 defp prepare_frame(frame) do
    frame |> Enum.reverse() |> Enum.join("")
 end

basic_pipeline/09_Mixer.md

@@ -5,7 +5,7 @@ Once again we start with defining the initialization options and the pads of bot
 
 **_`lib/elements/Mixer.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.Mixer do
  @moduledoc """
  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/
 
 **_`lib/elements/Mixer.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.Mixer do
  ...
  defmodule Track do
@@ -55,7 +55,7 @@ The next step in our element implementation is quite an obvious one:
 
 **_`lib/elements/Mixer.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.Mixer do
  ...
  @impl true
@@ -75,7 +75,7 @@ Following on the callbacks implementation, let's continue with `handle_process/4
 
 **_`lib/elements/Mixer.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.Mixer do
  ...
  @impl true
@@ -96,7 +96,7 @@ What we do is that we are simply putting the incoming `buffer` into the `Track`
 
 **_`lib/elements/Mixer.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.Mixer do
  ...
  @impl true
@@ -118,7 +118,7 @@ There is nothing left to do apart from defining the `handle_demand/5` itself!
 
 **_`lib/elements/Mixer.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.Mixer do
   ...
   @impl true
@@ -144,7 +144,7 @@ Each of these steps has a corresponding private function.
 
 **_`lib/elements/Mixer.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.Mixer do
  ...
  defp get_output_buffers_actions(state) do
@@ -186,7 +186,7 @@ Now let's focus on preparing `:end_of_stream` action:
 
 **_`lib/elements/Mixer.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.Mixer do
  ...
  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
 
 **_`lib/elements/Mixer.ex`_**
 
-```Elixir
+```elixir
 defmodule Basic.Elements.Mixer do
  ...
  defp get_demand_actions(state, pads) do