 When is later going on to the next talk, so the next talk is a hands on session compared to what the previous Looks so Live Streaming with a dyna'r unig o'r rhan o'r ffordd ymddangos. Ac mae'n gweithio'n rhan o'r tutorial o'r ddau'r ddau. Felly, ddafodd, mae'n ddau. Dwi'n ddau fydd eich bod hynny'n ddau. Felly, y cwmponent yn ymddi'r R. Ynglynllus, y model RTP, ynglynllus'r HDML5 ar gyfer, sy'n ddau'r ddau'r cyfnodd yn y prifsgwys. Yn y cyfnodd ar gyfer. I'll show you exactly how to get that done. Licences, so everything's open sourced. EngineX is BSD, the RTMP model as well. We're AGPL, FFAMPEG is GPL, and that's pretty much what consists of our solution. The installation is quite easy. We provide both RPMs and DEBS, which run on RHEL, CentOS, Debian and Ubuntu accordingly. We support various PHP versions as well, starting from 5.3 and up to 7. The presentation includes links to installing the software as well. I've pre-installed it. It takes about 10 minutes and the entire session is 25. Out of that consideration, the demo will be live, but the installation will not be demonstrated. It's quite easy and we're happy to get support and questions via the forum or email and various other options that I'll mention later on. Let's review some of the important packages that we have for this solution. As I said, we produce both DEBS and RPMs. The culture engine X is mostly a vanilla engine X that's compiled with a few extra models that we require. One of them is, of course, and the main component in our presentation is the RTMP model. That's also entirely open sourced, as I've said. The license under BSD. Then we also have the cultural base component, which provides the server-side code, which is mostly PHP. That's also entirely open sourced, AGPLed. We have the cultural front, which consists of an Apache web server running our player, which is written in PHP mostly, PHP and JavaScript. We have the FFN peg that we also use for live streaming. Mostly, people, when they think about RTMP, they often use FMLE, but that's closed sourced and I personally don't like closed sourced solutions that much, so I'll show you how to live stream using FFN peg only. Seeing how we make vast use of FFN peg in other components of our server, including to perform the transcoding operations, we already have that included. If you've installed cultural server, you also get FFN peg command line utility that you can freely use and achieve that goal. The RTMP configuration, the configuration pass very somewhat depending on whether you've installed RPMs or Debs, but the configuration itself is unified. In our current environment, we'll be using Ubuntu, so that's a Deb package. This keyboard is going to be somewhat challenging because it's both Mac and a French layout. So we'll see how well I do. If I don't do that well, it's not because I'm stupid, I'm just not used to it. All right, so try to be understanding. That's far I've done well. I managed the slash and everything, I'm so proud of myself. I don't think we can see too well though. It's a bit of a concern to me. Can you see all right? All right, good, so it's just me. The most important portion of our configuration, this is the Nginx config file, the main one, is here. So this is the HTTP server. This is an integration with a different model that I wouldn't be showing today that I've actually demonstrated last year. That's our own Nginx VOD model. I recommend you check the session from last year because it might interest you as well, but I wouldn't stick to that at the moment. Then we say that we'd like to listen on port 88. This is just a random choice. You could put it on any port. The reason why I'm not using 80 is because Apache consumes 80. We use that for the front-end. So this could easily be because we have other applications for the server. I'll be showing them as well. They're not the focus of this session, but I'll show them. All right, so we've chosen 88. You could choose anything else. Frankly, 88 is not that good of a choice because it's a well-known port for Kerberos. Nobody uses it nowadays, but still I wouldn't recommend it. So choose something else like 88, for example. Then we have the server name. It's IP because it's a demo machine. Then we go to the RTMP configuration portion. A few words about Nginx. It's a very good server. It can do a lot and has a lot of interesting models. Starting from version 1911, DSO support was introduced. DSO is a dynamic shared object. You could dynamically compile additional models onto Nginx and load it. Prior to that, you had to statically compile all models into the Nginx. That's the reason why we produce our own culture Nginx package. If you're using Nginx from higher versions, you could compile these models independently and load them during runtime. So that's an important note. For RTMP, the configuration, the very basic configuration is quite simple. We'll just say listen on port 1935, TCP, which is the default RTMP port. We'll be using that to stream to the server. Then, as far as playback is concerned, we'll use HLS and port 88, which again could be changed. Now, as far as the application goes, we'll call it cave live, for example, cave for cultural. Then we need to allow the live input. In our case, we'd like both dash segments and HLS segments and manifests. So we've got both dash on and the dash path. That's where the manifest and the fragments would be stored. And we've got the HLS with a similar directive. Now, of course, on a production environment, you'd like to have more than one node for both redundancy and capacity. So bear in mind that in such a setup, the HLS path and the dash paths need to be accessible from both nodes. You could put it behind a very simple load balancer, even HA proxy, for example, in which case you could also produce SSL offloading so that you could use RTMP over SSL as well for encryption if you're interested. Many big vendors have this concern where they'd like everything to be encrypted, so that's a very cheap and easy way to produce that. In our setup, it's just one node, so it's irrelevant, but just saying so you'll know. All right, so that's our configuration. Now, let's go to our web interface for a moment, if you don't mind. This would be a very massive challenge to find the semicolumn. I can do it, I believe in myself. All right, perhaps I can't. Can you? What do you want to do? This one, I want the column, so that's lovely. Yes, very good. He's smarter than I am. That's very impressive. All right, now let's try to open a web browser. That's also very hard to do. Mac and I don't get along that well. Finder? You want a browser, right? Yes, I don't even care which. Okay, Safari is okay? Yes, that's fine. You don't get an IP? Yes, yes, I do, but so you just, okay, like this. I don't use Macs, sorry. All right, hold on. Yes, that would be hard to do. There's a learning curve, I'm doing better. So I'm going to take you now to our admin interface for an equal to our platform, where you can do tons of things, but I wouldn't be demonstrating most of them today, seeing how we're very short on time. But we'll see some parts for our demo. So let me just log us in. Look at me go. Yes, I can hear the French people snickering. I can. That's all right, that's good. Humor is good. It makes for a more interesting presentation, doesn't it? All right, how do you enlarge this window? Oh wow, look at that. Do you have Chrome? Is Chrome installed here? No? Chrome? Or Firefox maybe? That'd be nice too. Okay, Safari doesn't work so we know that. Oh, here we are. It's very insistent about Safari, isn't it? It's like give it a try. Give it a try, you want Safari. I know you do. Yes, that's all right. I think I'm capable of that. You're faster there. All right, let's do it again. What's with the A? What can't it be where it should be? It's a good thing I have a simple password for this one. Here we are, good. So let's manage our media. This is so much fun. It's amusing, it's true. All right. Oh, look at it go. First it said no, then it said yes. All right, good enough. So, we've set up Nginx and we've looked at the configuration. We have two tasks to finish now. One of them is to create a Kultura entry for integration between Kultura and the Nginx RTMP model. And the other is to stream. And then, if we have time, maybe we'd like to actually play something. I don't know, it's not that important, I suppose. But I think it might add something. So, let's create a new entry. It seems that I can't navigate forward for some reason. See, there are more tabs over there, but they're not visible. Oh, here we are, here we are. There we go. See, that's a learning curve. All right. So, live stream entry. We'll give it a name. Let's do FOSDM2. That's just a descriptive name. It doesn't really have any bearings over the process. And let's say manual live streaming. Not akamai. And here, we just need to put in a URL for our Nginx playback. I've had the wisdom to do this so that I could copy paste, which may prove to be harder on Mac, but we'll try. Look at that. That's amazing. All right. So, what have we here? This is the IP for the Nginx server. As we said, streaming would be done over RTMP, but playback would be done over HTTP using HLS. So, we'll say this is the IP. Our port is currently 88. And this is the path, which corresponds, if you look at the configuration here. There we go. So, this is the HLS me, right? So, fragments and the manifest would be kept here. We'll see a sample of what it looks like. So, this is part of the path, and this is the manifest for it, which our player will require in order to playback. That's it. That's all the parameters you should require. Then you do create live stream. And then you navigate back. Maybe work this time. Here we are. And we'll see a new entry here. Trying to navigate to the other columns, and apparently the technique I've found before doesn't work with this. Hold on. It's like with two fingers. Amazing. All right. Now, I need to go to the other side. Let's, okay. Here we are. Let's choose one of our new players. Good. And we're ready to stream. Now, seeing how we'll be using ffempeg from CLI, we're actually able to stream from the server itself onto itself, which is nice. So, let's do it. I should already have the command in my history. All right, that's fine. Never mind. So, this command is also in the presentation. Basically, it's rather simple. ffempeg minus re minus i. Then the path to the video you'd like to stream. A few other ffempeg flags here. And then the RTMP URL for the NGINX. Simple enough. Let's run it. Look at it go. Now, if I'll only be able to open another tab, maybe we can look at the contents too. That'd be a command T then. Oh, much easier. All right. Let's just search to the same place. Almost. So, we should be seeing fragments now. Let's take a look. So, var, tmp, hls. Here we are. Look at those people. All right. Where is the asterisk? Okay. Here we go. So, we've got the manifest. And we've got the fragments. If you're curious about what the manifest looks like, it's a very simple format. All right. So, text file, fragments, and that's pretty much it. And now, let's have a look at the player. I've also noticed that in my ffmpeg command, instead of saying FOSDM1, I said FOSDM. So, instead of looking at this entry, let's look at this one. This is married with children. It's a very nice sitcom from the 90s. Most of you are unborn. Be careful. All right. And of course, you can open it full screen if you'd like. Some humor is always good. And that's pretty much the way it works. So, if there are questions I'd like to take now. So, that's a good question. You can go. I'm sorry. So, the question was rather all the fragments are removed from the server or rather you can go back and forth. Is that correct? So, the answer is that's configurable via the RTMP model directives. There are a lot of directives that I recommend you take a look at. And in the presentation, you'll find a link to them. So, you can decide rather or not you'd like to keep the old fragments so that you can go back and forth or rather you'd like to discard them. Other questions? Right. So, first of all, this is not my model. The presentation actually makes that quite clear. This is an open source model by someone else. A very nice person who has an open source project. The cultural portion is what is the company I work for and I do the integrations and the packaging of devs and RPMs and so forth. The model itself is not mine. If we look at the presentation for a moment, I'm just skipping forward. All right. So, these are the people. So, the guy that maintains and started this project, the RTMP model is Roman. And if you look at the appendix, you'll find links to everything. Both stuff that I'm responsible for, other cultural resources, his project, of course, engine X and so forth. But back to your question as to the advantages. So, there are a few other alternatives. We also have setups with Wausa, for example. And whilst Wausa is a well-known player in the industry and I can't say their products don't work, they're not open. So, if you need a very fast configuration, RTMP solution that's open, I would certainly recommend this one. For us, it was no-brainer because we also have other integrations and models that use the engine X. And so, because of the VOD model, for example, which is something that we do maintain in-house and a project that we did start in-house, we already had engine X in all our deployments. So, for us, it was no-brainer to make that choice. There are other solutions and some of them are also open. With RTMP, if you want to use WebRTC, for example, there are many others and we've actually seen quite a few sessions about them. One was MediaSoup and I've seen a few others. So, there are definitely other open alternatives, but I've found by researching that if you want RTMP, this is probably the best shot. At least it was for us. I mean, every project has different considerations naturally. But for us, this was a very good choice. Well, you know, latency is always a problem, right? I mean, everyone here is latency. There is pop-up like this because it's a very common problem. That depends on how you define very low latency. How would you define that with RTMP? Less than a second. Frankly, I haven't seen anyone who's managed to get there. I'll be happy to see it, though. I mean, it sounds very nice. But I haven't seen it yet. OK, thank you very much. Thank you for joining.