android openmax hardware decoder 整合記錄

歡迎訪問個人blog： http://blog.thinkinside.me

關於android中openmax中hardware decoder的調用中，整合過程比較簡單。主要是對OMXCodec的封裝進行調用。

這裏記錄一下碰到的主要的問題：

1 現象：開關幾回後程序出現crash。

  幾臺設備都有此現象，內存大的機器能夠開關的次數多些，內存小的機器開關次數少。video尺寸小的可開關的次數多些，video尺寸小的可開關次數少。典型的內存泄露，並且與video decoder的解碼buffer有關。通過痛苦萬分的無數次打log，發現GraphicBuffer沒有釋放。

解決方案也簡單的能夠，從surface中申請的ANativewindow沒有被釋放。也就是

ANativeWindow_fromSurface()

....

....

ANativeWindow_release()

沒有成對調用。

2 現象：播放某些流或者DTV時出現解碼錯誤且再也不恢復

  因爲咱們的framework和OMXCodec的調用方式，致使過早decoder退出。具體些講，因爲咱們的封裝接口調用OMXCodec的解碼是經過read函數調用實現的。read內部會去調用tracksource->read.若是出現數據不足或者錯誤太多，容易致使tracksource的buffer不夠。咱們這時候會在tracksource的read給出數據不足的返回值。OMXcodec的封裝認爲收到這個錯誤返回值把本身的狀態設置爲Endofstream，以後就再也不解碼了。

解決方案：參考AnotherPacketSource。在tracksource read阻塞住，等新的數據填入。

3 現象：解碼時卡死

這個是因爲調用OMXCodec的調用爲阻塞致使的。咱們往codec塞數據和decode的調用都是在一個線程中。先塞數據，再decode。若是decode中出現錯誤數據過多或者數據不足時，按照上一個問題的解決方案，會出現等待新數據輸入的過程。但是這時候在framework中decode函數沒法返回，也就沒有辦法輸入更多數據了。典型的死鎖過程。

解決方案：放棄上一個方案中的阻塞方法。出現數據不足時，給OMXCodec返回一個空的MediaBuffer，而且告知沒有錯誤發生。上面兩個問題完美解決。

4 現象：沒法使用overlay

使用系統默認播放器時，會有Log代表在SurfaceFlinger作doComposeSurfaces函數時使用的是HWC_OVERLAY。而咱們的framework只能使用到HWC_FRAMEBUFFER。對比awesome player對OMXCodec的調用，發現調用的OMXCodec的接口，以及nativewindow的操做並無太大區別。

最後只好從Java層開始review，終於在 MediaPlayerService::Client::setVideoSurfaceTexture中發現了native_window_api_connect(anw.get(), NATIVE_WINDOW_API_MEDIA);調用。

解決方案： 在申請好nativewindow後調用native_window_api_connect，在release nativewindow前調用native_window_api_disconnect。