Live Streaming Architecture

hi I'm Ulysses welcome to livestream ninja this is episode number 6 and in this episode we'll talk about live-streaming architecture if you need to get a good understanding and grasp of how live-streaming works you can understand the architecture so I'd like to share with you three areas that cover is basically the live streaming architecture and that's the publishing side the streaming planet and then the viewing side so let's look at that and share with you my slide so first of all publishers side so you have a live event whether you have a speakers or some kind of sports event and you want to capture that so you have a camera and some kind of audio source whether it's a microphone and it's connected to a mixer or through the audio system the house system so you capture that using some kind of power encoder so the encoder could be a software encoder that runs on some kind of desktop or it could be a hardware encoder or it could be an IP camera or it could be a browser in the case of WebRTC so let's talk about software encoder first so if you have a software encoder is usually some kind of PC or desktop whether it's Mac Linux or or a PC running Windows it doesn't really matter and so you need some kind of capture device to be able to capture your video and your audio whether it's a PCI card or an external device doesn't really matter and you have some kind of software encoder that runs on that desktop you know once again that desktop could be a PC could in Mac or Linux so that software encoder captures leave the camera captures the audio and video sources and then streams it using the RTMP protocol or real-time messaging protocol and connects to the streaming server so in the software the software encoder there's usually some kind of rtmp server information that you have to provide as well as the port and the app name and then the streaming name as well as a username and a password so you can figure that to connect to the live streaming server now some of the examples of software encoders are out there there's like ASP and very popular probably the de-facto standard and then there's B mix there is ODF which is open source and OBS means open broadcasting software there's xsplit there's others out there and there's dozens of software encoders out there that you allows you to connect to a streaming server then you have a hardware encoder so if you don't want to use a PC for example if you use a hardware encoder hiring coders are basically devices that are specifically designed for streaming and doesn't do anything else but just streaming so it's not as you know like it like a PC does all these different things you can do all the different things like you know what processing causing and all that but a hardware encoder basically just um it's all sole purpose is to stream to the streaming server so it usually has some kind of web interface so you could put in the rtmp server the port username passwords the live app and in this streaming name and you have to provide that on the web interface on the hardware protocol of the hardware encoder now you can also use an IP camera and I could be camera as a camera that's connected to the network shoe to stream using RTSP or real puns streaming protocol usually when you use RTSP you have to port forward especially if your streaming server is outside of the local network and in most cases it is then you have to open up that port on your router to be able to pour your shimmy server and be able to see it some IP cameras have the rtmp feature so you could just like the software in color and the hardware encoder you can use the RTMP protocol and you could push that out you don't have to open up the firewall using the RTMP protocol so that's an IP camera with both RTSP and rtmp protocols and then lately if you heard of the technology called WebRTC WebRTC allows the browser such as Google Chrome or Firefox to be able to capture your camera and audio source from there the WebRTC will publish or connect to the Shamy server through what you call session description protocol or FTP now there will be other protocols another format that the WebRTC uses like ice turn stun servers and stuff like that that's all you technology and not too many people use the browser WebRTC to stream but it's an option whilst excusing and now it's capable you could do that using the losses server so let's talk about the server on streaming server basically ingest rtmp connection so you have real-time messaging protocol and it's able to allow ingest that or you can adjust our TSP connection as well from from an IP camera and it does a couple of things on the streaming server will actually you could tell it to do ABR adaptive bitrate streaming or adaptive bitrate streaming is let's say you have a 1080p connection that's incoming and utilities you're gonna create another format and a different resolution in a different bitrate at 720p at 640 480 at 360 and so on so you have one incoming stream and it creates multiple resolutions and the different bit rates and that allows what you call adaptive bitrate streaming so your player your video player or media player or viewing is capable of doing that you know such as JW player so um it delivers the video to your viewers without any interruption even if their connection slows down so it does slow down let me get switched to a lower resolution if and it improves they switch to a high resolution and that's what adaptive bitrate streaming is so instead of you know providing a single stream at you know let's say a 1080p you're providing multiple resolutions and different bit rates send the player smart enough to switch based on the viewers bandwidth the streaming server also can create multiple formats so if you have an RTMP connection it can create different formats such as Apple HLS MPEG - until the HDS or Microsoft streaming or our TSP as well so is able to do that and then obviously you have a player for each of those different formats the other thing that a streaming server can do is also restream your incoming stream to other streaming servers or streaming providers such as YouTube Facebook live Ustream livestream twitch so you could send your single stream your incoming stream to other services as well using the restream feature in the case of Bozza usually if you just have one server they call that the origin server now for scalability if you want you know let's say you're hit you got a thousand users and your CP usually up there you could always get a higher CPU and get a higher server with you know more memory more CPU but you could also create recall edge servers or your km servers in different parts of the world you know you know strategically put them in in geographic areas where your viewers are and you can configure a loss of saving server as an edge server and that edge servers and you have multiple edge servers around the world and those servers there's edge servers are talking to the origin server so that's one way of architecture in the your streaming server another way is using we call content delivery network using either Amazon and a top front or Akamai or Microsoft Azure or the Google cloud platform and it does take HLS and MPEG DASH only because those are based on HTTP and won't work with rtmp or RTSP so what it does is basically the same concept that walls are using using edge server so but in this case you're using Amazon Cloud you service provided by Amazon or a coma or Microsoft Azure of Google and they will configure edge servers around the world and then you do what you do is you create a player that points to that DNS so Google and Amazon will will provide those DNS names for you and they will do all they handle all the domain name services so the viewers are connecting to this the servers that are closest to them so they will do that all you have to do is push it and configure it so you got one streaming server push it to the cloud on the delivery network and then you create a player using the DNS at the CDNs provide for you so that's how you scale and reach your viewers around the world and then you know doesn't matter how many viewers you in the case of Amazon you can have thousands and thousands and thousands of users using the CDN and they will handle everything for you now I'm reviewing side so definitely for your viewers to view anything they got to have some kind of media player that medic player could be on this service provider you know such as YouTube and Facebook so they have an embedded on their pages but you can also create an embed a player on your own website so in the case of wowza they allow you to use some kind of media player such as with pod JW player and embed that into your website and then you have to configure the JW player to talk to the streaming server so in terms of protocols if you want to reach and you want to use a protocol that reaches to every device whether they're on the phone on a tablet or in a computer the most popular and probably the most universal protocol is hls because it will play on every device practically but if you want something that has low latency at these rtmp but rtmp has limitations at one time tchau flash was adequate it was everywhere on every desktop in every device but that should change over the years first Microsoft dropped support for flash and now Google and Firefox are eventually going to go away from that and start and stop using flash so as of right now yeah you can still use if you want a little late latency to use rtmp but you're going to have some kind of player that supports Flash such as JW player but you won't play on iOS if you want ILS you gotta use HLS and the future really of live streaming depends on mpeg-dash and big - is a bunch of companies gotten together and created standard using MPEG DASH and big - pretty much plays on every device except for Safari and iOS devices and opera the Opera browser does not support um MPEG - now that that is the feature but if you want to be able to play on all devices I recommend that you use HLS and if you want a little latency on certain devices like desktops then you have to use our TMP you know using a player like an JW player but anyway that's essentially the architecture you get the publishing side the server side as well as the viewing at a playback side so if you have any question just post on the comments and don't forget to follow and subscribe and visit our website and thanks for watching we'll see you in the next video thanks

Channel: livestreamninja

Views: 91,023

Keywords: architecture

Id: RvsaosnEHWc

Length: 14min 47sec (887 seconds)

Published: Fri Jan 27 2017