Rename tutorials. Add h1 headers with the title of the tutorial

Author: varsill

create_new_plugin/create_new_plugin.md

@@ -1,10 +1,10 @@
-# Creating your own plugin
+# Create your own plugin
 
 During the development of Membrane Framework we aim at designing fewer, but higher quality plugins. However, we also kept extendability and reusability in mind. That's why it is easy for developers like you to create their own custom plugin, which satisfies their needs.
 
 In this short guide we provide you with an overview of how to create your own Membrane plugin and how to integrate it into your project.
 
-# Membrane plugin template
+## Membrane plugin template
 
 To create a new plugin, we recommend using the [template](https://github.com/membraneframework/membrane_template_plugin) that has been made for this very purpose and which will be the base of your plugin.
 It defines necessary dependencies as well as other project specs, e.g. formatting, and guarantees you compliance with other Membrane components.

get_started/simple_pipeline.md renamed to get_started_with_membrane/get_started_with_membrane.md

@@ -95,7 +95,7 @@ end
 
 The pipeline is one of the basic concepts of Membrane. It's a schema of how the data packets are flowing through our application.
 
-#### Pipeline behaviour
+### Pipeline behaviour
 
 Let's start with declaring that we'll be using the `Membrane.Pipeline` behaviour:
 
@@ -127,7 +127,7 @@ Since we want to spawn children processes and link them, we will use the [`spec_
 
 >If the concept of callbacks and behaviours is new to you, you should probably take some time to read about OTP in Elixir (especially the part starring GenServer and Supervisor). You can find the proper guide [here](https://elixir-lang.org/getting-started/mix-otp/agent.html)
 
-## Elements
+### Elements
 
 The elements we'd like to use to play our mp3 will be:
 
@@ -157,7 +157,7 @@ children = %{
 
 The keys in the `children` keyword list (`file`, `decoder`, `converter`, `portaudio`) are just convenient names we gave our elements to refer to them later. We're going to need them for linking.
 
-## Linking elements
+### Linking elements
 
 Now we should link them in the proper order. Each Membrane Element can be one of three types: Source, Sink or Filter. The main difference is that Source provides only output pads, Sink only input and Filter both input and output pads. That means only a Source element start pipelines (it's not prepared to receive any data from other elements), Sink can only end pipelines (it will not send any data to subsequent elements), and Filters can be in the middle (they receive, process and send data further). In our case the links declaration will look like this: 
 
@@ -172,7 +172,7 @@ links = [
 
 The file Source reads bytes from our mp3 file and sends them to decoder. Decoder, after decoding, sends them to converter. Converter, after conversion sends them to our portaudio sink, which receives them and plays music through Portaudio 🎶
 
-## Parent Spec
+### Parent Spec
 
 Last but not least we need group our elements and links together into a proper structure:
 

glossary/glossary.md

@@ -1,8 +1,9 @@
-# Multimedia 
+# Glossary
+## Multimedia 
 + <a name="packet"></a> **Packet** is a formatted unit of data transmitted over network. In order to send data over network it has to be fragmented into packets, which size is limited by [MTU(Maximum Transfer Unit)](https://en.wikipedia.org/wiki/Maximum_transmission_unit) - 1500 bytes when using [Ethernet](https://en.wikipedia.org/wiki/Ethernet_frame).
 + <a name="frame"></a> **Frame** can refer to either [network frame](https://en.wikipedia.org/wiki/Frame_(networking)) or **media frame**, which is a basic data unit used by media coding formats. In particular one media frame can represent a single image in a video.
 + <a name="media_track"></a> (media)**Track** is equivalent to a single audio or video stream.
-+ ## Web protocols:
++ ### Web protocols:
   + <a name="udp"></a> **UDP**(User Datagram Protocol) is a [transport layer](https://en.wikipedia.org/wiki/OSI_model#Layer_4:_Transport_layer) protocol using connectionless communication. See [here](https://www.imperva.com/learn/ddos/udp-user-datagram-protocol) for more details.
   + <a name="tcp"></a> **TCP**(Transmission Control Protocol) is a [transport layer](https://en.wikipedia.org/wiki/OSI_model#Layer_4:_Transport_layer) protocol using connection-oriented communication. See [this explanation](https://www.khanacademy.org/computing/computers-and-internet/xcae6f4a7ff015e7d:the-internet/xcae6f4a7ff015e7d:transporting-packets/a/transmission-control-protocol--tcp) on how TCP works.
   + <a name="rtp"></a> **RTP**(Real-time Transport Protocol) is an [application layer](https://en.wikipedia.org/wiki/OSI_model#Layer_7:_Application_layer) protocol for delivering real-time audio and video over IP networks. RTP packet structure is described [here](https://en.wikipedia.org/wiki/Real-time_Transport_Protocol#Packet_header). There is an extension of RTP - [SRTP](https://developer.mozilla.org/en-US/docs/Glossary/RTP) (Secure RTP), which adds security features and is used by [WebRTC](#webrtc).
@@ -25,13 +26,13 @@
 + <a name="decryption"></a> **Decryption** is a process of retrieving data from an encrypted message.
 + <a name="muxing"></a> **Muxing**(abbr. from multiplexing) is a method of combining multiple streams into a single container, e.g. muxing video and audio into an MP4 container.
 + <a name="demuxing"></a> **Demuxing**(abbr. from demultiplexing) is a method of separating streams from one combined container, e.g. retrieving audio and video from MP4.
-+ ## Server's architecture 
++ ### Server's architecture 
 ([here](https://millo-l.github.io/WebRTC-implementation-method-Mesh-SFU-MCU/) is a short article to get you started)
   + <a name="sfu"></a> **SFU**([Selective Forwarding Unit](https://millo-l.github.io/WebRTC-implementation-method-Mesh-SFU-MCU/#22-sfuselective-forwarding-unit-server)) is a video conferencing architecture that consists of a single server, which receives incoming streams from all participants and forwards each participant's stream to all other conference participants.
   + <a name="mcu"></a> **MCU**([Multipoint Control Unit](https://millo-l.github.io/WebRTC-implementation-method-Mesh-SFU-MCU/#23-mcumulti-point-control-unit-server)) is an architecture consisting of a single server, which receives incoming streams from all participants, mixes the streams, and sends them to each of the participants.
   + <a name="p2p"></a> **P2P**([Peer to Peer](https://millo-l.github.io/WebRTC-implementation-method-Mesh-SFU-MCU/#21-signaling-serverp2pmesh)) is an architecture in which each participant is directly connected to all other participants, which eliminates the need for MCU or SFU.
 
-# Membrane Framework 
+## Membrane Framework 
 + <a name="pad"></a> **Pad** is an input or output of an [elements](#element) or a [bin](#bin). Output pads of one element are connected to input pads of another element or bin.
 + <a name="caps"></a> **Caps**(abbr. from capabilities) define [pads](#pad) specification, allowing us to determine whether two elements are compatible with each other. 
 + <a name="pipeline"></a> **Pipeline** is a chain of linked [elements](#element) or [bins](#bin) which together accomplish some media processing task.
@@ -41,18 +42,18 @@
   + <a name="source"></a> **Source** is an element with only output pads, the first element of each pipeline. It is responsible for fetching the data and transmitting it through the output pad.
   + <a name="filter"></a> **Filter** is an element with both input and output pads, which is responsible for transforming data.
   + <a name="sink"></a> **Sink** is an element with only input [pads](#pads), the last element of a pipeline. It might be responsible, i.e. for writing the output to the file or playing the incoming media stream.
-+ ## Types of elements:
++ ### Types of elements:
   + <a name="payloader"></a> **Payloader** and *Depayloader* are responsible for respectively dividing frames into [packets](#packet) and assembling packets back into frames.
   + <a name="encoder"></a> **Encoder** and *Decoder* are responsible for [encoding](#encoding) and [decoding](#decoding).
   + <a name="encryptor"></a> **Encryptor** and *Decryptor* are responsible for [encryption](#encryption) and [decryption](#decryption).
   + <a name="muxer"></a> **Muxer** and *Demuxer* are responsible for [muxing](#muxing) and [demuxing](#demuxing).
   + <a name="mixer"></a> **Mixer** is responsible for mixing multiple media streams into a single stream. Unlike multiplexing, mixing is an irreversible operation.
   + <a name="jitter_buffer"></a> **Jitter buffer** / **Ordering buffer** is an element responsible for ordering packets incoming from the network as their order can be disrupted during transmission due to network unreliability.
-+ ## *Demands mechanism*
++ ### *Demands mechanism*
   + <a name="redemands"></a> **Redemands** in Membrane is an element's action that lets the programmer handle just one buffer at a time. When redemanding, the `handle_demand/5` callback is synchronously called.
 
-# *General Elixir/Erlang concepts* 
-+ ## OTP Behavior
+## *General Elixir/Erlang concepts* 
++ ### OTP Behavior
   + <a name="gen_server"></a> [**GenServer**](https://elixir-lang.org/getting-started/mix-otp/genserver.html) abstracts client/server interaction.
 + <a name="phoenix"></a> [**Phoenix**](https://phoenixframework.org/) is a web development framework written in Elixir.
 + <a name="elixir_mix"></a> [**Mix**](https://elixir-lang.org/getting-started/mix-otp/introduction-to-mix.html) is a build tool for creating and managing Elixir projects.