Mplayer改造备忘录
转载时请注明出处：http://blog.csdn.net/absurd
Mplayer可能是Linux下功能最强大的多媒体播放器，它支持大量的多媒体文件格式，像常见的音频文件如mp3/wav/mid，常见的视频文件如avi/vcd/dvd/rm等等，各种视频编/解码方式也是应有尽有。它对音频和视频输出方式也有比较全面的支持，重要的是它支持我们需要的OSS音频输出和DirectFB视频输出。它在性能上有比较优异的表现，占用空间(磁盘和内存)也在可以接受的范围内。所以我们选择它作为我们平台上的多媒体播放工具。
但是我们不能直接拿过来用，需要对它进行改造，原因在于：
1. 它的界面代码是用基于X Window的GTK+写的，而且多处直接调用了X Window的函数。而我们的GTK+是基于DirectFB的，要移植过来比较困难。同时由于我们要求整个系统的风格统一，即使能够容易的移植过来，仍然要对其界面做较大改动。
2. 智能手机平台中，播放音/视频文件的地方不只一处。像来电时要播放来电铃音、来短信时要播放短信铃音、闹钟要播放闹铃、数码相机要回放视频录像、多媒体播放器要播放多媒体文件，通话本身也要占用音频设备(speaker/mic)。为了避免冲突，要对播放动作统一管理，让这些应用程序串行的去访问音/视频设备。
3. 仅仅简单的串行化对音/视频设备的访问还不够。一方面是它们的优先级不一样，你不能指望等一首mp3播放完了，才去播放来电铃音; 而在打电话时也不能播放mp3。另外一方面，它们被中断后的行为也不一样，像短信铃音被来电铃音中断，短信铃音就结束了。而mp3播放被中断了，可能只是暂停下来。
4. 播放本身的行为也不一样。像短信铃音只播放一遍，而来电铃音可能循环的播放直到超时为止。来电铃音也可能要先振动，再播放铃音，或者反之，或者只振动等等，依据设置而定。
基于以上这些原因，我们要对Mplayer进行改造。
所幸的是Mplayer的引擎与界面之间的耦合很松，它们通过一个命令队列进行通信，这使得摒弃原生的界面代码非常容易。尽管我们可以把我们的代码加入Mplayer中，也通过命令队列来控制引擎的工作。但是Mplayer本身比较复杂，把我们的代码加入其中，如果我们的代码不太稳定，调试会比较困难。
Mplayer还提供了一种通过stdin/stdout的方式与引擎通信，我们选择了这种通信方式。这样做的好处是隔离了复杂度，对程序的稳定性大有帮助。它的本身提供的功能比较弱，我们需要对其命令集进行扩展，这是很简单的事情。
当然我们对它的改造不仅仅是换一个界面，为了让所有动作串行化，需要把它改造成为C/S架构的。所有应用程序通过向服务器发送请求，来完成播放任务。服务器负责对各播放动作按优先级进行调度，并记录各种状态，最后把仲裁后的结果发给Mplayer执行。Mplayer作为服务器的一个子进程运行，两者之间通过双向管道通信。
多媒体播放器的界面部分作为一个普通客户端应用程序运行，和其它如电话/短信等客户端应用程序没有什么差别。我们的实现和传统的C/S架构仍有不同，服务器并不一定完全处于被状态，等待客户端的请求，它在适当的时候可能会触发一些事件，这些事件主动上报给客户端。比如多媒体播放器被来电中断了，服务器要通知多媒体播放器暂停计时; 播放出错了,要通知多媒体播放器显示出错信息等等。事件上报采用注册机制，谁注册了就发给谁，保持服务器与客户端的松耦合关系。
服务器是完全独立的，它不关心是谁在播放，播放什么内容，而是完全按照客户端指定的参数行事。为了减化应用程序的调用，大部分参数，如优先级和播放时间限制等等，是从配置信息中获取的，应用程序通常不用关心。这些工作在客户端封装API函数中完成，这样即保证服务器的独立性，又保证了客户端的易用性。
客户端与服务器端之间的通信机制采用DBUS，DBUS采用本地socket作为承载层。所以这种改造比较容易实现，而且性能不会受到太大的影响。
改造后的架构如图所示：
~~~end~~~