Интеграция пользовательских кодеков Wrapper в Android

Question

Мне нужно разработать собственный видеокодек "обертка" и интегрировать его в Android (JB сейчас, ICS позже). Мы хотим использовать некоторые пользовательские ключи дешифрования с SIM-карты (не спрашивайте!). Кажется, что лучший метод (который позволил бы ему работать вместе с другими незашифрованными носителями и использовать стандартный медиаплеер или другой) - это определить наш собственный mime-тип и связать его с пользовательским кодеком-оберткой, который может выполнять пользовательский расшифровывать, а затем передавать данные в реальный кодек. (Допустим, тип файла .mp4 теперь.)

(В качестве альтернативы можно написать собственный медиаплеер, но мы бы не стали идти по этому пути, потому что мы действительно хотим, чтобы медиа появлялись незаметно рядом с другими медиа)

Я пытался следовать этому руководству: как интегрировать декодер в мультимедийную среду

1. У меня проблемы с регистрацией в OMX Core - я могу собрать libstagefright.so из источника Android, набрав make stagefright но в руководстве он говорит использовать libstagefrighthw.so что кажется подходящим для JB, но я не уверен, как это построить, он, кажется, не создается с помощью make stagefright разве я что-то не так делаю?

2. Другая проблема заключается в том, что даже если я зарегистрирую пользовательский кодек-обертку, я не уверен, как передать данные в реальный кодек.

Если у кого-то есть какие-либо предложения (или они могут дать детское пошаговое руководство!), Я был бы очень признателен - крайний срок достаточно для доказательства концепции, и я очень мало знаю о кодеках или медиа-структуре...

Большое спасибо. (ps я не хочу вступать в грязную борьбу из-за проблем с drm и аналогами и т.д.., спасибо)

Answer 1

В этом посте я использую H.264 в качестве примера, но решение (я) может быть расширено для поддержки других кодеков, таких как MPEG-4, VC-1, VP8 и т.д. Есть 2 возможных решения вашей проблемы, которые я привожу ниже, каждый со своими плюсами и минусами, чтобы помочь вам принять обоснованное решение.

Решение 1. Расширьте кодек для поддержки нового режима.

В JellyBean можно зарегистрировать одно и то же OMX компонент с таким же MIME типы как 2 разных имен компонентов, а именно, OMX.ABC.XYZ а также OMX.ABC.XYZ.secure, Первый используется для нормального воспроизведения и является наиболее часто используемым компонентом. Последний используется, когда синтаксический анализатор т.е. MediaExtractor указывает на наличие защищенного контента. В OMXCodec::Create, после findMatchingCodecs возвращает список кодеков, мы можем наблюдать выбор для выбора .secure компонент, как здесь.

Шаги, чтобы следовать:

1. На вашей платформе зарегистрируйте другой компонент с новым расширением, таким как OMX.H264.DECODER.decrypt или что-то подобное. Изменение требуется только в media_codecs.xml, Выбор: зарегистрировать новый фабричный метод или использовать общий фабричный метод - ваш выбор.

2. В вашем парсере, когда вы столкнетесь с конкретным вариантом использования, установите новый флаг, например kKeyDecryptionRequired, Для этого вам нужно будет определить новый флаг в Metadata.hи соответствующий причуды в OMXCodec.h,

3. Изменить OMXCodec::create способ добавить .decrypt суффикс похож на .secure суффикс, как показано выше.

4. Со всеми изменениями в OMXCodec, Metadata, MediaExtractor модули, вам придется только перестраивать libstagefright.so и заменить то же самое на вашей платформе.

Вуаля!! Ваша интеграция должна быть завершена. Теперь возникает основная проблема внутри компонента. В рамках реализации компонента вы должны различать создание обычного компонента и .decrypt создание компонентов.

С точки зрения времени выполнения, предполагая, что ваш компонент знает о том, что это .decrypt компонент или нет, вы могли бы справиться с decryption как часть OMX_EmptyThisBuffer вызов, где вы можете расшифровать данные, а затем передать их в базовый кодек.

Плюсы: простота интеграции, минимальные изменения в платформе Android, масштабируемость для других кодеков, нет новых MIME требуется регистрация типа.

Минусы: вам нужно отслеживать будущие ревизии андроида, особенно по новым причудам, флагам и выбору .decrypt расширение. Если Google решит использовать нечто подобное, вам придется соответствующим образом адаптировать / изменить свое решение.

Решение 2: Регистрация нового типа MIME

Из вашего вопроса не ясно, смогли ли вы определить MIME введите или нет, и, следовательно, я фиксирую шаги для ясности.

Шаги, чтобы следовать:

1. Зарегистрировать новый MIME введите в MediaDefs как показано здесь. Например, вы можете нанять нового MIME введите как const char *MEDIA_MIMETYPE_VIDEO_AVC_ENCRYPT = "video/avc-encrypt";

2. Зарегистрируйте новый компонент с этим обновленным MIME введите media_codecs.xml, Обратите внимание, что вам необходимо убедиться, что причуды компонента также обрабатываются соответствующим образом.

3. В OMXCodec::setVideoOutputFormat Реализация метода, вам нужно будет представить поддержку для обработки вашего нового MIME введите, как показано для H.264 здесь Обратите внимание, что вам придется обрабатывать аналогичные изменения в OMXCodec поддержать новый MIME тип.

4. В MediaExtractor, вам придется сигнализировать MIME тип для video отслеживать с использованием нового определенного типа. С этими изменениями ваш компонент будет выбран и создан.

Тем не менее, проблема все еще остается: где выполнить расшифровку? Для этого вы также можете использовать то же решение, как описано в предыдущем разделе, т.е. обрабатывать то же самое, что и часть OMX_EmptyThisBuffer вызов.

Плюсы: ни о чем я не могу думать..

Минусы: во- первых, решение не масштабируется. Вы должны будете продолжать добавлять новые MIME типы и продолжайте изменять Stagefright фреймворк. Далее изменения в OMXCodec потребует соответствующих изменений в MediaExtractor, Следовательно, хотя ваше первоначальное внимание сосредоточено на MP4 экстрактор, если вы хотите расширить решение для других контейнерных форматов, таких как AVI, MKV, вам придется включить поддержку новых MIME типы в этих экстракторах.

Наконец, несколько заметок.

1. В качестве предпочтительного решения я бы порекомендовал Решение 1, так как оно легко и просто.

2. Я не затрагивал ACodec основанная реализация кодека. Тем не менее, я чувствую, что Решение 1 будет гораздо более простым решением для реализации, даже если такая поддержка потребуется в будущем.

3. Если вы не изменяете OMX ядро, вам не нужно изменять libstagefrighthw.so, Просто для справки, это обычно реализуется поставщиками как часть их специальных модулей, как в vendor/<xyz>/hardware/..., Вы должны проверить с вашим поставщиком платформы на источники для libstagefrighthw.so,