Разработвате H264 хардуерен декодер за Android - Stagefright или OpenMax IL?

Разработвам H264 H/W ускорен видео декодер за android. Досега се сдобих с някои библиотеки MediaCodec, Stagefright, OpenMax IL, OpenMax AL и FFmpeg. След малко проучване открих, че...

  1. Намерих страхотен ресурс за използване на stagefright с FFmpeg, но не мога да използвам FFmpeg като лиценз, той е доста ограничителен за разпределен софтуер. (Или е възможно да отхвърлите FFmpeg от този подход?)

  2. Не мога да използвам MediaCodec като негов Java API и трябва да го извикам чрез JNI от C++ слой, което е относително бавно и не ми е позволено.

  3. Не мога да използвам OpenMax AL, тъй като поддържа само декодиране на MPEG-2 транспортен поток чрез буферна опашка. Това изключва предаването на необработени h264 NALU или други медийни формати по този въпрос.

  4. Сега останаха само - stagefright и OpenMax IL. Разбрах, че stagefright използва OpenMax(OMX) интерфейс. Така че трябва ли да използвам stagefright или OpenMax IL? Кое ще е по-обещаващо?

Освен това разбрах, че ускореният декодер на Android H/W е специфичен за доставчика и всеки доставчик има свои собствени OMX API интерфейси. Вярно ли е? Ако е така, трябва ли да напиша H/W специфична реализация на доставчика в случай на OpenMax IL? Какво ще кажете за сценичния страх? - Хардуерно зависим ли е или зависи от хардуера? Ако няма начин за H/W независимо внедряване с помощта на stagefright или OpenMax IL, трябва да поддържам поне Snapdragon на Qualcomm, Exynos на Samsung и Tegra-4.

Обърнете внимание, че трябва да декодирам поток H264 Annex B и да очаквам декодирани данни след декодиране, които ще изпратя към моя канал за рендиране на видео. Така че основно ми трябва само декодерният модул.

Наистина съм много объркан. Моля, помогнете ми да насоча в правилната посока. Благодаря предварително!

РЕДАКТИРАНЕ

Моят софтуер е с търговска цел и изходният код също е частен. И аз също съм ограничен да използвам ffmpeg от клиент. :)


person Kaidul    schedule 06.09.2015    source източник
comment
Възможен дубликат на Как да използвам хардуерно ускорено декодиране на видео на Android?   -  person Ciro Santilli 新疆再教育营六四事件ۍ    schedule 22.02.2016


Отговори (2)


Наистина трябва да изберете MediaCodec. Извикването на java методи чрез JNI има някои допълнителни разходи, но трябва да имате предвид какъв е порядъкът на големината. Ако извикате функция на пиксел, режийните разходи на JNI извикванията може да са проблематични. Но за използването на MediaCodec правите само няколко извиквания на функции на кадър и режийните разходи там са незначителни.

Вижте напр. http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/omxil/mediacodec_jni.c;h=57df9889c97706436823a4960206e323565e221c;hb=b31df501269b56c65327be181cdca46df пример закатоa43df48 с помощта на MediaCodec от C код с помощта на JNI. Тъй като други също са поели по този път, мога да ви уверя, че разходите за JNI не са причина да се обмислят други API освен MediaCodec.

Използването на stagefright или OMX директно е проблематично; ABI се различава между всяка версия на платформата (така че можете или да се насочите само към една версия, или да компилирате няколко пъти, насочвайки се към различни версии, опаковайки всичко в един пакет), и ще трябва да се справите с много странности, специфични за устройството, докато MediaCodec трябва (и в съвременните версии го прави) да работи еднакво на всички устройства.

person mstorsjo    schedule 07.09.2015
comment
Благодаря за вашият отговор! Предложиха ми MediaCodec в няколко теми, но аз избегнах съвета. Сега ще направя бърз тест и ще видя как се представя. - person Kaidul; 07.09.2015
comment
Видях, че обвивката на vlc mediacodec jni използва специфични заглавки на OMX, имам ли нужда от тях, за да извикват само методи на слоя mediacodec Java в основния слой? - person Kaidul; 13.10.2015
comment
Не се нуждаете от специфичните за OMX хедъри, но във VLC те се използват за удобство, тъй като има някакъв споделен код. Единственото споделено нещо е обработката на интерпретирането на цветовия формат на MediaCodec, което се оказва същото като за OMX. (Тоест, MediaCodecInfo.CodecCapabilities.COLOR_FormatYUV420SemiPlanar е еквивалентен на OMX_COLOR_FormatYUV420SemiPlanar; има споделен код за копиране на данни от MediaCodec/OMX буфери в собствените картини на VLC, с различни кодови пътища за различни цветови формати.) - person mstorsjo; 13.10.2015
comment
Благодаря! Има функция, наречена MediaCodec_getName() git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/omxil/, който съдържа всички OMX* неща. Мога ли да го пропусна, като извикам MediaCodec.getName() Java API от по-ниско ниво? - person Kaidul; 13.10.2015
comment
Функцията MediaCodec_getName(), към която сте се свързали, е по-сложна версия на извършване на MediaCodec.createDecoderByType чрез ръчно повторение върху MediaCodecList. Това позволява да се пропуснат някои декодери, за които е известно, че не работят за случая на използване на VLC. - person mstorsjo; 13.10.2015
comment
Благодаря ти! Един последен въпрос - мога ли да обвия всички MediaCodec методи с персонализиран Java метод и да извикам персонализирания метод с помощта на JNI? Искам да кажа - тогава всички функции на медиакодек ще бъдат извикани вътре във функцията. Има ли някаква разлика между този подход и извикването на функциите на mediacodec една по една с помощта на JNI? - person Kaidul; 14.10.2015
comment
Това трябва да е също толкова добро, наистина няма разлика. Разходите за извикване на JNI методи не са толкова големи, колкото биха имали значение, но вероятно могат да направят кода ви малко по-чист и по-лесен за четене. - person mstorsjo; 14.10.2015

Намерих страхотен ресурс за използване на stagefright с FFmpeg, но не мога да използвам FFmpeg като лиценз, той е доста ограничителен за разпространен софтуер. (Или е възможно да отхвърлите FFmpeg от този подход?)

Това не е вярно. FFmpeg е LGPL, така че можете просто да го използвате във вашето търговско приложение за разпространение.

Възможно е обаче да използвате модули на FFmpeg, които са GPL лицензирани, напр. libx264. В този случай вашата програма трябва да е съвместима с GPL.

Но дори това не е лошо за разпространението на софтуер - просто означава, че трябва да дадете на клиентите си (които така или иначе трябва да са крале) достъп до изходния код на приложението, за което плащат, и нямате право да ограничавате техните свободи. Не е лоша сделка, IMHO.

Освен това разбрах, че ускореният декодер на Android H/W е специфичен за доставчика и всеки доставчик има свои собствени OMX API интерфейси. Вярно ли е?

Очевидно, да. Ако имате нужда от хардуерно ускорение, някой трябва да напише програма, която кара вашия специфичен хардуер да ускорява нещо.

person Marcus Müller    schedule 06.09.2015