Cómo invocar mi decodificador personalizado en el código fuente de Android

Estoy intentando agregar mi decodificador del software HEVC al código de fuente del androide. Quiero generar el archivo libstagefright.so .

Me he referido a otras preguntas similares y no fueron de mucha ayuda para mí. No pude obtener una imagen clara con las siguientes preguntas o la guía de referencia.

1) Integración de un codec a Android marco multimedia.

2) Integrar un decodificador personalizado para jugar en android y mostrar fps al mismo tiempo.

3) Cómo registrar un núcleo OMX para agregar un nuevo decodificador.

¿Puede alguien por favor ayudarme con los pasos para la integración de un nuevo decodificador personalizado con Android.

En este momento, acabo de añadir el archivo media_codecs.xml y { "OMX.google.h265.decoder" , "hevcdec" , "video_decoder.hevc" } en el archivo SoftOMXPlugin.cpp.

¿Qué otros archivos necesitan ser editados para un nuevo formato que se agregará al código fuente de Android? ¿Qué funciones invocan mi código fuente de decodificador (¿El archivo de código fuente de softomxcplugin invoca mi decodificador?).

De su consulta y discusiones anteriores, encuentre los pasos para integrar un componente HEVC en el marco de Android . Dado que, su componente es un componente de SW , tendría que integrar el mismo como un SoftVideoDecoderOMXComponent .

¿Qué es SoftVideoDecoderOMXComponent ?

En las últimas versiones del framework Android Stagefright , los codecs acelerados de SW se integran en el framework usando una interfaz similar a OMX . Anteriormente, este no era el caso y tenía algunos desafíos de su propia. Por lo tanto, Google ha simplificado la estrategia de integración y obligatorio que todos los códecs de SW empleará un SoftOMXComponent como interfaz.

La mayoría de las llamadas de OMX IL son manejadas por la clase base y por lo tanto, la implementación de un nuevo componente de códec es relativamente fácil como se describe a continuación.

Me gustaría tomar el ejemplo de la integración de códec AVC para proporcionar una visión general. Se recomienda que el lector esté familiarizado con la especificación OMX IL 1.1.2 que describe la estructura, el funcionamiento y la máquina de estado de un componente decodificador de vídeo OMX IL .

Nota: HEVC aún no forma parte de la especificación OMX IL y por lo tanto, la recomendación es principalmente entender la estructura y el funcionamiento del componente.

Creación del componente SoftHEVC

Consulte el archivo de encabezado de SoftAVC.h y la fuente correspondiente SoftAVC.cpp .

Tendrá que implementar un conjunto similar de archivos. Es muy recomendable reutilizar la implementación general de AVC debido a algunas similitudes inherentes.

Implementación de SoftHEVC.cpp

SoftHEVC definir un componente SoftHEVC.h en SoftHEVC.h que deriva de SoftVideoDecoderOMXComponent . Esto garantizaría que todas las llamadas OMX sean manejadas adecuadamente por la clase base.
CodecProfileLevel definir una tabla de combinaciones de level profile de soporte, tal como se encuentra en CodecProfileLevel .
En el constructor , puede inicializar la mayoría de las variables de una manera similar. Puesto que se trata de un componente de decodificador de vídeo, tendrá que inicializar 2 puertos a saber, input y output . ctor invoca un initDecoder para inicializar el componente. También tendría que implementar una funcionalidad similar para su códec.
El dtor se explica por sí mismo y por lo tanto, voy a saltar explicando lo mismo.
onQueueFilled se invoca cuando se proporciona un búfer lleno con un valor de trama de datos de flujo de bits para procesamiento en input puerto de input o se proporciona un búfer libre para la output . Esto invoca la función de descodificación principal H264SwDecDecode . Ahora, para el primer fotograma, podría encontrarse un cambio en las resoluciones en comparación con la resolución inicialmente inicializada. Esto es manejado por 2 escenarios como se describe en el siguiente punto.
handlePortSettingsChanged observar 2 funciones handlePortSettingsChanged y handleCropRectEvent . Estos 2 eventos son importantes desde la perspectiva de un búfer de salida. handlePortSettingsChanged significa un cambio en las dimensiones del búfer de salida en comparación con el tamaño inicialmente inicializado y por lo tanto, proporciona una devolución de llamada de evento al usuario para liberar la asignación actual y reasignar el mismo. handleCropRectEvent indica que __cropping window__which se comunica al usuario. Por lo general, esto no requiere una reasignación de búfer.
drainOneOutputBuffer copiará el marco decodificado en el búfer del puerto de salida y notificará al llamador sobre la disponibilidad del búfer decodificado.
En onQueueFilled , después de una decodificación satisfactoria, el búfer de entrada que se ha consumido también se devuelve al llamante.
El resto de las funciones son muy sencillas y creo que podría simplemente reutilizar la mayoría de la implementación.
Para el registro del componente, tendrá que implementar createSoftOMXComponent que crea el componente SoftHEVC como se muestra aquí .

Dado que, ya ha manejado el componente registrado, estoy saltando esa parte. Sólo por referencia, supongo que ha registrado el componente en la matriz SoftOMXPlugin en SoftOMXPlugin . Además, ya que HEVC no es un tipo MIME conocido, tendría que registrar el mismo. Habría un cambio requerido en MediaDefs.cpp donde tendrá que introducir una nueva entrada, MEDIA_MIMETYPE_VIDEO_HEVC similar a los formatos existentes como AVC y soportar cambios en OMXCodec.cpp y ACodec.cpp .

Con estos pasos, presumo que debería ser capaz de integrar su decodificador SW y ser capaz de realizar su reproducción.