在S3C2410嵌入式开发平台上移植了几款linux媒体播放器,感觉播放效果不是很理想,
|
-- 作者:meinengda -- 发布时间:2004-12-3 18:00:46 -- 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视频的效果吧! |
联系客服