加入收藏 | 设为首页 | 会员中心 | 我要投稿 | RSSRSS-巴斯仪表网
您当前的位置:首页 > 电子发烧 > 单片机学习

mplayer在S3C2410上的移植

时间:2013-09-08  来源:123485.com  作者:9stone

        在S3C2410嵌入式开发平台上移植了几款linux媒体播放器,感觉播放效果不是很理想,320x240分辨率下的视频播放也不是很流畅,难道200M主频的速度就只能这样了?我开始有点失望了。上个月,当mplayer摘取了年度Linux   world   博览会“新媒体”大奖的消息传来,激发了我再次移植mplayer   到2410的决心,尽管前几次移植的结果都不是很成功。   

        以前我刚开始在linux下做桌面开发时,就听说mplayer号称linux史上功能最强的媒体播放器,它在桌面上安装起来很方便,简单的 configure,make一下,就装好了,和QT的GUI配合,界面还是蛮友好的。Mplayer对媒体格式的广泛支持,以及丰富的后期处理滤镜给我留下深刻印象,最新的版本更支持DIVX,H.264,MPEG4等最新的流媒体格式,可以实时在线播放视频流,这么优秀的播放软件把它移植到嵌入式设备上该多好啊! 
  
        公司里有一块FS2410的开发板,深圳优龙的板子,CPU是三星的S3C2410,arm9的内核,板子做工很精细,以前一直都用它来做开发,买的时候配的是10.4寸的sharp大屏,640X480的分辨率,不错,这样就可以测试在640X480分辨率下的视频播放速度了。硬件平台的问题解决了,下一步下载最新的mplayer源代码包,毕竟最新的源代码包才有最新的功能,当然了BUG估计也是不少的。打开mplayer的官方网站
http://www.mplayerhq.hu的主页,可以看到“download”这个链接,点击一下,进入下载页面,在该页面里可以看到“daily   CVS   snapshot   source”的下载部分,这部分链接都指向了每天提交到CVS服务器里最新的mplayer源代码包,鼠标点击一下开始下载! 
  
  
  1.   开始编译     
  下载下来的源代码一般都叫MPlayer-current.tar.bz2的名字,好,开始解包,在命令行下敲以下的命令 
  
  bunzip2     MPlayer-current.tar.bz2     |     tar     xv     – 
  
    查看解包出来的README和INSTALL文件,看看有没有安装时特别声明的东西,这是我的习惯,因为同一个软件的不同版本,安装的方法有时并不一样。然后输入./configure   --help看看有没有多出或减少什么选项,还好,没什么变化,于是把以前配置mplayer的命令拿出来,复制,粘贴在命令行上:     
   
  ./configure   --cc=arm-linux-gcc   --target=arm-armv4-linux   --enable-static   --prefix=/tmp   /mplayer   --disable-win32     --disable-dvdread   --enable-fbdev   --disable-mencoder   --disable-live   --disable-mp3lib   --enable-mad   --enable-libavcodec     --language=zh_CN     
   
  配置完毕,开始跨平台编译:       make 
  
  眼睛盯着编译器反馈的每一个信息,老是担心在哪出错,mplayer的源代码太庞大了,又使用到不少第三方的库,谁能保证编译不出问题呢.果然,没编译几下,就停下来了,说什么codec-cfg无法运行,产生不了某某头文件。检查了一下,发现codec-cfg这个可执行文件是最先编译产生的一个文件,这个文件是存在的啊,怎么会执行不了呢?于是手动执行了一下,系统提示“cannot   execute   binary   file”,突然想起来,codec-cfg是按跨平台方式编译的啊,产生的是arm的代码,当然不能在x86上执行了,那就先用不用跨平台编译的方式,先把mplayer编译成x86的代码,于是重新配置,简单的   ./configure,   make,然后将生成的 codec-cfg改名为codec-cfg.x86。然后再按跨平台方式配置,编译,等编译器出现错误停止编译时,将codec-cfg.x86该名为codec-cfg,再make,OK,编译就可以继续进行了。 
  
      在编译期间,还出现了几处错误,都是头文件引用的问题,特别提醒大家的是,在libmpcodecs和libavcodec这两个目录下,有一个疏漏,就是这两个目录的源文件都以  #incude   “config.h”   的方式引用头文件“config.h”,但是在这两个目录下并不存在该头文件“config.h”,这些源文件实际是期望引用mplayer安装包根目录下的“config.h”头文件,因此我们需要在libmpcodecs和libavcodec这两个目录下手动建立一个名为config.h的链接并指向mplayer安装包根目录下的“config.h”头文件,建立方法     
   
  $>   cd       libmpcodecs     
  $>   ln     –s     ../config.h     config.h       
  $>   cd     ../     
  $>   cd     libavcodec     
  $>     ln     –s     ../config.h     config.h 
  
  经过几次的编辑修改,终于成功完成对mplayer的编译链接,一看mplayer文件的大小,10M,z这也太太夸张了吧,我还没编译成debug的呢。到目前为止这算是成功的第一步了。

