Разрабатывает аппаратный декодер H264 для Android — Stagefright или OpenMax IL?
Я занимаюсь разработкой ускоренного видео декодера H264 для Android. До сих пор я пришел с некоторыми библиотеками MediaCodec, Stagefright, OpenMax IL, OpenMax AL а также FFmpeg, После небольшого исследования я обнаружил, что —
-
Я нашел большой ресурс использования stagefright с FFmpeg, но я не могу использовать FFmpeg, поскольку для его лицензии это довольно ограничительно для распределенного программного обеспечения. (Или можно отказаться от FFmpeg от этого подхода?)
-
Я не могу использовать MediaCodec в качестве Java API, и мне приходится вызывать его через JNI из уровня C ++, который является относительно медленным, и мне это запрещено.
-
Я не могу использовать OpenMax AL, поскольку он поддерживает только декодирование транспортного потока MPEG-2 через буферную очередь. Это исключает передачу необработанных значений h264 NALU или других форматов мультимедиа.
-
Теперь осталось только — stagefright и OpenMax IL. Я узнал, что stagefright использует интерфейс OpenMax (OMX). Так я должен идти с stagefright или OpenMax IL? Что будет более перспективным?
Кроме того, я узнал, что ускоренный декодер Android H / W зависит от производителя, и у каждого производителя есть свои собственные интерфейсы API OMX. Это правда? Если так, нужно ли мне писать H / W вендор для конкретной реализации OpenMax IL? А как насчет сценического страха? — Это аппаратно-независимый или аппаратно-зависимый? Если нет способа реализации H / W с использованием аддона или OpenMax IL, мне нужно поддерживать как минимум Qualcomm Snapdragon, Samsung Exynos и Tegra-4.
Обратите внимание, что мне нужно декодировать поток Приложения B H264 и ожидать декодированные данные после декодирования, которые я отправлю в свой конвейер рендеринга видео. В общем, мне нужен только модуль декодера.
Я очень смущен. Пожалуйста, помогите мне поставить в правильном направлении. Заранее спасибо!
РЕДАКТИРОВАТЬ
Мое программное обеспечение для коммерческих целей, и исходный код также является частным. И я также ограничен в использовании ffmpeg клиентом. 🙂
Решение
Вы действительно должны пойти на MediaCodec. Вызов java-методов через JNI имеет некоторые накладные расходы, но вы должны иметь в виду, какова величина этих накладных расходов. Если вы вызываете функцию на пиксель, накладные расходы на вызовы JNI могут быть проблематичными. Но для использования MediaCodec вы делаете только несколько вызовов функций на кадр, и накладные расходы там незначительны.
Смотрите, например http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/omxil/mediacodec_jni.c;h=57df9889c97706436823a4960206e323565e221c;hb=b31df501269b56c65327be181cdca3df48946fb1 В качестве примера использования MediaCodec из кода C с использованием JNI. Поскольку другие тоже пошли по этому пути, я могу заверить вас, что накладные расходы JNI не являются причиной для рассмотрения других API, кроме MediaCodec.
Использование stagefright или OMX напрямую проблематично; ABI различается в зависимости от версии платформы (так что вы можете выбрать только одну версию или скомпилировать несколько раз, ориентируясь на разные версии, упаковав все это в один пакет), и вам придется иметь дело со множеством специфических особенностей устройства, в то время как MediaCodec должен (и в современных версиях работает) одинаково на всех устройствах.
Другие решения
Я нашел большой ресурс использования stagefright с FFmpeg, но я не могу использовать FFmpeg, так как для его лицензии это довольно ограничительно для распределенного программного обеспечения. (Или можно отказаться от FFmpeg от этого подхода?)
Это не правда. FFmpeg — это LGPL, так что вы можете просто использовать его в своем коммерчески распространяемом приложении.
Тем не менее, вы можете использовать модули FFmpeg, которые имеют лицензию GPL, например, libx264. В этом случае ваша программа должна соответствовать требованиям GPL.
Но даже это не плохо для распространения программного обеспечения — это просто означает, что вам нужно предоставить своим клиентам (которые в любом случае должны быть королями) доступ к исходному коду приложения, за которое они платят, и не иметь права ограничивать их свободы. Неплохая сделка, ИМХО.
Кроме того, я узнал, что ускоренный декодер Android H / W зависит от производителя, и у каждого производителя есть свои собственные интерфейсы API OMX. Это правда?
Очевидно, да. Если вам нужно аппаратное ускорение, кто-то должен написать программу, которая заставит ваше конкретное оборудование ускорить что-то.