Pertanyaan Apakah persahabatan 'Android + FFMpeg' benar-benar tersedia?


Pertanyaannya bukan berarti saya tertarik jika kode ffmpeg bisa digunakan di Andoid. Saya tahu itu bisa. Saya hanya bertanya apakah seseorang memiliki kemajuan kinerja nyata dengan hal-hal itu. Saya telah membuat pertanyaan setelah beberapa minggu percobaan dengan hal-hal dan saya sudah cukup ... Saya tidak ingin menulis ke cabang di mana orang bahkan tidak mengatakan jenis video apa yang mereka dekodekan (resolusi, codec) dan hanya berbicara tentang beberapa FPS mistis. Saya hanya tidak mengerti apa yang ingin mereka lakukan. Saya juga tidak akan mengembangkan aplikasi hanya untuk ponsel saya atau untuk ponsel Android 2.2 ++ yang memiliki beberapa fitur OpenGL yang diperluas. Saya memiliki ponsel HTC Desire yang cukup populer sehingga jika aplikasi tidak berfungsi, maka apa selanjutnya?

Nah, apa yang saya miliki?

  1. FFMpeg sumber dari cabang HEAD terbaru. Sebenarnya saya tidak bisa membulatkannya dengan NDK5 jadi saya memutuskan untuk menggunakan yang dicuri.

  2. Script build Bambuser (bash) dengan sumber ffmpeg yang sesuai ([web]: http://bambuser.com/r/opensource/ffmpeg-4f7d2fe-android-2011-03-07.tar.gz). Ini membangun dengan baik setelah beberapa koreksi dengan menggunakan NDK5.

  3. Kode sumber ffmpeg gamer Rockplayer dengan Android.mk yang besar dalam kapasitas skrip build ([web]: http://www.rockplayer.com/download/rockplayer_ffmpeg_git_20100418.zip). Ini dibangun oleh NDK3 dan NDK5 setelah beberapa koreksi. Rockplayer mungkin adalah pemutar media paling keren untuk Android dan saya kira saya akan memiliki beberapa manfaat menggunakan build-nya.

Saya memiliki video yang cocok untuk sebuah proyek (tidak besar dan tidak kecil): 600x360 H.264.

Kedua perpustakaan yang kami peroleh dari klausul 2 dan 3 memberi kami kemungkinan untuk mendapatkan bingkai dari video (bingkai demi bingkai, mencari dll.). Saya tidak mencoba untuk mendapatkan track audio karena saya tidak membutuhkannya untuk proyek ini. Saya tidak menerbitkan sumber saya di sini karena menurut saya itu tradisional dan mudah ditemukan.

Nah, apa hasilnya dengan video? HTC Desire, Android 2.2 600x360, H.264 decoding dan rendering berada dalam utas yang berbeda

  1. Bambuser (NDK5 buld untuk armv5te, RGBA8888): 33 ms / frame rata-rata.
  2. Rockplayer (NDK3 build untuk neon, RGB565): 27 ms / frame rata-rata.

Ini tidak buruk untuk tampilan pertama, tetapi hanya berpikir bahwa ini adalah hasil hanya untuk men-decode frame. Jika seseorang memiliki hasil yang jauh lebih baik dengan waktu decoding, beri tahu saya.

Hal yang paling sulit untuk sebuah video adalah render. Jika kita memiliki bitmap 600x360 kita harus skala satu entah bagaimana sebelum melukis karena ponsel yang berbeda memiliki ukuran layar yang berbeda dan kita tidak bisa berharap bahwa video kami akan menjadi ukuran yang sama seperti layar.

Opsi apa yang harus kita atur ulang bingkai agar pas dengan layar? Saya dapat memeriksa (ponsel dan sumber video yang sama) kasus-kasus tersebut:

  1. sws_scale () fungsi C dalam build Bambuser: 70 ms / frame. Tidak bisa diterima.
  2. Stupid bitmap melakukan penyalinan ulang di Android (Bitmap.createScaledBitmap): 65 ms / frame. Tidak bisa diterima.
  3. OpenGL render dalam proyeksi ortho pada quad bertekstur. Dalam hal ini saya tidak perlu menskalakan bingkai. Saya hanya perlu menyiapkan tekstur 1024x512 (dalam kasus saya itu RGBA8888) mengandung frame piksel dan kemudian memuatnya di GPU (gl.glTexImage2D). Hasil: ~ 220 ms / frame untuk ditampilkan. Tidak bisa diterima. Saya tidak menyangka bahwa glTexImage2D hanya mengisap CPU Snapdragon.

Itu saja. Saya tahu bahwa ada beberapa cara menggunakan shader fragmen untuk mengonversi piksel YUV menggunakan GPU, tetapi kami akan memiliki glTexImage2D dan 200 ms yang sama hanya untuk pemuatan tekstur.

Tapi ini bukan akhirnya. ... satu-satunya teman saya akhirnya ... :) Ini bukan kondisi tanpa harapan.

Mencoba untuk menggunakan RockPlayer, Anda pasti akan bertanya-tanya bagaimana mereka melakukan skrap kerangka sialan begitu cepat. Saya kira mereka memiliki pengalaman yang sangat bagus dalam ARM achitecture. Mereka paling mungkin menggunakan avcodec_decode_video2 dan dari img_convert (seperti yang saya lakukan dalam versi RP), tetapi kemudian mereka menggunakan beberapa trik (tergantung versi ARM) untuk penskalaan. Mungkin mereka juga memiliki beberapa konfigurasi buld "ajaib" untuk ffmpeg yang mengurangi waktu decoding tetapi Android.mk yang mereka publikasikan bukanlah THE Android.mk yang mereka gunakan. Tidak tahu ...

Jadi, sekarang sepertinya Anda tidak bisa hanya membongkar beberapa jembatan JNI yang mudah untuk ffmpeg dan daripada memiliki pemutar media nyata untuk platform Android. Anda dapat melakukan ini hanya jika Anda memiliki video yang sesuai yang tidak perlu Anda skalakan.

Ada ide? Saya berharap untuk Anda;)


32
2018-05-20 13:28


asal


Jawaban:


Saya melakukan kompilasi ffmpeg di android. Dari titik ini - bermain video adalah murni tergantung pada implementasi, jadi tidak ada titik mengukur latensi pada hal-hal yang dapat sangat dioptimalkan di tempat yang dibutuhkan dan tidak menggunakan standart swscale. Dan ya - Anda dapat membangun beberapa jembatan JNI mudah dan menggunakannya di NDK untuk melakukan panggilan ffmpeg, tapi ini sudah menjadi kode pemain.


1
2017-07-09 14:03



Dalam pengalaman saya, YUV ke konversi RGB selalu menjadi hambatan. Karena itu, menggunakan shader OpenGL untuk ini terbukti memberikan dorongan yang signifikan.


1
2018-02-03 09:47



saya menggunakan http://writingminds.github.io/ffmpeg-android-java/ untuk proyek saya. Ada beberapa solusi dengan perintah yang rumit tetapi untuk perintah sederhana pembungkus bekerja sangat baik bagi saya.


0
2018-01-26 22:06