我正在为Android开发H264 H/W加速视频解码器。到目前为止,我已经有了一些库MediaCodec
,Stagefright
,OpenMax IL
,OpenMax AL
和FFmpeg
。经过研究,我发现-
另外,我知道Android H/W加速解码器是特定于供应商的,每个供应商都有自己的OMX接口(interface)API。是真的吗如果是这样,在OpenMax IL的情况下,我是否需要编写硬件特定于供应商的实现?那stagefright呢? -是否与硬件无关或与硬件相关?如果无法使用stagefright或OpenMax IL进行H/W indenpent实现,则我至少需要支持Qualcomm的Snapdragon,三星的Exynos和Tegra-4。
请注意,我需要解码H264附件B流,并希望在解码后将解码后的数据发送到我的视频渲染管道。因此,基本上,我只需要解码器模块。
我真的很困惑。请帮助我正确的方向。提前致谢!
编辑
我的软件用于商业目的,源代码也是私有(private)的。而且我也被客户端限制使用ffmpeg。 :)
最佳答案
您确实应该选择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作为使用JNI从C代码使用MediaCodec的示例。正如其他人也采用这种方式一样,我可以向您保证,JNI开销不是考虑使用MediaCodec之外的其他API的原因。
直接使用stagefright或OMX是有问题的;每个平台版本之间的ABI有所不同(因此,您只能针对一个版本,或者针对不同版本进行多次编译,然后将它们打包在一个软件包中),并且您必须应对许多特定于设备的怪癖,而MediaCodec应该(并且在现代版本中也是如此)在所有设备上都可以正常工作。