All of these is exposed in this figure :<\/p>\n
![\"how_to_open_arch_video_step1\"](\"https:\/\/www.alkannoide.com\/wp-content\/uploads\/2013\/06\/how_to_open_arch_video_step1.png\")
<\/a><\/h3>\nThe generated assets are transfered in the delivery zone storage.<\/p>\n
Service : Manager<\/h3>\n
Here is the intelligence of the system. You have two choice :<\/p>\n
\n- create your own system. In this case, t<\/span><\/span>he manager need some developments, you can choose the language you want : Python, PHP, NodeJS, Java, Perl, etc…<\/li>\n
- using a system already\u00a0developed. I think about Kaltura platform for example. This option need some integration and learning time if you want to use it.<\/li>\n<\/ul>\n
I\u00a0recommend\u00a0to associate your code to a database.\u00a0The database will save the metadata of your video assets and some configurations datas.<\/p>\n
\n- relational\u00a0database : <\/span>MySQL<\/a>, <\/span>PostgreSQL<\/a>, <\/span>SQLLite<\/a>, …<\/li>\n
- non-relational\u00a0database : Redis<\/a>, …<\/li>\n<\/ul>\n
Service : Bus<\/h3>\n
The service bus will use the concept of\u00a0Message queue<\/a>. That is very interesting because it helps to manage more easily the communication between each application : you send the message and the library or the system make the rest. There are many tools in the open source world :<\/p>\n\n- ZeroMQ<\/a>,<\/li>\n
- Gearman<\/a>,<\/li>\n
- RabbitMQ<\/a><\/li>\n<\/ul>\n
For each message queue solutions, you will find connectors for separates languages (C, C++, PHP, Python, Perl, …). Depends on the message queue solution you choose, you need to make more or less developments.<\/p>\n
Service : Worker<\/h3>\n
Workers services are here to make specific tasks :<\/p>\n
\n- encode<\/strong> : this service is based on the most famous open source tools in the encoding’s world : ffmpeg<\/a>\u00a0and its differents libraries (libfaac<\/a>, libx264<\/a>, …). But you can use mencoder<\/a> too.<\/li>\n
- package<\/strong> : the objective is not to\u00a0encode the video asset, but to change the format. Some tools are available :\n
\n- MP4Box<\/a>\u00a0: to manage MP4 files or MPEG-DASH<\/li>\n
- f4fpackager<\/a>\u00a0: to generate HDS, you will need to deploy the HDS module for Apache in the delivery platform<\/li>\n
- mediasegmenter<\/a>\u00a0: to generate HLS<\/li>\n
- FLV2DTSC<\/a> : to generate DTSC if you want to use MistServer<\/a> (a solution I told in previous articles<\/a>).<\/li>\n<\/ul>\n<\/li>\n
- transferts<\/strong> : at the end of a process, you will need to transfert the asset to a destination. Transfert workers is able to use some protocols : FTP, SCP, HTTP, etc… So you can push the content to the delivery storage.<\/li>\n<\/ul>\n
All of this services can be in the same physical server. If you have more assets to manage and generate, it is possible very easily to scale up. Workers can be deploy on dedicated server and the bus service is here to manage the network. You can add another service manager to add\u00a0redundance. Thoses updates will have a impact on the reliability of the platform.<\/p>\n
Here is one solution which include the most part of those precepts : Transcodem<\/a>. You can fork this project on GitHub too.<\/p>\nDelivery<\/h2>\n
Ok, now your assets are ready to deliver and are in the delivery storage. In our architecture, we want to stream content based on HTTP protocol (HDS, HLS, Smooth Streaming). You can start with one physical server, but all tools and the architecture I expose can scale up easily to many physicals servers. We have many tools to help us :<\/p>\n
\n- HTTP webservers : Apache<\/a>, NGinx<\/a>, Lighttpd<\/a> and differents plugins (module origin from Adobe<\/a> to stream HDS for example)<\/span><\/li>\n
- Media servers : Red5<\/a>, MistServer<\/a><\/li>\n<\/ul>\n
And if your platform will support a high load, you can use proxy cache solution like Varnish<\/a>. I gave in a previous post a solution to deliver content with Varnish and MistServer<\/a>.<\/p>\n
I\u00a0recommend\u00a0to associate your code to a database.\u00a0The database will save the metadata of your video assets and some configurations datas.<\/p>\n
- \n
- relational\u00a0database : <\/span>MySQL<\/a>, <\/span>PostgreSQL<\/a>, <\/span>SQLLite<\/a>, …<\/li>\n
- non-relational\u00a0database : Redis<\/a>, …<\/li>\n<\/ul>\n
Service : Bus<\/h3>\n
The service bus will use the concept of\u00a0Message queue<\/a>. That is very interesting because it helps to manage more easily the communication between each application : you send the message and the library or the system make the rest. There are many tools in the open source world :<\/p>\n
- \n
- ZeroMQ<\/a>,<\/li>\n
- Gearman<\/a>,<\/li>\n
- RabbitMQ<\/a><\/li>\n<\/ul>\n
For each message queue solutions, you will find connectors for separates languages (C, C++, PHP, Python, Perl, …). Depends on the message queue solution you choose, you need to make more or less developments.<\/p>\n
Service : Worker<\/h3>\n
Workers services are here to make specific tasks :<\/p>\n
- \n
- encode<\/strong> : this service is based on the most famous open source tools in the encoding’s world : ffmpeg<\/a>\u00a0and its differents libraries (libfaac<\/a>, libx264<\/a>, …). But you can use mencoder<\/a> too.<\/li>\n
- package<\/strong> : the objective is not to\u00a0encode the video asset, but to change the format. Some tools are available :\n
- \n
- MP4Box<\/a>\u00a0: to manage MP4 files or MPEG-DASH<\/li>\n
- f4fpackager<\/a>\u00a0: to generate HDS, you will need to deploy the HDS module for Apache in the delivery platform<\/li>\n
- mediasegmenter<\/a>\u00a0: to generate HLS<\/li>\n
- FLV2DTSC<\/a> : to generate DTSC if you want to use MistServer<\/a> (a solution I told in previous articles<\/a>).<\/li>\n<\/ul>\n<\/li>\n
- transferts<\/strong> : at the end of a process, you will need to transfert the asset to a destination. Transfert workers is able to use some protocols : FTP, SCP, HTTP, etc… So you can push the content to the delivery storage.<\/li>\n<\/ul>\n
All of this services can be in the same physical server. If you have more assets to manage and generate, it is possible very easily to scale up. Workers can be deploy on dedicated server and the bus service is here to manage the network. You can add another service manager to add\u00a0redundance. Thoses updates will have a impact on the reliability of the platform.<\/p>\n
Here is one solution which include the most part of those precepts : Transcodem<\/a>. You can fork this project on GitHub too.<\/p>\n
Delivery<\/h2>\n
Ok, now your assets are ready to deliver and are in the delivery storage. In our architecture, we want to stream content based on HTTP protocol (HDS, HLS, Smooth Streaming). You can start with one physical server, but all tools and the architecture I expose can scale up easily to many physicals servers. We have many tools to help us :<\/p>\n
- \n
- HTTP webservers : Apache<\/a>, NGinx<\/a>, Lighttpd<\/a> and differents plugins (module origin from Adobe<\/a> to stream HDS for example)<\/span><\/li>\n
- Media servers : Red5<\/a>, MistServer<\/a><\/li>\n<\/ul>\n
And if your platform will support a high load, you can use proxy cache solution like Varnish<\/a>. I gave in a previous post a solution to deliver content with Varnish and MistServer<\/a>.<\/p>\n
- Media servers : Red5<\/a>, MistServer<\/a><\/li>\n<\/ul>\n
- f4fpackager<\/a>\u00a0: to generate HDS, you will need to deploy the HDS module for Apache in the delivery platform<\/li>\n
- package<\/strong> : the objective is not to\u00a0encode the video asset, but to change the format. Some tools are available :\n
- Gearman<\/a>,<\/li>\n
- non-relational\u00a0database : Redis<\/a>, …<\/li>\n<\/ul>\n