6

我正在为 android 开发 H264 H/W 加速视频解码器。到目前为止，我已经使用了一些库MediaCodec、Stagefright、OpenMax IL和. 经过一番研究，我发现-OpenMax ALFFmpeg

  1. 我找到了使用 FFmpeg 的 stagefright 的一个很好的资源，但是我不能使用 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 的情况下编写硬件供应商特定的实现？怯场呢？- 它是与硬件无关的还是依赖于硬件的？如果无法使用 stagefright 或 OpenMax IL 实现 H/W indenpent，我至少需要支持高通的 Snapdragon、三星的 Exynos 和 Tegra-4。

请注意，我需要解码 H264 附件 B 流并期望解码后的解码数据，我将发送到我的视频渲染管道。所以基本上，我只需要解码器模块。

我真的很困惑。请帮助我确定正确的方向。提前致谢！

编辑

我的软件是用于商业目的，源代码也是私有的。而且我也被限制为客户端使用 ffmpeg。:)

4

2 回答 2

3

你真的应该选择 MediaCodec。通过 JNI 调用 java 方法确实有一些开销，但您应该记住开销是多少数量级。如果您按像素调用一个函数，则 JNI 调用的开销可能会出现问题。但是对于使用 MediaCodec，您每帧只需执行几个函数调用，并且开销可以忽略不计。

参见例如http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/omxil/mediacodec_jni.c;h=57df9889c97706436823a4960206e323565e221c;hb=b31df501269b56c65327be181cdca3df48946fb1c作为示例使用 JNI 的代码。由于其他人也这样做了，我可以向您保证，JNI 开销不是考虑除 MediaCodec 之外的其他 API 的理由。

直接使用 stagefright 或 OMX 是有问题的；ABI 在每个平台版本之间有所不同（因此您可以只针对一个版本，或者针对不同版本多次编译，将它们全部打包在一个包中），并且您必须处理许多特定于设备的怪癖，而MediaCodec 应该（并且在现代版本上确实如此）在所有设备上都可以正常工作。

于 2015-09-07T06:49:16.103 回答
2

我找到了使用 FFmpeg 的 stagefright 的一个很好的资源，但是我不能使用 FFmpeg 作为它的许可证，它对分布式软件有很大的限制。（或者可以从这种方法中丢弃 FFmpeg？）

这不是真的。FFmpeg 是 LGPL，因此您可以在您的商业可再发行应用程序中使用它。

但是，您可能正在使用GPL 许可的 FFmpeg模块，例如 libx264。在这种情况下，您的程序必须符合 GPL。

但即使这样对分发软件也不是坏事——它只是意味着你需要让你的客户（无论如何他们应该是国王）访问他们支付的应用程序的源代码，并且不允许限制他们的自由。不错的交易，恕我直言。

此外，我了解到 Android H/W 加速解码器是特定于供应商的，每个供应商都有自己的 OMX 接口 API。这是真的吗？

显然，是的。如果您需要硬件加速，则必须有人编写一个程序来使您的特定硬件加速某些东西。

于 2015-09-06T19:18:12.443 回答