唉,爲了在上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格式的分包上,解碼部分,等新開發板拿到手,才知道具體如何進行了.