Mplayer transformation Memorandum

Mplayer transformation Memorandum

 

Please indicate the source when reprint: http://blog.csdn.net/absurd

 

Mplayer may be the most powerful multimedia player in Linux. It supports a large number of multimedia file formats, such as common audio files such as MP3, WAV, and mid, common video files, such as Avi, VCD, DVD, and RM, are also available in various video encoding/decoding methods. It also provides comprehensive support for audio and video output modes. What's important is that it supports the OSS audio output and directfb video output that we need. It has excellent performance, and the Occupied Space (disk and memory) is also within the acceptable range. Therefore, we chose it as a multimedia playback tool on our platform.

 

But we cannot use it directly. We need to modify it because:

1. Its interface code is written using GTK + based on X Window, and multiple functions of X Window are directly called. While our GTK + is based on directfb, it is difficult to transplant it. At the same time, because we need to unify the style of the entire system, even if it can be easily transplanted, we still need to make major changes to its interface.

 

2. On the smartphone platform, there are more than one place for playing audio/video files. For example, when you call a video, you need to play the ring tone of the incoming call, when you send a text message, when the alarm is triggered, when the digital camera wants to play back the video, and when a multimedia player wants to play a multimedia file, the call itself also occupies audio devices (SPEAKER/MIC ). To avoid conflicts, you must manage the playing actions in a unified manner so that these applications can access audio/video devices in sequence.

 

3. Simple serialization of audio/video device access is not enough. On the one hand, they have different priorities. You cannot expect to play the incoming call bell when an MP3 player finishes playing. You cannot play the MP3 when making a call. On the other hand, they behave differently after being interrupted. For example, if the SMS is interrupted by the incoming call, the text message will end. MP3 playback is interrupted, but it may be paused.

 

4. The playing behavior is also different. Like a text message, the bell sound is played only once, and the incoming call may be played cyclically until it times out. The incoming call tone may vibrate first, and then play the tone, or vice versa, or only vibrate, depending on the settings.

 

For these reasons, we need to transform mplayer.

 

Fortunately, the mplayer engine is loosely coupled with the interface, and they communicate through a command queue, which makes it easy to discard the Native Interface code. Although we can add our code to mplayer, we can also control the work of the engine through command queues. However, mplayer itself is complicated, and we add our code to it. If our code is not stable, debugging will be more difficult.

 

Mplayer also provides an engine communication method through stdin/stdout. The advantage of this is that complexity is isolated, which is of great help to program stability. Its functions are relatively weak. We need to expand its command set, which is very simple.

 

Of course, our transformation to it is not just a new interface, In order to serialize all actions, we need to transform it into a C/S architecture. All applications send requests to the server to complete the playback task. The server is responsible for scheduling the playback actions by priority, recording various statuses, and finally sending the results after arbitration to mplayer for execution. Mplayer runs as a sub-process of the server and communicates with each other through a two-way pipeline.

 

The Interface part of the multimedia player is used as a common client application to run programs, which is no different from other client applications such as phone/SMS. Our implementation is still different from the traditional C/S architecture, and the server is not necessarily in the state. Waiting for client requests, it may trigger some events when appropriate, these events are automatically reported to the client. For example, if a multimedia player is interrupted by a call, the server must notify the multimedia player to pause timing; if a playback error occurs, the server must notify the multimedia player to Display Error information. Event Reporting uses the registration mechanism. If you register an event, you can send it to the event provider to maintain the loose coupling between the server and the client.

 

The server is completely independent. It does not care who is playing or what content is played, but acts completely according to the parameters specified by the client. In order to reduce the call of applications, most parameters, such as priority and playback time restrictions, are obtained from the configuration information, and applications do not need to care about them. These tasks are completed in the encapsulated API functions of the client. This ensures the independence of the server and the ease of use of the client.

 

The communication mechanism between the client and the server uses accept, and accept uses local socket as the bearer layer. Therefore, this transformation is easy to implement, and the performance will not be greatly affected.

 

Transformed architecture:

~~~ End ~~~