基于Mplayer的嵌入式流媒体播放器的设计与实现*

闻连臣，段晓辉，郭跃超，张 振

（北京大学 无线通信与信号处理研究中心，北京 100871）

0 引言

多媒体的呈现方式从本地播放、下载存储播放逐步发展到流式播放[1]。流媒体融合了网络和多媒体编解码等技术，虽然在PC领域上的应用已比较成熟，但是在嵌入式领域，仍有着很大的开发空间。文中提到的向Mplayer的解码库中添加S3C6410的多媒体编解码模块MFC(multi format codec)[2]，具有很强的应用价值。

本设计的平台是HINOC手持测试仪。HINOC[3](High performance Network Over Coax)是“三网融合”中的从光纤网到用户的一个传输方案，如图1所示。头端设备(HINOC Brige，HB)对多个终端设备(HINOC Modem，HM)进行管理。

HINOC手持测试仪的主要功能是不仅有 HM的功能，还能协助工程人员进行故障定位。图2和图3显示了其硬件和软件结构。

工作人员通过流式传输可以观看远程业务视频，而且能直观地验证网络的底层是否连通。

1 需求分析

图1 HINOC网络结构图

本系统采用了ARM-Linux，处理器是基于ARM1176-JZF-S的S3C6410，播放器是Linux系统上最优秀的播放器之一 Mplayer[4]，结构如图 4所示。将S3C6410的MFC加入Mplayer的解码库中，通过移植协议栈 live555，Mplayer支持流式传输。

图2 手持测试仪硬件架构

图3 手持测试仪软件架构

图4 Mplayer结构图

研究发现为Mplayer添加解码器的方法有多种，总结如表1所示，本文采用了第3个方案。

表1 Mplayer添加解码器的方法

2 硬件模块

S3C6410这款16/32位的微处理器，主频可达667 MHz，主处理器之外集成了MFC，如图5所示，能支持MPEG4/H.263/H.264/VC1的编解码，解码性能可达 720×480 30 f/s或者720×576 25 f/s。S3C6410还支持实时视频会议等功能。

MFC由BIT和视频编解码器组成。BIT处理器对数据流进行分解，一方面与主处理器通信来协调整个流程，另一方面控制视频解码器进行解码。BIT处理器主要包括：BIT处理器内核、程序内存、数据内存、与主处理器进行交互的接口。视频编解码器受BIT处理器的控制来完成解码，内部包含宏块控制器、预测、块效应滤波、重构等子模块。

解码时需对中间运算缓存，图5中的外部存储器提供了这些空间，可分为BIT处理器缓冲和数据缓冲，如图6和图7。代码缓冲区的主要作用是存储启动代码。工作缓存区缓存中间结果，其配合流缓冲区进行工作。参数缓存区主要存帧缓冲的地址。主处理器对流缓冲区进行写操作，BIT处理器对其进行读操作，其缓存的是待解码的数据。帧缓冲区存储的是解码后的YUV数据。

图5 S3C6410中的主处理器和MFC关系图

图6 BIT缓冲区存储结构图

图7 数据缓冲区存储结构图

3 软件模块

3.1 Mplayer结构分析

由图4知，Mplayer的结构是模块化的，各个模块在mplayer.c的协同下工作。下面对其简要分析。

(1)stream.c所在的输入层，根据读入方式来调用文件，正如图 4中 stream_*.c所示， 如 strean_file.c、stream_ftp.c、stream_netstream.c等。这个过程通过查询、跳转、缓存等来完成。

(2)demuxer.c所在的音视频分流层。demuxer.c是一个基本的框架，对于具体的流如mpeg-es、avi、asf等，都有相应的 demux_*.c。

