Вопрос не означает, что мне интересно, можно ли использовать код ffmpeg на Android. Я знаю, что это возможно. Я просто спрашиваю, есть ли у кого-то реальный прогресс в производительности с этим материалом.
Я создал вопрос после нескольких недель экспериментов с материалом, и с меня хватит ...
Я не хочу писать в ветки, где люди даже не говорят, какое видео они декодируют (разрешение, кодек), а говорят только о каком-то мистическом FPS. Я просто не понимаю, что они хотят делать. Также я не собираюсь разрабатывать приложения только для моего телефона или для телефонов Android 2.2 ++, которые имеют некоторые расширенные функции OpenGL. У меня довольно популярный телефон HTC Desire, так что если приложение на нем не работает, что дальше?
Ну что у меня?
Источник FFMpeg из последней ветки HEAD. На самом деле я не мог сделать это с 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 (NDK5 buld для armv5te, RGBA8888): 33 мс / кадр в среднем.
- Rockplayer (сборка NDK3 для неона, RGB565): среднее значение 27 мс / кадр.
Это не плохо для первого взгляда, но просто подумайте, что это результаты только для декодирования кадров.
Если у кого-то есть намного лучшие результаты со временем декодирования, дайте мне знать.
Самым сложным для видео является рендеринг. Если у нас есть растровое изображение 600x360, мы должны каким-то образом масштабировать его перед рисованием, потому что разные телефоны имеют разные размеры экрана, и мы не можем ожидать, что наше видео будет того же размера, что и экран.
Какие варианты у нас есть, чтобы изменить масштаб кадра, чтобы он поместился на экране?
Мне удалось проверить (тот же телефон и источник видео) те случаи:
- Функция sws_scale () C в сборке Bambuser: 70 мс / кадр. Неприемлемо.
- Глупое масштабирование растрового изображения в Android (Bitmap.createScaledBitmap): 65 мс / кадр. Неприемлемо.
- Рендеринг OpenGL в ортопроекции на текстурированный квад. В этом случае мне не нужно масштабировать рамку. Мне просто нужно было подготовить текстуру 1024x512 (в моем случае это была RGBA8888), содержащую пиксели кадров, и затем загрузить ее в графический процессор (gl.glTexImage2D). Результат: ~ 220 мс / кадр для рендеринга. Неприемлемый. Я не ожидал, что glTexImage2D просто засосал процессор Snapdragon.
Вот и все.
Я знаю, что есть какой-то способ использовать фрагментный шейдер для преобразования пикселей YUV с использованием графического процессора, но у нас будет тот же glTexImage2D и 200 мс только для загрузки текстуры.
Но это не конец. ... мой единственный друг конец ... :)
Это не безнадежное состояние.
Пытаясь использовать RockPlayer, вы наверняка удивитесь, как они делают это чертово масштабирование кадров так быстро. Я полагаю, что у них действительно хороший опыт в архитектуре ARM. Скорее всего, они используют avcodec_decode_video2 и img_convert (как я это делал в версии RP), но затем они используют некоторые приемы (в зависимости от версии ARM) для масштабирования.Возможно, у них также есть какая-то «волшебная» конфигурация buld для ffmpeg, уменьшающая время декодирования, но опубликованный ими Android.mk не является Android.mk, который они используют.Не знаю ...
Итак, теперь похоже, что вы не можете просто создать простой мост JNI для ffmpeg, чем настоящий медиаплеер для платформы Android.Вы можете сделать это, только если у вас есть подходящее видео, которое вам не нужно масштабировать.
Есть идеи?Я надеюсь на тебя;)