開發H264硬件解碼器Android - Stagefright或OpenMax IL？

Question

我正在為Android開發H264 H / W加速視頻解碼器。 到目前為止，我已經找到了一些圖書館MediaCodec ， Stagefright ， OpenMax IL ， OpenMax AL和FFmpeg 。 經過一番研究，我發現 -

1. 我找到了一個很好的使用stagefright與FFmpeg的資源 ，但我不能使用FFmpeg作為其許可證，它對分布式軟件是相當嚴格的。 （或者可以從這種方法中丟棄FFmpeg？）

2. 我不能使用MediaCodec作為它的Java API，我必須通過C ++層的JNI調用它，這是相對慢的，我不被允許。

3. 我不能使用OpenMax AL，因為它只支持通過緩沖隊列解碼MPEG-2傳輸流。 這排除了傳遞原始h264 NALU或其他媒體格式的問題。

4. 現在只剩下 - stagefright和OpenMax IL。 我開始知道stagefright使用OpenMax（OMX）接口。 那么我應該使用stagefright還是OpenMax IL？ 哪個會更有希望？

此外，我發現Android H / W加速解碼器是供應商特定的，每個供應商都有自己的OMX接口API。 這是真的嗎？ 如果是這樣，我是否需要編寫OpenMax IL的H / W供應商特定實現？ 那么stagefright呢？ - 它是硬件無關的還是硬件依賴的？ 如果使用stagefright或OpenMax IL無法實現H / W，我需要至少支持Qualcomm的Snapdragon，三星的Exynos和Tegra-4。

注意，我需要解碼H264附件B流並期望解碼后的解碼數據，我將發送到我的視頻渲染管道。 所以基本上，我只需要解碼器模塊。

我真的很困惑。 請幫助我正確指導。 提前致謝！

編輯

我的軟件用於商業目的，源代碼也是私有的。 我也被限制使用客戶端的ffmpeg。 :)

Answer 1

你真的應該選擇MediaCodec。 通過JNI調用java方法確實有一些開銷，但是你應該記住開銷的數量級。 如果你為每個像素調用一個函數，JNI調用的開銷可能會有問題。 但是對於使用MediaCodec，每幀只進行一些函數調用，其開銷可以忽略不計。

例如，請參閱http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/omxil/mediacodec_jni.c;h=57df9889c97706436823a4960206e323565e221c;hb=b31df501269b56c65327be181cdca3df48946fb1作為使用C的MediaCodec的示例使用JNI的代碼。 正如其他人也這樣，我可以向你保證，JNI開銷不是考慮其他API而不是MediaCodec的理由。

直接使用stagefright或OMX是有問題的; ABI在每個平台版本之間有所不同（因此您可以只針對一個版本，或者針對不同版本進行多次編譯，將其全部打包在一個軟件包中），並且您必須處理許多特定於設備的怪癖，而MediaCodec應該（並且在現代版本上）應該在所有設備上工作相同。

Answer 2

我找到了一個很好的使用stagefright與FFmpeg的資源，但我不能使用FFmpeg作為其許可證，它對分布式軟件是相當嚴格的。 （或者可以從這種方法中丟棄FFmpeg？）

這不是真的。 FFmpeg是LGPL，因此您可以在商業可再發行應用程序中使用它。

但是，您可能正在使用經過GPL許可的FFmpeg 模塊 ，例如libx264。 在這種情況下，您的程序必須符合GPL標准。

但即使這對分發軟件也不好 - 這只是意味着你需要給你的客戶（無論如何應該是國王），訪問他們所支付的應用程序的源代碼，並且不允許限制他們的自由。 不是壞事，恕我直言。

此外，我發現Android H / W加速解碼器是供應商特定的，每個供應商都有自己的OMX接口API。 這是真的嗎？

顯然，是的。 如果您需要硬件加速，有人必須編寫一個程序，使您的特定硬件加速。