Android 1.5 告别篇

     唉,为了在上Android 2.2后能够轻松一些,花了近两个月时间在1.5上完善前一个项目的移植,虽然新项目的开发板和系统版本都换了,但是OpenCore的框架,OpenMAX的框架还是不变的...不过,Android 2.2已经开始使用stagefright了,Android 2.3 就完全用stagefright替换掉OpenCore了,怎么想,都觉得这段时间的工作没有太多的成就.

     Android 1.5虽然做了libopencoremp4.so,但是其实他只支持.3gp的本地文件播放.这里讲一下.3gp和.mp4文件的区别,网上总有人说.3gp和.mp4只是文件封装类型,里面的数据流都是一样的,我觉得这种说法实在是不负责任,从我测试的结果来看,用同一个源,在屏幕大小,帧率,比特率都设置相同的情况下,通过格式工厂(FormatFactory)转换出来的.3gp的mpeg4(divx)视频流和.mp4的mpeg4(divx)的视频流,文件大小上就有2KB的差距,并且在imx27自带的vpu硬解上验证后,mp4格式的mpeg4视频流能够正常识别并解码,而3gp的却不行;另外mpeg4(Xvid)的视频流,vpu也是可以解的,但是格式工厂转的3gp只支持mpeg4(Divx)/H263+AMR,所以无法验证3gp的mpeg4(Xvid)通过vpu是否能解. 后期的工作,因项目需要,转向H264方向,Android 1.5虽然在OpenMax的代码里有avc_h264的解码,但是并未生成库,所以我想还是在Android 2.2上研究其h264的编解码吧.

     在测试3gp与mp4的mpeg4视频流的时候,还遇到一个有趣的问题,文件源的帧率为29.97,当转换出的视频流帧率为18或12等小于原帧率的时候,在vpu上播放,显示画面居然是"快动作",当我把帧率设为60后,播放画面又变慢了接近1倍;而我直接使用射手播放器,分别放这三个视频,感觉却基本没有变化...靠,这不是违背常理了么? 后来仔细想想,其实这是正常的,帧率这个属性只在上层分包的时候用到,而对于解码的部分,解码器本身是时间无关的,它并不会去关心这个视频会播放多少时间,不会去做时间同步,再者解码能力是固定,特别像vpu这种bitstream形式的解码器,每次只解固定大小的数据流,而单位大小数据流中的帧的数量是相对固定的,帧率越低,帧与帧之间的动作跨度就越大,这样单位时间能解出的画面的变化就越大,那么单位时间显示的动作变化就越大,这样在帧率低的情况下,播放的画面自然就越"快",反之亦然;而从时间上看,vpu的解码能力是固定的,也就是其在单位时间内解出的帧的数量是固定的,那么帧率越低,整个视频流包含的帧数就越少,所以对于vpu来说,所花费的时间就越少,这样播放的速度就快,反之亦然!

     这两日,初步摸索了一下Froyo的代码,stagefright已经开始使用,但是其源码,实在是不敢恭维,和OpenCore比较,其美观度大打折扣,估计3.0会有很大改观.这里推荐两篇文章,算是前人摸索出的经验：

      http://blog.chinaunix.net/u1/57901/showart_2423206.html

      http://blog.chinaunix.net/u2/61880/showart_2339481.html

      这两篇基本囊括了stagefright的主要框架和调用,并且将其和Opencore的区别也理的很清楚了,帮助很大.对于硬解码来说,主要工作还是在OMX这一块,对于上层是使用StageFrightPlayer来调用还是使用PVPlayer来调用,那就不关我事咯=.=

      不过现在的难点,估计是在如何进行H264格式的分包上,解码部分,等新开发板拿到手,才知道具体如何进行了.