Streaming Video in Django | Demystified with Vaarun Sinha

Carbon Before I start with this talk, I just want to ask one question. Where are you watching this talk from? I am not talking about the location. I am talking about from where are you watching it? Probably some video streaming platform or maybe even YouTube, right? But this video or this whole talk is of 25 minutes and the file is of some gigabytes If you download this file, then it will take you probably a few minutes to download it, right? But how is it that when you click on this video or join a session from somewhere, it plays so instantaneously? This is possible with the magic of video streaming. Today in my talk I will explore what video streaming actually is and how to implement it in your Django application. So let's start. So first

Let's see the textbook definition. Streaming media is multimedia for playback using an online or offline video player. Technically, the stream is consumed in a continuous manner by the client. In this case, your video player. Sounds a bit complex, right? But this isn't one of those talks where we go about telling technical definitions. Let's understand what video streaming actually is Like we are a bunch of 5-year-olds. If you are adding a video to your website with normal HTML like this, then the browser will actually download the whole video before playing it. This works well for small videos. But for larger videos like this one, it will take a huge amount of time. Then how do websites like YouTube or Netflix play these videos so instantaneously? Basically what happens is that whole MP4 video is split it into multiple parts and what these video players have is an index

where they have small segments of videos of 8 seconds, 16 seconds or 10 seconds each. Then according to the user they play the video one by one. For example, if I suddenly go from 8 minutes to 18 minutes, then the video player will only request the segment which is in that particular timestamp. For example, 18 minutes. So it doesn't have to load the whole video before I watch it. This is called video streaming. And this video streaming is majorly done with two protocols. HLS and MPEG dash. The thing is basically the same. The whole video is converted into segments and there is an index file. But sure, there are some caveats In MPEG it is more flexible with the kind of videos you can encode. It has H264, H265, etc. For each video resolution, MPEG Dash just uses a single stream.

But HLS on the other hand is very specific on the type of encoding it uses. Interestingly, for each video resolution, whether it be 720p, high definition, low definition, whatever It uses different different segments. So when you are using HLS for video streaming, the player picks the best resolution according to your internet speed. These are the major differences. Now While describing these caveats or differences, I did throw two big words around. What are those? Encoding and codecs. Encoding sort of in a Lehman's language means to shrink something down. And codecs are instructions on how to unshrink those files. Now, with these basics out of the way, let's go on and see how we can do this in Django. I have divided this approach in three major levels. Level 1, where the user does all the work

Level 2, where we have some optimizations in place, and level 3, which is the most optimal way to stream video, but with a few complications. But before we go on, we have to create some basic models. I will create two models: the video And the segments. And the segments will have a foreign key relation to the video. You can see the code snippet on the screen. Imagine you have a video which you need to stream. As discussed previously You have to convert these videos into many segments and have an index file. So in level 1, we'll make the user do all that and just upload it via Django form or Django admin, just for simplicity. So, what are the pros of this approach? First, there is flexibility, there is no video processing load on the server itself, and users in full control. This is great for Small applications. But cons are that there will be inconsistent encoding, quality variation, and lastly, if the user is not that much technical, it will be hard for them to convert these videos into proper HLS files

or MPG-files. Level 2. Rather than making the user encode the video, we just ask the user to upload the mp4 or the normal format video. Then after that we create a model function like this video where we use fmpeg to convert this video and store it and then upload it in segments. And once again, the front end can directly access the whole stream using the. hls file. But in this, you have to trigger the model function according to what do you need. And it might happen that the model function fails And it stops the whole process. Now let's go on to the best level, level number 3. In level 2, the major con is that these things take a lot of time. So it will at least take a few minutes before you return a response to a user that your video has been encoded successfully. Right? But in YouTube

Creator Studio After you upload a video, it shows that the video is processing. But it instantly gives you a response and also shows you the progress. How does that happen exactly? So, to accomplish something similar in our project What we will do is that when a user uploads a video, we'll automatically offload the task to salary. First, we have to create a salary task. I'm not going to go over the whole code, but it is exactly the same as the model function with a few changes. Then we have to create an endpoint which takes in the video and returns a task ID as well as a message That video is still processing. Now the task is created and the task is offloaded. So the pressure is not on Django but on Celery. Right? But still How do we stream the progress from here to our Django application or any other front end?

How will that happen? That will happen with the power of Django channels. If you don't know what Django channels is, Django channels Majorly enables us to work with WebSockets in Django. Just a loose definition. So first we need to create a consumer. The code is here. So the consumer is pretty simple because it's just an exchange of a few numbers, right? After that Once the task is returning, we have to just add one more line of code into it. What is that? We have to create a group task underscore task ID where our salary task will also join the group and the user or the front end will also join the same group to receive the updates. So now the consumer is created, the group is created. Now let's put some code in a salary task so that before encoding it It joins that task and after that it sends the progress. So that is not possible with

normal fmpeg. We have to install a new package known as fmpeg progress where we also receive the progress of our fmpeg task. Then we have to join the group and send our progress into it. It's just that simple. Then in front end we just have to connect to that web socket and we will receive all the progress updates. So what are the pros and cons of this approach? The pros are that everything is handled asynchronously so that the users can continue interacting with the application without waiting for the response. Second, the users also receive real-time updates rather than waiting cluelessly in the level number two. Right? And it is also Scalable. Celery's architecture allows us for horizontal scaling. So, what are the cons of this approach? The major cons are first complexity. You have to set up Celery as well as Django channels and as well as a ASGI server.

Right. Second, there is a resource overhead. Adding salary into your application consumes some resources, specially in smaller scale deployments. And then there is also learning curve and maintainability. Many developers here don't know about Django channels or Fmpeg or Celery. So these are the major cons of this approach. So in level 1 we make the user do all the work. In level 2 we help them but they are still clawless. In level 3 we help them And we have asynchronous updates to them. Level 1 is optimal for very small applications. Level 2 is applicable for medium applications And level 3 is applicable for any application which has a feature of video streaming specially. I have implemented the models, the model function and the celery task along with the consumer and these

endpoints in a consolidated package known as Django Video Streaming which I have put under an MIT license. on GitHub and also as a Django package. And according to the level you want to implement in your application, you can use that package. So this was all of it. Before we started this talk Video streaming might have been a complex topic for you, but now I hope it is more simpler for you. Let me conclude what we have learned in this talk. First, We have learned what is video streaming. It is essentially dividing up the video into smaller segments and having an index file. Then we have learned about the two major protocols used for video streaming and their major differences, which are Flexibility of codecs and granular control on quality of video. Then we have also learned what are encoding and codecs.

And then we have also learned how to implement video streaming in our Django application. on various different levels. In level 1 we made user do all the work. In level 2 we helped the user. In level 3 we added celery and Django channels To create a great experience for the users. So that is it from my side. Thank you for listening to this talk. And now you might ask, who am I I am Varun Sena, I am co-founder and CTO of Digi and also the lead instructor at Axe Code. I hope you love listening to my talk today You can connect with me on LinkedIn, GitHub or email. Thank you.