經典必看，從入門到精通的android視頻下載!通往名企，從學習android視頻下載開始!達內android培訓(xun)技術專家總(zong)結了android下播放器視(shi)頻輸出方法總(zong)結。

在Android下輸出視(shi)頻(pin)畫(hua)面(mian),有(you)很多種方法,每個(ge)都(dou)有(you)自(zi)己(ji)的特點(dian),比如將視(shi)頻(pin)數(shu)據送(song)回到java層然后用lockCanvas畫(hua)出來這(zhe)種方法的特點(dian)就是慢.

上(shang)面這個完全不值得提倡,視(shi)頻數據從(cong)native層傳到jni層很耗時間.

開發基于(yu)ffmpeg的播(bo)放器(qi)時,可(ke)以使(shi)用ffmpeg的各種軟解碼器(qi),也可(ke)以使(shi)用android帶的OMXCodec解碼器(qi),OMXCodec解碼器(qi)是對OMX的一個(ge)封裝.其(qi)中ffmpeg解碼器(qi)主要(yao)輸出YUV420P的幀,而OMXCodec解碼器(qi)輸出的格(ge)式就多(duo)樣化,因具體的平(ping)臺不同(tong)(tong)而不同(tong)(tong).

使用OMXCodec解碼器(qi)解出(chu)來的(de)視頻,可(ke)以讓它(ta)自己輸(shu)出(chu),只(zhi)要在打(da)開解碼器(qi)的(de)時候給它(ta)傳個ANativeWindow:

解碼(ma)函數read出來的是MediaBuffer,其實是GraphicBuffer,不需要關心它(ta)(ta)(ta)的格式,只需要queueBuffer它(ta)(ta)(ta),然后設(she)置好(hao)render完成,并release它(ta)(ta)(ta):

值(zhi)得說明(ming)的(de)(de)是(shi)(shi),在(zai)創建OMXCodec的(de)(de)時候,也可以(yi)傳入kKeyColorFormat來指(zhi)定成(cheng)想要的(de)(de)格式,但是(shi)(shi)不(bu)幸(xing)的(de)(de)是(shi)(shi),有時候并不(bu)會支持你想要的(de)(de), 比(bi)如有的(de)(de)手機就不(bu)支持HAL_PIXEL_FORMAT_YV12,而是(shi)(shi)使用了一種內部(bu)格式,糾結吧,所以(yi)還是(shi)(shi)讓它(ta)自己(ji)輸出比(bi)較好.

在(zai)(zai)采用ffmpeg解(jie)碼器時,目前我所(suo)知(zhi)道的,輸出YUV420P有(you)兩種方法,一種是通過(guo)(guo)(guo)Lock ANativeWindow寫入YUV數(shu)據,一種是通過(guo)(guo)(guo)opengles在(zai)(zai)片斷著色器中將YUV數(shu)據通過(guo)(guo)(guo)公式(shi)轉(zhuan)換(huan)成(cheng)RGB輸出.

參考AwesomePlayer.cpp,會發現(xian)有個SoftwareRenderer的東東,這個類可以輸(shu)出(chu) HAL_PIXEL_FORMAT_YV12, YUV420P->YV12的轉換(huan)(huan)其(qi)實(shi)(shi)很(hen)簡(jian)單,就是(shi)UV分(fen)量的存儲位置不一樣,拷(kao)貝時變換(huan)(huan)下就可以了(le).這個是(shi)Lock ANativeWindow的方(fang)法(fa).里面還(huan)有一個AwesomeNativeWindowRenderer,其(qi)實(shi)(shi)就是(shi)上面提(ti)到的讓OMXCodec自己去輸(shu)出(chu)視頻(pin)的方(fang)法(fa).

我在實(shi)踐中發現,有些手(shou)機的(de)(de)SoftwareRenderer沒有處理好(hao),特別是刷第三(san)方(fang)ROM的(de)(de)時候,會花屏,所(suo)以需要自(zi)己(ji)手(shou)動(dong)從SoftwareRenderer.cpp中提(ti)取(qu)代碼,其實(shi)就是操作(zuo)ANativeWindow的(de)(de)一些函數:

