¿La amistad de 'Android + FFMpeg' está realmente disponible?

La pregunta no significa que me interese si el código de ffmpeg se puede utilizar en Andoid. Sé que puede. Sólo estoy preguntando si alguien tiene el progreso del rendimiento real con esas cosas. He creado la pregunta después de varias semanas de experimentos con las cosas y he tenido suficiente … No quiero escribir a las sucursales donde la gente incluso no decir qué tipo de vídeo que decodificar (resolución, codec) y hablar Sólo sobre algunos FPS místicos. Simplemente no entiendo lo que quieren hacer. También no voy a desarrollar la aplicación sólo para mi teléfono o para teléfonos Android 2.2 ++ que tienen algunas características ampliadas de OpenGL. Tengo muy popular teléfono HTC Desire por lo que si la aplicación no funciona en él, ¿qué sigue?

Bueno, ¿qué tengo?

FFMpeg de la última rama de HEAD. Realmente no podría buld él con NDK5 así que decidí utilizar robado.
Script de compilación de Bambuser (bash) con la fuente ffmpeg apropiada ([web]: http://bambuser.com/r/opensource/ffmpeg-4f7d2fe-android-2011-03-07.tar.gz ). Se construye bien después de algunas correcciones utilizando NDK5.
Rockplayer's gelded ffmpeg código fuente con Android.mk enorme en la capacidad de construir script ([web]: http://www.rockplayer.com/download/rockplayer_ffmpeg_git_20100418.zip ). Se construye por NDK3 y NDK5 después de algunas correcciones. Rockplayer es probablemente el reproductor de medios más cool para Android y supuse que tendría algunas ventajas usando su compilación.

Tenía vídeo adecuado para un proyecto (no es grande y no es pequeño): 600×360 H.264.

Ambas bibliotecas que obtuvimos de las cláusulas 2 y 3 nos proporcionan la posibilidad de obtener marcos de vídeo (cuadro por cuadro, buscar, etc.). No intenté conseguir una pista de audio porque no necesitaba uno para el proyecto. No estoy publicando mi fuente aquí porque creo que es tradicional y es fácil de encontrar.

Bueno, ¿cuáles son los resultados con el video? HTC Desire, Android 2.2 600×360, descodificación H.264 y renderizado están en diferentes hilos

Bambuser (NDK5 buld para armv5te, RGBA8888): 33 ms / frame average.
Rockplayer (generación NDK3 para neón, RGB565): 27 ms / frame average.

No está mal para la primera mirada, pero apenas piense que éstos son resultados solamente para descodificar marcos. Si alguien tiene resultados mucho mejores con el tiempo de decodificación, házmelo saber.

Lo más difícil para un video es la reproducción. Si tenemos bitmap 600×360 debemos escalar uno de alguna manera antes de pintar porque los diferentes teléfonos tienen diferentes tamaños de pantalla y no podemos esperar que nuestro video será del mismo tamaño que la pantalla.

¿Qué opciones tenemos para cambiar la escala de un marco para que se ajuste a la pantalla? Pude comprobar (la misma fuente de teléfono y video) esos casos:

Sws_scale () Función C en la compilación de Bambuser: 70 ms / frame. Inaceptable.
Estúpido reescalado de mapa de bits en Android (Bitmap.createScaledBitmap): 65 ms / frame. Inaceptable.
Representación de OpenGL en la proyección del ortho en el patio texturizado. En este caso no necesité escalar el marco. Sólo necesitaba preparar la textura 1024×512 (en mi caso era RGBA8888) conteniendo píxeles de marco y que cargarlo en GPU (gl.glTexImage2D). Resultado: ~ 220 ms / frame para renderizar. Inaceptable. No esperaba que glTexImage2D sólo succionara en la CPU de Snapdragon.

Eso es todo. Sé que hay alguna manera de usar shader de fragmentos para convertir píxeles YUV usando GPU, pero tendremos el mismo glTexImage2D y 200 ms sólo para la carga de textura.

Pero, este no es el final. … mi único amigo el final … 🙂 No es condición desesperada.

Intentando utilizar RockPlayer definitivamente te preguntarás cómo hacen ese maldito marco escalando tan rápido. Supongo que tienen muy buena experiencia en ARM achitecture. Lo más probable es que utilicen avcodec_decode_video2 y que img_convert (como lo hice en la versión RP), pero luego utilizan algunos trucos (depende de la versión ARM) para escalar. Tal vez también tienen algunos "magia" buld configuración para ffmpeg disminución de tiempo de decodificación, pero Android.mk que publicaron no es el Android.mk que utilizan. No sé…

Por lo tanto, ahora parece que no puede buld sólo algunos fácil JNI puente para ffmpeg y que tienen reproductor de medios real para la plataforma Android. Sólo puede hacer esto si tiene un vídeo adecuado que no necesita escalar.

¿Algunas ideas? Yo tengo esperanza en ti 😉

Yo compilar ffmpeg en android. A partir de este punto – reproducir vídeo es puramente dependiente de la implementación, por lo que no hay punto de medir las latencias en las cosas whitch puede ser altamente optimizado en el lugar necesario y no utilizar standart swscale. Y sí – usted puede construir algún puente JNI fácil y utilizarlo en NDK para realizar llamadas ffmpeg, pero esto ya sería un código de jugador.

En mi experiencia, la conversión de YUV a RGB siempre ha sido un cuello de botella. Por lo tanto, usar un sombreado OpenGL para esto demostró dar un impulso significativo.

Utilizo http://writingminds.github.io/ffmpeg-android-java/ para mi proyecto. Hay alguna solución con comandos complejos, pero para comandos simples, el reiniciador funciona muy bien para mí.