android - 'Android+FFMpeg'友谊真的可用吗？

Question

这个问题并不意味着我对ffmpeg代码是否可以在Andoid上使用感兴趣。我知道可以。我只是问某人在这些东西上是否具有真正的性能进步。
经过数周的实验，我已经提出了问题，我已经受够了。
我不想写信给人们甚至不说他们解码什么样的视频(分辨率，编解码器)，而只谈论一些神秘的FPS的分支机构。我只是不明白他们想做什么。另外，我不会仅为我的手机或具有某些扩展OpenGL功能的Android 2.2++手机开发应用程序。我的手机HTC Desire非常受欢迎，因此如果该应用程序无法在其上运行，那么接下来该怎么办？
好吧，我有什么？

来自最新HEAD分支的FFMpeg源。实际上，我无法使用NDK5做到这一点，所以我决定使用被盗的NDK5。

Bambuser的构建脚本(bash)具有适当的ffmpeg源([web]:http://bambuser.com/r/opensource/ffmpeg-4f7d2fe-android-2011-03-07.tar.gz)。
通过使用NDK5进行一些更正后，它可以很好地构建。

Rockplayer混合了ffmpeg源代码，具有庞大的Android.mk，具有构建脚本的功能([web]:http://www.rockplayer.com/download/rockplayer_ffmpeg_git_20100418.zip)。

经过一些更正后，它是由NDK3和NDK5构建的。 Rockplayer可能是Android上最酷的媒体播放器，我认为使用该版本会带来一些好处。
我有一个适合项目的视频(不大也不小):600x360 H.264。
我们从第2条和第3条获得的两个库都为我们提供了从视频中获取帧的可能性(逐帧，查找等)。我没有尝试获取音轨，因为我不需要该项目的音轨。我不会在这里发布我的资源，因为我认为这是传统的，而且很容易找到。
那么，视频的结果如何？

HTC Desire，Android 2.2

600x360，H.264

解码和渲染位于不同的线程中

Bambuser(armv5te使用NDK5，RGBA8888):平均33毫秒/帧。

Rockplayer(NDK3用于 NEON ，RGB565):平均27毫秒/帧。

乍一看还不错，但只需认为这些只是解码帧的结果。
如果有人在解码时间上有更好的结果，请告诉我。
视频最难的是渲染。如果我们有600x360的位图，则我们应该在绘画之前以某种方式缩放比例，因为不同的手机具有不同的屏幕尺寸，并且我们不能指望视频与屏幕的尺寸相同。
我们必须重新调整框架以使其适合屏幕的哪些选项？
我能够检查(相同的电话和视频源)这些情况:

sws_scale()Bambuser构建中的C函数:70 ms/帧。不能接受

Android中笨拙的位图缩放(Bitmap.createScaledBitmap):65毫秒/帧。不能接受

在纹理四边形上进行正投影的OpenGL渲染。在这种情况下，我不需要缩放框架。我只需要准备1024x512纹理(在我的情况下是RGBA8888)包含igig帧像素，然后将其加载到GPU(gl.glTexImage2D)中即可。结果:〜220 ms/帧要渲染。不能接受我没想到glTexImage2D只是在Snapdragon CPU上很烂。

就这样。我知道有一些方法可以使用片段着色器通过GPU转换YUV像素，但是我们只有相同的glTexImage2D和200 ms才能加载纹理。
但这还没有结束。 ...我唯一的 friend 最终... :)这不是绝望的情况。
尝试使用RockPlayer时，您肯定会想知道他们如何如此快地进行如此糟糕的帧缩放。我想他们在ARM体系结构方面拥有非常好的经验。他们最有可能使用avcodec_decode_video2而不是img_convert(就像我在RP版本中所做的那样)，但是随后他们使用了一些技巧(取决于ARM版本)进行缩放。
也许他们对ffmpeg也有一些“神奇”的buld配置，以减少解码时间，但是他们发布的Android.mk并不是他们使用的Android.mk。我不知道。
因此，现在看来，您不仅可以为ffmpeg提供一些简单的JNI桥梁，而且不能为Android平台提供真正的媒体播放器。仅当您有不需要缩放的合适视频时，才可以执行此操作。
有任何想法吗？

Answer 1

我确实在Android上编译了ffmpeg。从这一点出发-播放视频纯粹取决于实现，因此无法在需要的位置而不使用标准的swscale来高度优化衡量鞭子延迟的点。是的-您可以构建一些简单的JNI桥并在NDK中使用它来执行ffmpeg调用，但这已经是一个播放器代码。