上面的代(dai)碼(ma)省略了很多,只(zhi)是(shi)一個基(ji)本的流程.android的源碼(ma)中還有一個gl2_yuvtex.cpp,里面有輸出YUV的方(fang)(fang)法(fa),是(shi)采用了初始化 egl和opengles,然后(hou)創(chuang)建GraphicBuffer寫(xie)入數據,跟據GraphicBuffer創(chuang)建EGLImageKHR,最后(hou)調用 opengles的擴(kuo)展GL_OES_EGL_image_external 輸出YUV,這種方(fang)(fang)法(fa)我也把(ba)它歸屬于LockAnativeWindow方(fang)(fang)法(fa),因為這個方(fang)(fang)法(fa)就是(shi)上面的底(di)層實(shi)現.

Lock AnativeWindow方法(fa)優點是(shi)(shi)底層有(you)平(ping)臺(tai)實現,非常(chang)快,缺點是(shi)(shi),在lockBuffer之后(hou),我們(men)可以拿到y分量(liang)的(de)行字節數,即stride,但是(shi)(shi)沒有(you)辦法(fa)獲(huo)取到uv分量(liang)的(de)stride,跟據一(yi)般(ban)情況(kuang)下應該是(shi)(shi)y_stride/2然后(hou)按16字節對齊,但是(shi)(shi)有(you)些(xie)廠商不按常(chang)理出牌,這(zhe)個值不一(yi)定是(shi)(shi)這(zhe)樣的(de),導致結果就是(shi)(shi)花屏或者內存(cun)Abort,所以得適配手機(ji),麻煩!

再(zai)來說說使(shi)用(yong)opengles將(jiang)YUV轉(zhuan)換成RGB輸出的方(fang)法,這(zhe)種(zhong)方(fang)法很早(zao)有就(jiu)人使(shi)用(yong)了(le),最早(zao)的時候就(jiu)使(shi)用(yong)軟件(jian)將(jiang)YUV轉(zhuan)換成RGB輸出,但(dan)是(shi)(shi)(shi)效率太低了(le),于是(shi)(shi)(shi)大(da)神們將(jiang)眼光投向(xiang)了(le)opengles的可(ke)編程片段著(zhu)色器(qi),將(jiang)YUV的轉(zhuan)換放到著(zhu)色器(qi)去做(zuo),硬件(jian)處理(li)是(shi)(shi)(shi)非常快的,這(zhe)樣就(jiu)大(da)大(da)提高了(le)效率,具體的做(zuo)法是(shi)(shi)(shi):初始(shi)化EGL(參考gl2_yuvtex.cpp)->創建(jian)著(zhu)色器(qi)程序并編譯(yi)連接->創建(jian)并上傳紋(wen)理(li)->畫三角形(xing).下面(mian)是(shi)(shi)(shi)頂點和紋(wen)理(li)坐標(biao),著(zhu)色器(qi)代碼:

要(yao)注意(yi)的(de)(de)(de)是,EGLContex和(he)線程(cheng)相關,是opengles的(de)(de)(de)狀態(tai)機(ji)(ji).使用這(zhe)種方法要(yao)注意(yi),在有(you)些老(lao)的(de)(de)(de)機(ji)(ji)器上,使用glTexImage2D或 glTexSubImage2D更新(xin)紋理(li)時非(fei)常(chang)慢(man),一幀720x576的(de)(de)(de)圖片可達(da)80ms,這(zhe)樣的(de)(de)(de)話,就不要(yao)用這(zhe)種方法渲染了,除(chu)非(fei)你(ni)可以舍棄清晰度,在新(xin)的(de)(de)(de)硬件上,一般(ban)都能在幾個(ge)ms內.

使(shi)(shi)用opengles來(lai)渲(xuan)染(ran),還有(you)其他(ta)的方法,就是使(shi)(shi)用OES擴(kuo)展,在安卓(zhuo)源碼里有(you)例子gl2_yuv.cpp,可以參考使(shi)(shi)用,使(shi)(shi)用 glEGLImageTargetTexture2DOES上傳紋理沒有(you)問題,一般都非常快,但是兼容性不好,原因和使(shi)(shi)用nativewindow直(zhi)接(jie)渲(xuan)染(ran)是相同(tong)的.

經(jing)典(dian)必看android視頻下(xia)載(zai)教程，從入門到精通的android視頻下(xia)載(zai)!