(3)解码。解码器由libmpcodecs/*和分离的库组成，如liba52、libmpeg2等。Mplayer.c通过dec_audio.c和dec_video.c对流头sh_audio_t和sh_video_t中的格式进行判断来选择解码器。通过dec_audo.c来调用ad_*.c；通过dec_video.c来调用vd_*.c，即视频解码器。解码之后还需对视频后期处理，即需用到视频滤波器vf_*.c。

(4)显示。video_out.c和 audio_out.c调用不同的显示模块，如 vo_directfb.c、vo_fbdev.c等。

3.2 调用MFC的API

应用程序调用MFC的API，现在对其进行介绍，其中涉及了Mplayer中的函数：SsbSipH264DecodeInit():解码实例的创建，即初始化；SsbSipH264DecodeGetInBuf():获取输入缓存区的地址，待解码数据从这里读取；

以上函数作为初始化，需要在编写的vd_*.c中的初始化函数int init(sh_video_t*sh)中调用；

SsbSipH264DecodeGetConfig()：在 vd_*.c 的 mp_image_t*decode(sh_video_t*sh,void*data,int len,int flags)中两处被调用：其一是为了获得视频流的信息，如分辨率的长、宽等，只能在 mp_image_t*decode()第一次执行时调用，否则因时间开销而影响视频的显示，调用的格式为：Ssb-SipH264DecodeGetConfig(handle，H264_DEC_GETCONF_STREAMINFO,&stream_info)；其二获得输出地址，格式为：SsbSipH264DecodeGetConfig(handle，H264_DEC_GETCONF_PHYADDR_FRAM_BUF，pYUVBuf)。其源码结构如下：

SsbSipH264DecodeExe():在函数mp_image_t*decode(sh_video_t*sh,void*data,int len,int flags)中被调用的解码函数。

SsbSipH264DecodeDeInit():最后对硬件资源的释放，在 void uninit(sh_video_t*sh)中调用。

4 实现流程

首先，将live555源码中live中的文件config.armlinux里的CROSS_COMPILE改为CROSS_COMPILE？=arm-linux-；然后依次执行./genMakefile armlinux、make；最后，将编译好的目录复制到/usr/local/lib下。其次完成Mplayer软解码的移植[5]。

下面介绍如何将MFC添加到Mplayer中，这是本文的关键。

首先，在文件etc/codecs.conf中增加解码器实体。codecs.conf是对音视频解码器的声明，其关键字是固定的，如videocodec说明是视频解码器。

其次，编写解码器vd_mfc264.c。Mplayer定义了一个vd_functions_t型结构体。原型定义在vd.h中，如下所示：

(1)int init(sh_video_t*sh)完成解码之前的初始化，包括MFC的启动以及一些API句柄的获得；

(2)void uninit(sh_video_t*sh)是结束函数，完成解码后的资源的释放；

(3)mp_image_t*decode(sh_video_t*sh，void*data，int len,int flags)完成解码。读取到的待解码数据填充到图7中的流缓冲区，通过与工作缓冲区的交互，将解码后的YUV数据放入图7中的帧缓冲区。

Mplayer的视频解码器都被libmpcodec目录下vd.c中的指针数组mpcodecs_vd_drivers所管理,因此增加：

(4)int control(sh_video_t*sh,int cmd,void*arg,...)的作用是控制视频的解码和显示，这个函数是为保障音视频的同步。

再次，编写显示模块vo_mfcfb.c。S3C6410的MFC可以对解码后的数据进行缩放、滤波等后期处理。在Mplayer的源码中，是把数据传给 video_out.c，然后通过调用vo_fbdev.c来使用framebuffer显示。在硬解码中，由于存储解码后的数据的物理地址，并不是在处理器的缓存中，而是在外部存储器中，这导致Mplayer的vo_fbdev.c无法获得缓存地址。解决办法就是编写vo_mfcfb.c，它完成将帧缓存区中的YUV数据进行后期处理并显示。整个流程如图4所示。将vo_mfcfb.c加入到video_out.c中，不再具体叙述。

最后，修改 Mplayer下的相关 Makefile，将编写的两个源文件和相应的头文件编译成静态链接库。

5 系统测试与分析

现在用一台PC运行live555来充当流媒体服务器，通过搭建HB，来验证手持测试仪上的流媒体播放功能。

通过软件Media Coder将测试视频转换成编码帧率25 f/s、分辨率720×480和不同的编码码率的视频。图8从播放帧率角度显示了对比的解码性能。

图8 软硬解码性能对比

分辨率为720×480、编码帧率为25 f/s的 H.264视频,在Arm11平台下，要想达到人眼视觉可以接受的流畅性，Mplayer的软解只能达到的码率为500 kb/s，而使用MFC硬解可以高达3 500 kb/s，比软解码提高约3 000 kb/s。

6 结论

流媒体最耗资源的是视频的解码，本文利用支持live555的Mplayer的成熟框架，将S3C6410的MFC添加到Mplayer的解码库中，不仅可以降低系统对CPU、内存等硬件资源的要求，而且大大提高了视频质量，这体现了嵌入式应遵循的高性价比理念。而Mplayer在嵌入式领域的应用，通常是对已有软件解码器进行算法的优化，或者直接进行移植应用[5]，本文的开发方案为相关应用提供了很好的借鉴。

[1]CONKLIN G J，GREENBAUM G S，LILLEVOLD K O，et al.Video coding for streaming media delivery on the Internet[J].IEEE Transactions on Circuits And Systems for Video Technology，2001，11(3)：269-281.

[2]Samsung Electronics.S3C6410X RISC microprocessor user′s Manual[Z].2008.

[3]国家广播电影电视总局广播科学研究院，北京大学，西安电子科技大学，上海明波通信技术股份有限公司，上海未来宽带技术及应用工程研究中心有限公司.高性能同轴电缆接入技术(HINOC)研究与实现论文集[M].辽宁：辽宁石油化工大学，2011.

[4]Mplayer.The online documentation of Mplayer[EB/OL].(2013-05-01)[2014-06-30].http：//www.mplayerhq.hu/DOCS/HTML/zh_CN/intro.html.

[5]慈文彦，何君，朱明祥.基于ARM处理器的流媒体播放器客户端的构建[J].信息技术，2012(1)：106-112.