开发H264硬件解码器安卓- Stagefright还是OpenMax IL？
我正在为安卓开发H264 H/W加速视频解码器。到目前为止，我使用了一些库MediaCodec、Stagefright、OpenMax IL、OpenMax AL和FFmpeg。经过一番研究，我发现-
- 我发现了一个与大资源一起使用stagefright的FFmpeg，但是我不能使用FFmpeg作为它的许可证，它对分布式软件有很大的限制。(或者可能从这种方法中丢弃FFmpeg？)
- 我不能使用MediaCodec作为Java，我必须从C++层通过JNI调用它，这是相对缓慢的，我是不允许的。
- 我不能使用OpenMax AL，因为它只支持通过缓冲队列解码MPEG-2传输流。这就排除了传递原始h264、NALU或其他媒体格式的可能性。
- 现在只有左边是- OpenMax IL。我逐渐了解到stagefright使用OpenMax(OMX)接口。那么，我应该使用stagefright还是OpenMax IL呢？哪个更有希望？
另外，我知道Android /W加速解码器是特定于供应商的，每个供应商都有自己的OMX接口API。是真的吗？如果是这样的话，我是否需要在OpenMax IL的情况下编写H/W供应商的具体实现？那滞胀呢？-是硬件不可知论还是硬件依赖？如果没有使用stagefright或OpenMax IL的H/W独立实现的方法，我至少需要支持高通的Snap巨龙、三星的Exynos和Tegra-4。
请注意，我需要解码H264附件B流，并期望解码后的数据，我将发送到我的视频渲染管道。基本上，我只需要解码模块。
我真的很困惑。请帮我朝正确的方向走。提前感谢！
编辑
我的软件是为了商业目的，而且源代码也是私有的。我也被限制使用ffmpeg的客户。:)
回答 2
Stack Overflow用户
发布于 2015-09-07 06:49:16
你真的应该去找MediaCodec。通过JNI调用java方法确实有一些开销，但是您应该记住开销的大小。如果要调用每个像素的函数，则JNI调用的开销可能会出现问题。但是对于使用MediaCodec，每帧只进行几次函数调用，并且开销可以忽略不计。
例如，请参见jni.c;h=57df9889c97706436823a4960206e323565e221c;hb=b31df501269b56c65327be181cdca3df48946fb1作为使用JNI从C代码中使用MediaCodec的示例。其他人也是这样做的，我可以向您保证，JNI开销不是考虑MediaCodec以外的其他API的理由。
直接使用stagefright或OMX是有问题的；每个平台版本之间的ABI不同(所以您可以只针对一个版本，或者针对不同的版本多次编译，将其打包到一个包中)，您将不得不处理许多设备特定的怪癖，而MediaCodec应该(以及在现代版本上)在所有设备上都能同样工作。
Stack Overflow用户
发布于 2015-09-06 19:18:12
我在FFmpeg中发现了一个很好的使用stagefright的资源，但是我不能使用FFmpeg作为它的许可证，它对于分布式软件来说是相当有限的。(或者可能从这种方法中丢弃FFmpeg？)
那是胡说。FFmpeg是LGPL，所以您只需在您的商业可再发行应用程序中使用它。
但是，您可能正在使用FFmpeg的模块，这些模块是GPL许可的，例如libx264。在这种情况下，您的程序必须符合GPL。
但这对软件的分发也没什么坏处--这只是意味着你需要让你的客户(不管怎么说，谁应该是王者)，访问他们正在付费的应用程序的源代码，并且不允许限制他们的自由。交易不错，IMHO。
另外，我知道Android /W加速解码器是特定于供应商的，每个供应商都有自己的OMX接口API。是真的吗？
很明显是的。如果您需要硬件加速，必须有人编写一个程序，使您的特定硬件加速某事。
https://stackoverflow.com/questions/32427289
复制相似问题
腾讯云开发者