2.开始调试     
        编译出来的代码能正常的在FS2410上跑吗?心中还是有许多疑问。给板子上电,然后用自己编写的一个网络传输工具将代码传到板子的ramdisk,接着再传上一个10M左右的视频,好了,先不带参数运行mplayer,不错,中文的帮助信息弹出来了,说明程序基本编译对了,这时输入命令   ./mplayer     matrix.mpg   ,   眼睛直盯着屏幕,期待着画面的出现,可惜,在出现了一些视频剪辑的反馈信息后,程序再也不动了,没办法,按CTRL+C结束程序,然后就提示出现段错误。以前听说有linux嵌入式的爱好者移植时也出现这样的错误,但是如果不播放声音时,图像可以出现,于是输入命令   ./mplayer     -nosound     matrix.mpg,这时画面出来了,这个320x240大小的从网上下载的视频,播放起来相当流畅,好像比平时看的影碟机解码速度还快,那当然了,毕竟是320x240大小,又没声音解码的。 
  
      声音这块不解决,当然是不能说移植成功的,因为mplayer还支持那么多格式的音频解码。但是问题究竟出在哪里呢?用排除法吧!找一个未经任何音频压缩的WAV音频文件,其时就是PCM文件,上传到ramdisk,然后用mplayer播放,还是出现一样的问题,程序死了。好了,这就说明问题并非出现在音频解码部分,极有可能出现在音频流的播放部分。现在市面上大多数的嵌入式开发板的音频驱动是oss规范的驱动,以前自己做过oss的编程,对这块还是比较熟悉。于是开始查看mpalyer,c源文件,看看它是如何实现音频流播放的, 
  
      在音频播放部分它使用到了libao2库的音频播放/控制模块,通过进一步查看ao_oss.c源代码进一步获知mplayer是如何与音频的linux 驱动工作的。这一步弄清楚后,重新编译mplayer,打开debug选项,打开调试字符串输出,并在音频播放处设置多处断点,并加上printf语句输出一些变量内容,最终发现在调用ao_oss.c的play()函数时出现除零出错, 
  
      这个问题产生的根源最终追溯到音频的驱动部分。现在大部分的嵌入式板子都使用菲利普uda1341音频芯片,因而也都使用了相同一个音频驱动,即MIZI 公司拥有版权的linux   uda1341音频驱动,这个驱动基本上符合了oss的规范,但是当使用到多段DMA音频数据传输时,出现了一个问题,即DMA缓冲的建立发生在第一次调用write()函数将音频数据传送到设备描述符的时候,然而oss驱动的调用者通常要在打开音频设备描述时候,就期望获取DMA缓冲的信息,然而因为缓冲尚未建立,因而返回缓冲大小为0这个结果。 
  
      解决的办法是在音频驱动源码的smdk2410_audio_open()函数体,加上如下一段代码, 
  
  if   (!output_stream   .buffers   &&   audio_setup_buf(&output_stream))     
                                      return   -ENOMEM; 
  
  添加的位置具体见以下代码的粗体部分:     
   
  static   int   smdk2410_audio_open(struct   inode   *inode,   struct   file   *file)     
  {     
                int   cold   =   !audio_active;    
   
                DPRINTK("audio_open/n");     
   
                if   ((file->f_flags   &   O_ACCMODE)   ==   O_RDONLY)   { 
  
                              if   (audio_rd_refcount   ||   audio_wr_refcount) 
  
                                            return   -EBUSY; 
  
                              audio_rd_refcount++; 
  
                }   else   if   ((file->f_flags   &   O_ACCMODE)   ==   O_WRONLY)   { 
  
                              if   (audio_wr_refcount) 
  
                                            return   -EBUSY; 
  
                              audio_wr_refcount++; 
  
                }   else   if   ((file->f_flags   &   O_ACCMODE)   ==   O_RDWR)   { 
  
                              if   (audio_rd_refcount   ||   audio_wr_refcount) 
  
                                            return   -EBUSY; 
  
                              audio_rd_refcount++; 
  
                              audio_wr_refcount++; 
  
                }   else 
  
                              return   -EINVAL;     
   
              if   (cold)   { 
  
                              audio_rate   =   AUDIO_RATE_DEFAULT; 
  
                              audio_channels   =   AUDIO_CHANNELS_DEFAULT; 
  
                              audio_fragsize   =   AUDIO_FRAGSIZE_DEFAULT; 
  
                              audio_nbfrags   =   AUDIO_NBFRAGS_DEFAULT; 
  
                              if   ((file->f_mode   &   FMODE_WRITE)){ 
  
                                                          init_s3c2410_iis_bus_tx(); 
  
                                                          audio_clear_buf(&output_stream); 
  
                                //   加上以下这行代码        
                                if   (!output_stream   .buffers   &&   audio_setup_buf(&output_stream))     
                                      return   -ENOMEM;
     
                              } 
  
                              if   ((file->f_mode   &   FMODE_READ)){ 
  
                                                          init_s3c2410_iis_bus_rx(); 
  
                                                          audio_clear_buf(&input_stream); 
  
                              } 
  
                }     
   
                MOD_INC_USE_COUNT;  
   
                return   0; 
  
  }     
   
  改完驱动后,重新编译内核。     
   
  3.   结论     
      mplayer因为直接使用缓冲帧,或者使用别的什么优化的算法,使得在ARM   S3C2410视频播放速度得到显著提高,至少在320x240大小,解压mpeg1或2标准的视频时速度是相当流畅的,但是mpeg4解码速度仍显不足。Arm   s3c2410的cpu属于精简指令,定点计算,无MMX,无硬件浮点计算,因而对大尺寸多媒体编解码的能力仍显不足。业界的解决办法是在CPU外增加硬编解码的DSP,或者在SOC内增加协处理器以加强这方面的功能。  
   
  
后记     
      在得知优龙又有新的开发板-xscale   PXA255面世后,我决定用将移植好的mplayer拿给他们在板子上测试。mpeg4编码,画面大小为320x240的视频播放已经相当流畅,这也许就是那些市面上用PXA255   CPU做的PDA播放DIVX视频的效果吧!


分享到:
来顶一下
返回首页
返回首页
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表
栏目导航->单片机学习
  • 电子应用基础
  • 电源技术
  • 无线传输技术
  • 信号处理
  • PCB设计
  • EDA技术
  • 单片机学习
  • 电子工具设备
  • 技术文章
  • 精彩拆解欣赏
  • 推荐资讯
    使用普通运放的仪表放大器
    使用普通运放的仪表放
    3V与5V混合系统中逻辑器接口问题
    3V与5V混合系统中逻辑
    数字PID控制及其改进算法的应用
    数字PID控制及其改进
    恶劣环境下的高性价比AD信号处理数据采集系统
    恶劣环境下的高性价比
    栏目更新
    栏目热门