You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The scope of this tutorial covers the process of creating your own video room with the use of the Membrane framework.
13
12
# Introduction
13
+
The scope of this tutorial covers the process of creating your own video room with the use of the Membrane framework.
14
+
15
+
## What are we doing here?
14
16
It hasn't been that long ago when video rooms have become quite a common tool used in many fields of our life. We use them when we want to have an impression of meeting our beloved ones in the manner as they were sitting just next to us. We use them at work, to synchronize our work progress and exchange information between us and our colleagues.
15
17
Taking advantage of recent technological improvements and state-of-the-art tools introduced in the field of data transmission, video streaming
16
18
has become accessible to everyone at the scale not known previously.
I don't think I can describe it any better: [How to install Elixir](https://elixir-lang.org/install.html).
14
-
But do not forget to add the elixir bin to your PATH variable!
13
+
I don't think I can describe it any better: [How to install Elixir](https://elixir-lang.org/install.html).
14
+
But do not forget to add the elixir bin to your PATH variable!
15
15
16
-
Take your time and make yourself comfortable with Elixir. Check if you can run Elixir's interactive terminal and if you can compile Elixir's source files with the Elixir compiler.
17
-
You can also try to create a new Mix project - we will be using [Mix](https://elixir-lang.org/getting-started/mix-otp/introduction-to-mix.html) as the build automation tool all along with the tutorial.
16
+
Take your time and make yourself comfortable with Elixir. Check if you can run Elixir's interactive terminal and if you can compile Elixir's source files with the Elixir compiler.
17
+
You can also try to create a new Mix project - we will be using [Mix](https://elixir-lang.org/getting-started/mix-otp/introduction-to-mix.html) as the build automation tool all along with the tutorial.
18
18
19
19
## Template downloading
20
20
Once we have the development environment set up properly (let's hope so!) we can start to work on our project. We don't want you to do it from scratch as the development requires some dull playing around with UI, setting the dependencies, etc. - we want to provide you only the meat! That is why we would like you to download the template project with core parts of the code missing. You can do it by typing:
@@ -32,24 +32,24 @@ git checkout template/start
32
32
33
33
In case you find yourself lost along with the tutorial, feel free to check the suggested implementation provided by us, which is available on the `template/end` branch of this repository.
34
34
35
-
#Install native dependencies
35
+
## Native dependencies installing
36
36
First, some native dependencies are needed. Here is how you can install them and setup the required environment variables.
Alternatively to the steps described in the section above, you can make use of the docker image we have prepared for the purpose of this tutorial.
66
66
You won't need to install any native dependencies there nor export environmental variables - however **your computer cannot be running on M1 processor**.
After running the command, a container terminal will be attached to your terminal. You will be able to find the project code inside the container in the `/videoroom` directory.
85
85
86
-
# What do we have here?
87
-
Let's make some reconnaissance.
88
-
First, let's run the template.
89
-
Before running the template we need to install the dependencies using:
90
-
```
91
-
mix deps.get
92
-
npm ci --prefix=assets
93
-
```
94
-
95
-
Then you can simply run the Phoenix server with the following command:
96
-
```
97
-
mix phx.server
98
-
```
99
-
If everything went well the application should be available on [http://localhost:4000](http://localhost:4000/).
100
-
101
-
Play around...but it is not that much to do! We have better inspect what is the structure of our project.
102
-
Does the project structure reassemble you the structure of a Phoenix project? (in fact, it should!). We will go through the directories in our project.
103
-
+**assets/** <br>
104
-
You can find the front end of our application. The most interesting subdirectory here is src/ - we will be putting our typescript files there. For now, the following files should be present there:
105
-
+**consts.ts** - as the name suggests, you will find there some constant values - media constrains and our local peer id
106
-
+**index.ts** - this one should be empty. It will act as an initialization point for our application and later on, we will spawn a room object there.
107
-
+**room_ui.ts** - methods which modify DOM are put there. You will find these methods helpful while implementing your room's logic - you will be able to simply call a method in order to put a next video tile among previously present video tiles and this whole process (along with rescaling or moving the tiles so they are nicely put on the screen) will be performed automatically
108
-
+**config/** <br>
109
-
Here you can find configuration files for given environments. There is nothing we should be interested in.
110
-
+**deps/** <br>
111
-
Once you type ```mix deps.get``` all the dependencies listed in mix.lock file will get downloaded and be put into this directory. Once again - this is just how mix works and we do not care about this directory anyhow.
112
-
+**lib/** <br>
113
-
This directory contains the server's logic. As mentioned previously, the Phoenix server implements Model-View-Controller architecture so the structure of this directory will reflect this architecture.
114
-
The only .ex file in this directory is `videoroom_web.ex` file - it defines the aforementioned parts of the system - **controller** and **view**. Moreover,
115
-
it defines ```router``` and ```channel``` - the part of the system which is used for communication. This file is generated automatically with the Phoenix project generator
116
-
and there are not that many situations in which you should manually change it.
117
-
+**videoroom/** <br>
118
-
This directory contains the business logic of our application, which stands for M (model) in MVC architecture. For now, it should only contain application.ex file which defines the Application module for our video room. As each [application](https://hexdocs.pm/elixir/1.12/Application.html), it can be loaded, started, and stopped, as well as it can bring to life its own children (which constitute the environment created by an application). Later on, we will put into this directory files which will provide some logic of our application - for instance, Videoroom.Room module will be defined there.
119
-
+**videoroom_web/**<br>
120
-
This directory contains files that stand for V (view) and C (controller) in the MVC architecture.
121
-
As you can see, there are already directories with names "views" and "controllers" present here. The aforementioned (tutorial) (the one available in the "helpful links" sections) describes the structure and contents of this directory in a really clear way so I don't think there is a need to repeat this description here. The only thing I would like to point out is the way in which we are loading our custom Javascript scripts. Take a look at lib/videoroom_web/room/index.html.eex file (as the Phoenix tutorial says, this file should contain an EEx template for your room controller ) - you will find the following line there:
As you can see, we are loading a script which is placed in `/js/room.js` (notice, that a path provided there is passed in respect to priv/static/ directory which holds files generated from typescript scripts in assets/src/ directory)
126
-
127
-
+**priv/static/** <br>
128
-
Here you will find static assets. They can be generated, for instance, from the files contained in assets/ directory (.ts which are in assets/src are converted into .js files put inside priv/static/js). Not interesting at all, despite the fact, that we needed to load /js/room.js script file from here ;)
86
+
##What do we have here?
87
+
Let's make some reconnaissance.
88
+
First, let's run the template.
89
+
Before running the template we need to install the dependencies using:
90
+
```
91
+
mix deps.get
92
+
npm ci --prefix=assets
93
+
```
94
+
95
+
Then you can simply run the Phoenix server with the following command:
96
+
```
97
+
mix phx.server
98
+
```
99
+
If everything went well the application should be available on [http://localhost:4000](http://localhost:4000/).
100
+
101
+
Play around...but it is not that much to do! We have better inspect what is the structure of our project.
102
+
Does the project structure reassemble you the structure of a Phoenix project? (in fact, it should!). We will go through the directories in our project.
103
+
+**assets/** <br>
104
+
You can find the front end of our application. The most interesting subdirectory here is src/ - we will be putting our typescript files there. For now, the following files should be present there:
105
+
+**consts.ts** - as the name suggests, you will find there some constant values - media constrains and our local peer id
106
+
+**index.ts** - this one should be empty. It will act as an initialization point for our application and later on, we will spawn a room object there.
107
+
+**room_ui.ts** - methods which modify DOM are put there. You will find these methods helpful while implementing your room's logic - you will be able to simply call a method in order to put a next video tile among previously present video tiles and this whole process (along with rescaling or moving the tiles so they are nicely put on the screen) will be performed automatically
108
+
+**config/** <br>
109
+
Here you can find configuration files for given environments. There is nothing we should be interested in.
110
+
+**deps/** <br>
111
+
Once you type ```mix deps.get``` all the dependencies listed in mix.lock file will get downloaded and be put into this directory. Once again - this is just how mix works and we do not care about this directory anyhow.
112
+
+**lib/** <br>
113
+
This directory contains the server's logic. As mentioned previously, the Phoenix server implements Model-View-Controller architecture so the structure of this directory will reflect this architecture.
114
+
The only .ex file in this directory is `videoroom_web.ex` file - it defines the aforementioned parts of the system - **controller** and **view**. Moreover,
115
+
it defines ```router``` and ```channel``` - the part of the system which is used for communication. This file is generated automatically with the Phoenix project generator
116
+
and there are not that many situations in which you should manually change it.
117
+
+**videoroom/** <br>
118
+
This directory contains the business logic of our application, which stands for M (model) in MVC architecture. For now, it should only contain application.ex file which defines the Application module for our video room. As each [application](https://hexdocs.pm/elixir/1.12/Application.html), it can be loaded, started, and stopped, as well as it can bring to life its own children (which constitute the environment created by an application). Later on, we will put into this directory files which will provide some logic of our application - for instance, Videoroom.Room module will be defined there.
119
+
+**videoroom_web/**<br>
120
+
This directory contains files that stand for V (view) and C (controller) in the MVC architecture.
121
+
As you can see, there are already directories with names "views" and "controllers" present here. The aforementioned (tutorial) (the one available in the "helpful links" sections) describes the structure and contents of this directory in a really clear way so I don't think there is a need to repeat this description here. The only thing I would like to point out is the way in which we are loading our custom Javascript scripts. Take a look at lib/videoroom_web/room/index.html.eex file (as the Phoenix tutorial says, this file should contain an EEx template for your room controller ) - you will find the following line there:
As you can see, we are loading a script which is placed in `/js/room.js` (notice, that a path provided there is passed in respect to priv/static/ directory which holds files generated from typescript scripts in assets/src/ directory)
126
+
127
+
+**priv/static/** <br>
128
+
Here you will find static assets. They can be generated, for instance, from the files contained in assets/ directory (.ts which are in assets/src are converted into .js files put inside priv/static/js). Not interesting at all, despite the fact, that we needed to load /js/room.js script file from here ;)
129
129
<br><br>
130
130
[NEXT - System architecture](3_SystemArchitecture.md)<br>
Hang on for a moment! I know that after slipping through the tons of the documentation you are really eager to start coding, but let's think for a moment before taking any actions. What do we want our application to look like?
Copy file name to clipboardExpand all lines: videoroom/4_CreatingServersCommunicationChannels.md
+3-1
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,9 @@ description: >-
8
8
</div>
9
9
---
10
10
11
-
# I know you have been waiting for that moment - let's start coding!
11
+
# Server's communication channels
12
+
I know you have been waiting for that moment - let's start coding!
13
+
12
14
## Let's prepare the server's endpoint
13
15
Do you still remember about Phoenix's sockets? Hopefully, since we will make use of them in a moment! We want to provide a communication channel between our client's application and our server.
14
16
Sockets fit just in a place - but be aware, that it is not the only possible option. Neither WebRTC nor Membrane Framework expects you to use any particular means of communication between
We are still missing probably the most important part - the heart of our application - the implementation of the room.
12
13
The room should dispatch messages sent from RTC Engine to appropriate peer channels - and at the same time, it should direct all the messages sent to it via peer channel to the RTC Engine.
We will put the whole logic into `assets/src/room.ts`. Methods responsible for handling UI are already in `assets/src/room_ui.ts`, let's import them:
12
13
```ts
@@ -136,8 +137,6 @@ According to MembraneWebRTC [documentation](https://hexdocs.pm/membrane_rtc_engi
136
137
137
138
We will go through the callbacks list one by one, providing the desired implementation for each of them. All you need to do later is to gather them together into one JS object called ```callbacks``` before initializing ```this.webrtc``` object.
We can share with you inspiration for further improvements!
12
12
## Voice activation detection
13
13
Wouldn't it be great to have a feature that would somehow mark a person who is currently speaking in the room? That's where voice activation detection (VAD) joins the game!
0 commit comments