Kai*_*dul 5 c++ h.264 android-ndk stagefright openmax
我正在为Android开发H264硬件加速视频解码器。到目前为止,我已经过来和一些图书馆MediaCodec,Stagefright,OpenMax IL,OpenMax AL和FFmpeg。经过一些研究,我发现-
我发现了将stagefright与FFmpeg一起使用的绝妙资源,但是我不能将FFmpeg用作其许可证,因为它对分布式软件有很大的限制。(或者可以从这种方法中丢弃FFmpeg吗?)
我不能将MediaCodec用作Java API,而必须通过C ++层的JNI调用它,它相对较慢,因此不允许使用。
我不能使用OpenMax AL,因为它仅支持通过缓冲区队列对MPEG-2传输流进行解码。这排除了为此传递原始h264 NALU或其他媒体格式的可能性。
现在只剩下-stagefright和OpenMax IL。我知道stagefright使用OpenMax(OMX)接口。那我应该选择Stagefright还是OpenMax IL?哪个会更有前途?
另外,我知道Android H / W加速解码器是特定于供应商的,每个供应商都有自己的OMX接口API。是真的吗 如果是这样,在OpenMax IL的情况下,我是否需要编写硬件供应商特定的实现?那stagefright呢?-是否与硬件无关或与硬件相关?如果无法使用stagefright或OpenMax IL进行H / W indenpent实现,则我至少需要支持Qualcomm的Snapdragon,三星的Exynos和Tegra-4。
请注意,我需要解码H264附件B流,并希望在解码后将解码后的数据发送到视频渲染管道。因此,基本上,我只需要解码器模块。
我真的很困惑。请帮助我正确的方向。提前致谢!
编辑
我的软件用于商业目的,源代码也是私有的。而且我也被客户端限制使用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=b31df501269b56c65327be181cdca3df4894 6fb1 作为使用 C 语言 MediaCodec 的示例使用 JNI 的代码。由于其他人也采用了这种方式,我可以向您保证,JNI 开销并不是考虑 MediaCodec 之外的其他 API 的理由。
直接使用 stagefright 或 OMX 是有问题的;每个平台版本之间的 ABI 有所不同(因此您可以只针对一个版本,或者针对不同版本进行多次编译,将其全部打包在一个包中),并且您必须处理许多特定于设备的怪癖,而MediaCodec 应该(并且在现代版本上)在所有设备上都以相同的方式工作。
| 归档时间: |
|
| 查看次数: |
3287 次 |
| 最近记录: |