现在的问题并不意味着我很感兴趣，如果ffmpeg的code可以在Andoid使用。我知道，它可以。我只是问，如果有人与这些东西的真正性能的进展。 我创建了几个星期的东西，实验后的问题，我已经受够了...... 我不想写分支，其中的人甚至不说什么样的视频，他们去code（分辨率，codeC）和只讲一些神秘的FPS。我只是不明白他们想做的事情。另外，我不打算只开发了我的电话或为Android 2.2 +手机，有一些扩展的OpenGL功能的应用程序。我有颇为流行的手机的HTC Desire所以如果应用程序没有在它的工作，所以接下来会发生什么？

The question does not mean that I'm interested if ffmpeg code can be used on Andoid. I know that it can. I'm just asking if somebody has the real performance progress with that stuff. I've created the question after several weeks of experiments with the stuff and I've had enough... I do not want to write to branches where people even do not say what kind of video they decode (resolution, codec) and talk only about some mystical FPS. I just don't understand what they want to do. Also I'm not going to develop application only for my phone or for Android 2.2++ phones that have some extended OpenGL features. I have quite popular phone HTC Desire so if the application does not work on it, so what's next?

好了，我有什么？

从最新的HEAD分支FFmpeg的源代码。其实我不能NDK5球泡，所以我决定用偷来的。

FFMpeg source from the latest HEAD branch. Actually I could not buld it with NDK5 so I decided to use stolen one.

Bambuser的构建脚本（bash）的适当的ffmpeg源（[网络]：http://bambuser.com/r/opensource/ffmpeg-4f7d2fe-android-2011-03-07.tar.gz). 据一些修正通过NDK5后建立良好。

Bambuser's build script (bash) with appropriate ffmpeg source ([web]: http://bambuser.com/r/opensource/ffmpeg-4f7d2fe-android-2011-03-07.tar.gz). It builds well after some corrections by using NDK5.

RockPlayer的的阉割的ffmpeg源$ C ​​$ C巨大Android.mk在构建脚本（[网络]的能力：http://www.rockplayer.com/download/rockplayer_ffmpeg_git_20100418.zip). 据一些更正后建立了一个由NDK3和NDK5。 RockPlayer的可能是最凉爽的媒体播放器为Android，我以为，我会用它的建立有一定的津贴。

Rockplayer's gelded ffmpeg source code with huge Android.mk in the capacity of build script ([web]: http://www.rockplayer.com/download/rockplayer_ffmpeg_git_20100418.zip). It builds by NDK3 and NDK5 after some corrections. Rockplayer is probably the most cool media player for Android and I supposed that I would have some perks using it's build.

我有合适的视频的一个项目（是不是大，是不小）：600x360 H.264

I had suitable video for a project (is not big and is not small): 600x360 H.264.

我们从第2得到了与这两个库3为我们提供了可能性，以获得视频帧（一帧一帧，求等）。我没有试图让一个音轨，因为我并不需要一个用于该项目。我不发表我的源在这里，因为我认为这是传统的，很容易找到。

Both libraries we got from clauses 2 and 3 provide us possibility to get frames from video (frame-by-frame, seek etc.). I did not try to get an audio track because I did not need one for the project. I'm not publishing my source here because I think that's traditional and it's easy to find.

那么，什么结果与视频？ HTC Desire的，安卓2.2 600x360，H.264 解码和渲染，可在不同的线程

Well, what's the results with video? HTC Desire, Android 2.2 600x360, H.264 decoding and rendering are in different threads

Bambuser（NDK5球泡了的ARMv5TE，RGBA8888）：33毫秒/帧的平均 在RockPlayer的（NDK3搭建霓虹灯，RGB565）：27毫秒/帧的平均

这不是坏的第一次看，但只是觉得，这些结果只是去code帧。 如果有人与解码时间更好的结果，让我知道。

It's not bad for the first look, but just think that these are results only to decode frames. If somebody has much better results with decoding time, let me know.

最困难的事情了视频渲染。如果我们有位图600x360，我们应该画，因为不同的手机有不同的屏幕尺寸前以某种方式扩展之一，我们不能指望我们的视频将是相同大小的屏幕。

The most hard thing for a video is rendering. If we have bitmap 600x360 we should scale one somehow before painting because different phones have different screen sizes and we can not expect that our video will be the same size as screen.

做的，我们必须重新调整框架，以适应其屏幕哪些选项？ 我是能够检查（相同的电话和视频源）的情况：

What options do we have to rescale a frame to fit it to screen? I was able to check (the same phone and video source) those cases:

sws_scale（）C在Bambuser的构建功能：70毫秒/帧。不能接受的。 在安卓（Bitmap.createScaledBitmap）笨位图的重新调整：65毫秒/帧。不能接受的。 在上质感的四邻投影OpenGL渲染。在这种情况下，我并不需要扩展框架。我只是需要prepare纹理1024×512（在我的情况下，它是RGBA8888）containig帧的像素，比GPU（gl.glTexImage2D）加载它。结果：〜220毫秒/帧渲染。不能接受的。我没想到的是glTexImage2D刚吸上的Snapdragon CPU。

这就是全部。 我知道有一些方法来使用片段着色器使用GPU来转换YUV像素，但我们也会有同样的glTexImage2D和200毫秒只是纹理加载。

That's all. I know that there is some way to use fragment shader to convert YUV pixels using GPU, but we will have the same glTexImage2D and 200 ms just to texture loading.

但是，这不是结束。 ......我唯一的朋友到底... :) 这不是绝望的状态。

But this is not the end. ...my only friend the end... :) It's not hopeless condition.

试图用RockPlayer的你肯定会想知道他们是如何做到这该死的框架扩展这么快。我想，他们已经在ARM achitecture真的很好的经验。他们最有可能使用的AV codec_de code_video2比img_convert（正如我在RP版所做的那样），但他们使用的一些技巧（所依赖的ARM版本）的缩放。 也许他们也有减少的ffmpeg解码时间，但Android.mk一些神奇球泡配置，他们发布的是不是他们使用的Andr​​oid.mk。不知道啊，

Trying to use RockPlayer you definitely will wonder how they do that damn frame scaling so fast. I suppose that they have really good experience in ARM achitecture. They most probably use avcodec_decode_video2 and than img_convert (as I did in RP version), but then they use some tricks (depends of ARM version) for scaling. Maybe they also have some "magic" buld configuration for ffmpeg decreasing decoding time but Android.mk that they published is not THE Android.mk they use. Dunno...

所以，现在它看起来就像你不能只是球泡一些简单的JNI桥ffmpeg的，比有真正的媒体播放器的Andr​​oid平台。只有当你有合适的视频，你不需要缩放，你可以做到这一点。

So, now it looks like you can not just buld some easy JNI bridge for ffmpeg and than have real media player for Android platform. You can do this only if you have suitable video that you do not need to scale.

任何想法？我希望你;）

Any ideas? I hope for you ;)

推荐答案

在我的经验，YUV到RGB转换一直是一个瓶颈。因此，使用OpenGL着色此证明给一个显著的推动作用。

In my experience, YUV to RGB conversion has always been a bottleneck. Therefore, using an OpenGL shader for this proved to give a significant boost.