Author: Yakov Zhdanov
Many systems support video upload and viewing functionality. Of course, all video files uploaded by users shall be converted to some common format (flv format as usual) to make playback easier, probably scaled to common resolution, or watermarks are required on the site, etc. Therefore, developers have to solve the problem of video conversion very often and use various approaches.
In this article, we will try to provide our vision to implementation of this kind of a system, sample system functions in a real world application. Our demo sample is written in Java (Spring + Hibernate), uses FFmpeg as a converter facility and JMS to interact with an external (invoking) system and for internal communications.
Business Goals
A video conversion system should address the following issues:
- Convert video to a desired format on demand of an invoking system;
- Notify the invoking system when conversion completes, including information on the conversion results (success, failure etc);
- Provide facilities for monitoring by administrator;
- Provide facilities for cancelling a task;
- Provide automatic load balancing.
In addition, the video conversion system should address the following technical requirements:
- Be fully independent from the main application; it should not depend on the domain model or architecture of the invoking application, this makes its re-use possible;
- Provide significant level of performance scalability;
- Be robust;
- Prevent data loss.
Architecture Definition
In order to achieve a significant level of performance as well as lower the cost of the system enhancement, we’ve introduced asynchronous architecture of the video conversion system with no synchronous processes, and processing is implemented asynchronously so that the system can be easily scaled for processing of a large number of asynchronous processes.
Components
The system consists of the Video Conversion Dispatcher Server and a number of Video Conversion Clients specifically performing the conversion.
The aim of the dispatcher server is to balance the load of the conversion clients. It also will add tasks to its internal queue, persist them if necessary to ensure the system is robust and prevent data loss.
The Dispatcher Server also provides desired administration and monitoring options.
The client converts video using FFmpeg launching it as a separate OS process and then saving the results of the conversion directly to a resource storage if conversion successful.
Each client is assigned to with a unique name by the system administrator.
Please, refer to figure 1.
Brief Explanation of the Workflows
The system workflow is the following:
- The external system has to convert a video file, so it fires out an event, containing all necessary data for conversion. The event is processed by the video conversion server.
- The Server, while handling the event, creates a video conversion task, saves it to the DB; then if there are free clients the task is forwarded to a particular client for completion. If there are no free clients at the moment the task is pending. The Server will assign and forward it to a client once there is a free client available. The internal JMS topic is used for task transporting.
- The Client receives the task, determines where the original resource is stored. It chooses an appropriate storage connector and downloads the resource.
- The Client sends the message telling the server that video conversion has been started, launches FFmpeg as a separate process and waits until it exits. If FFmpeg does not exit after a predefined timeout, the client terminates it and reports an error to the server by sending a JMS message. Also, the error is reported in case FFmpeg exited with an error.
- If FFmpeg exits without any error and the result file is of non-zero length, the conversion is considered successful. The Client uploads the result to the resource storage and notifies the server by sending a JMS message.
- The Server forwards the information regarding video conversion start and completion to the main (invoking) system.
Communications
As mentioned above all communications are performed through JMS. The Dispatcher server communicates with the external system using JMS topic. For internal communications, we use JMS topic as well.
To make implementation easier we use object messages and all information is sent as an object (event-object) inside the message.
Other workflow notes:
- When the server starts it sends a broadcast message to all the clients to determine clients number and statuses. Also, the server looks through the persisted tasks to find tasks that have not been dispatched, and if there are such tasks dispatch them to clients.
- On a predefined period (configurable) the server broadcasts a message to all the clients to determine their number and statuses. This is helpful when a new client has been started or stopped since the latest broadcasting request. The clients that sends no response for a long time is marked as not responding (such clients do not participate in conversion until the server receives the response from them; if the task has been assigned to such a client it will be reassigned). The Client also can report a busy status (with the task information attached) or free.
- The approach when the server broadcasts a special message for the client to respond with its status allows us to add and remove clients on the fly providing additional facility to scale the system.
- Clients are rather passive in communications. They only send a message on the conversion start, completion and a status message.
- Load balancing in the system is quite simple. As far as we use FFmpeg for conversion, we cannot influence the conversion process at all, so we just select the first free client and assign the task to it. If there are no free servers the task waits until new client is started (the client will be added to the server automatically) or one of the existing servers will become free.
The video conversion system provides some data transfer objects, events and interfaces for use in external system. They are:
- Video Conversion Info. This is a data transfer object (DTO) that contains the information about the conversion to be performed, including the original video resource ID, converted video resource ID and storage type for the conversion system to correctly choose the storage connector. This DTO is created by the invoking system. It allocates all the resources and sends it to the video conversion dispatcher server.
- A set of events including Video Conversion Started Event (fired when the client starts conversion), Video Conversion Finished Event (fired when the client finishes conversion), Video Conversion Requested Event (fired by the external system when it needs to perform conversion) and Video Conversion Task Accepted Event (fired by the dispatcher server when the task is received and saved to queue).
- Also, the Resource Storage Connector Interface is provided for the end users to implement necessary connectors. We use Amazon S3 in the system.
Conclusion
The described video conversion system is actually a real live application. The system architecture and used algorithms and approaches are exactly the same as described here.
We will be releasing an article soon on how to build FFmpeg from SVN with a rich variety of supported formats.
Do you like the article and want us to develop your project? Feel free to contact us here!
This entry was posted on Thursday, December 18th, 2008 at 9:38 am and is filed under Video.
