L'amitié entre Android et FFMpeg est-elle vraiment disponible?

Question

La question ne signifie pas que je suis intéressé si ffmpeg code peut être utilisé sur Andoid. Je sais qu'il peut. Je demande juste si quelqu'un a le vrai progrès des performances avec ce genre de choses. J'ai créé la question, après plusieurs semaines d'expériences avec les trucs et j'en ai eu assez... Je ne veux pas écrire pour les branches dans lesquelles des gens ne disent pas ce genre de vidéo qu'ils décoder (résolution, codec) et ne parler que de certains mystiques FPS. Je ne comprends pas ce qu'ils veulent faire. Aussi, je ne vais pas développer des applications uniquement pour mon téléphone ou pour Android 2.2++ téléphones qui ont une certaine étendue fonctionnalités OpenGL. J'ai très populaire téléphone HTC Desire ainsi, si l'application ne fonctionne pas sur elle, alors quelle est la prochaine?

Eh bien, que dois-je?

1. FFMpeg source à partir de la dernière TÊTE de la branche. En fait, je ne pouvais pas buld avec NDK5 j'ai donc décidé d'utiliser volées.

2. Bambuser de génération de script (bash) à l'ffmpeg source ([web]: http://bambuser.com/r/opensource/ffmpeg-4f7d2fe-android-2011-03-07.tar.gz). Il construit bien après quelques corrections en utilisant NDK5.

3. Rockplayer est castré ffmpeg code source avec d'énormes Android.mk dans la capacité de construire script ([web]: http://www.rockplayer.com/download/rockplayer_ffmpeg_git_20100418.zip). Il s'appuie par NDK3 et NDK5 après quelques corrections. Rockplayer est probablement la chose la plus cool media player pour Android et je suppose que j'aurais quelques avantages à l'aide de sa construction.

J'avais adapté la vidéo pour un projet (s'il n'est pas gros et n'est pas petite): 600x360 H. 264.

Les deux bibliothèques que nous avons reçu, alinéas 2 et 3 de nous fournir la possibilité d'obtenir des images à partir de la vidéo (image par image, rechercher, etc.). Je n'ai pas essayer d'obtenir une piste audio parce que je n'en avais pas besoin pour le projet. Je ne suis pas publier ma source ici parce que je pense que c'est traditionnel et il est facile à trouver.

Eh bien, ce sont les résultats avec la vidéo? Le Désir de HTC, Android 2.2 600x360, H. 264 le décodage et le rendu dans différents threads

1. Bambuser (NDK5 buld pour armv5te, RVBA8888): 33 ms/cadre moyen.
2. Rockplayer (NDK3 construire pour le néon, RGB565): 27 ms/cadre moyen.

C'est pas mal pour le premier coup d'oeil, mais il suffit de penser que ces résultats sont-ils seulement de décoder les images. Si quelqu'un a de bien meilleurs résultats avec le décodage de temps, laissez-moi savoir.

Le plus difficile pour une vidéo de rendu. Si nous avons bitmap 600x360 nous devrions échelle d'une certaine façon avant de peindre, parce que les différents téléphones mobiles ont différentes tailles d'écran et on ne peut pas s'attendre à ce que notre vidéo sera de la même taille que l'écran.

Quelles sont les options que nous avons pour redimensionner une image pour l'adapter à l'écran? J'ai pu vérifier (le même téléphone et la vidéo source) ces cas:

1. sws_scale() fonction C dans Bambuser de construire: 70 ms/cadre. Inacceptable.
2. Stupide bitmap du changement d'échelle dans Android (Bitmap.createScaledBitmap): 65 ms/cadre. Inacceptable.
3. De rendu OpenGL dans ortho projection texturé quad. Dans ce cas, je n'ai pas besoin de redimensionner le cadre. J'ai juste besoin de préparer la texture 1024x512 (dans mon cas c'était RVBA8888) contenant cadre de pixels et de le charger dans le GPU (gl.glTexImage2D). Résultat: ~220 ms/image pour le rendu. Inacceptable. Je n'ai pas s'attendre à ce que glTexImage2D vient de sucer sur le PROCESSEUR Snapdragon.

C'est tout. Je sais qu'il y est une certaine façon d'utiliser le fragment shader pour convertir YUV pixels à l'aide de GPU, mais nous aurons la même glTexImage2D et 200 ms juste pour la texture de chargement.

Mais ce n'est pas la fin. ...mon seul ami à la fin... :) Ce n'est pas condition désespérée.

Essayez d'utiliser RockPlayer vous allez certainement me demande comment elles font sacrément image mise à l'échelle rapide. Je suppose qu'ils ont vraiment une bonne expérience dans le BRAS achitecture. Ils ont le plus probablement utiliser avcodec_decode_video2 et que img_convert (comme je l'ai fait en RP version), mais ensuite, ils utilisent certains trucs (dépend de BRAS de version) pour la mise à l'échelle. Peut-être qu'ils ont aussi quelques "magie" buld de configuration pour ffmpeg diminution de décodage de temps, mais Android.mk publié n'est pas de L'Android.mk qu'ils utilisent. Je ne sais pas...

Alors, maintenant, il semble que vous ne pouvez pas simplement buld facile JNI pont pour ffmpeg et que real media player pour la plateforme Android. Vous pouvez faire cela seulement si vous avez adapté la vidéo que vous n'avez pas besoin d'échelle.

Des idées? J'espère que pour vous ;)

Answer 1

J'ai compilé ffmpeg sur Android. À partir de ce moment - la lecture de la vidéo dépend uniquement de la mise en œuvre, il est donc inutile de mesurer les latences sur des éléments pouvant être optimisés à la place requise et sans utiliser l'échelle standard. Et oui - vous pouvez créer un pont JNI simple et l'utiliser dans NDK pour effectuer des appels ffmpeg, mais il s'agirait déjà d'un code de joueur.

Answer 2

D'après mon expérience, la conversion YUV en RVB a toujours été un goulot d'étranglement. Par conséquent, l’ utilisation d’un shader OpenGL à cet effet s’est révélée très utile.