Integración personalizada de Codecs Wrapper en Android

Necesito desarrollar un códec de vídeo personalizado 'envoltorio' e integrarlo en android (JB por ahora, ICS más adelante). Queremos utilizar algunas claves de descifrado personalizadas de la tarjeta SIM (no pregunte!). El mejor método (que le permitiría trabajar junto a otros medios no cifrados y usar el reproductor de medios estándar u otro) parece ser definir nuestro propio tipo mime y vincularlo a un códec de envoltura personalizado que puede hacer la costumbre Descifrado, y luego pasar los datos a un codec real. (Digamos que el tipo de archivo es .mp4 por ahora.)

(Una alternativa podría ser escribir nuestro propio reproductor de medios, pero preferimos no ir por esa ruta porque realmente queremos que los medios aparezcan sin problemas junto a otros medios)

He estado intentando seguir esta guía: cómo integrar un decodificador en el marco multimedia

Estoy teniendo problemas con el registro OMX Core – Puedo construir el libstagefright.so desde la fuente android escribiendo make stagefright pero en la guía dice que use el libstagefrighthw.so que parece apropiado para JB, pero no estoy seguro de cómo Para construir esto, no parece ser construido de usar make stagefright menos que estoy haciendo algo mal?
El otro problema es que incluso si consigo el códec incorporado de la envoltura registrado, no estoy seguro cómo ir sobre pasar los datos apagado a un códec verdadero.

Si alguien tiene alguna sugerencia (o puede dar algunas instrucciones paso a paso de bebé!), Realmente lo apreciaría – el plazo es bastante ajustado para la prueba de concepto y sé muy poco sobre codecs o el marco de medios de comunicación …

Muchas gracias. (Ps No quiero entrar en una lucha de barro sobre drm y agujeros analógicos etc .., gracias)

En este post, estoy utilizando H.264 como un ejemplo, pero la solución puede extenderse para apoyar otros codecs como MPEG-4 , VC-1 , VP8 , etc Hay 2 posibles soluciones para resolver su problema, que Me estoy enlistando a continuación, cada uno con sus propios pros y contras para ayudarle a tomar una decisión informada.

Solución 1: Extender el códec para admitir el nuevo modo

En JellyBean , se podía registrar el mismo componente OMX con los mismos tipos MIME que 2 nombres de componentes diferentes a saber, OMX.ABC.XYZ y OMX.ABC.XYZ.secure . El primero se utiliza para la reproducción normal y es el componente más comúnmente utilizado. Este último se utiliza cuando el analizador, es decir, MediaExtractor indica la presencia de contenido seguro . En OMXCodec::Create , después de findMatchingCodecs devuelve una lista de codecs, podemos observar la opción de seleccionar el componente .secure como aquí .

Pasos a seguir:

En su plataforma, registre otro componente con alguna nueva extensión como OMX.H264.DECODER.decrypt o algo similar. El cambio solo se requiere en media_codecs.xml . La opción de registrar un nuevo método de fábrica o tener un método de fábrica común es su elección.
Desde su analizador, cuando se encuentra con el caso de uso específico, establezca un nuevo indicador como kKeyDecryptionRequired . Para ello tendrá que definir una nueva bandera en Metadata.h y una peculiaridad correspondiente en OMXCodec.h .
Modifique el método OMXCodec::create para anexar un sufijo .decrypt similar al sufijo .secure como se muestra arriba.
Con todos los cambios en OMXCodec , Metadata , módulos de MediaExtractor , tendrá que reconstruir sólo libstagefright.so y reemplazar el mismo en su plataforma.

Voila !! Su integración debe ser completa. Ahora viene el principal desafío dentro del componente. Como parte de la implementación de componentes, debe ser capaz de diferenciar entre una creación de componentes ordinarios y la creación de componentes .decrypt .

Desde una perspectiva de tiempo de ejecución, suponiendo que su componente es consciente del hecho de que es un componente .decrypt o no, podría manejar el decryption como parte de la llamada OMX_EmptyThisBuffer , donde podría descifrar los datos y luego pasarlo al códec subyacente.

Pros: fácil de integrar, cambios mínimos en el marco de Android, escalable a otros códecs, no requiere registro de tipo MIME nuevo.

Contras: Es necesario realizar un seguimiento de las futuras revisiones de android, específicamente en las nuevas peculiaridades, banderas y la elección de la extensión .decrypt . Si Google decide emplear algo similar, tendrá que adaptar / modificar su solución en consecuencia.

Solución 2: Registro de nuevo tipo MIME

De su pregunta, no está claro si fue capaz de definir el tipo MIME o no y por lo tanto, estoy captando los pasos para mayor claridad.

Pasos a seguir:

Registre un nuevo tipo MIME en MediaDefs como se muestra aquí . Por ejemplo, puede emplear un nuevo tipo MIME como const char *MEDIA_MIMETYPE_VIDEO_AVC_ENCRYPT = "video/avc-encrypt";
Registre su nuevo componente con este tipo MIME actualizado en media_codecs.xml . Tenga en cuenta que tendrá que asegurarse de que las peculiaridades de los componentes también se manejan en consecuencia.
En la implementación del método OMXCodec::setVideoOutputFormat , tendrá que introducir el soporte para manejar su nuevo tipo MIME como se muestra para H.264 aquí . Tenga en cuenta que tendrá que gestionar cambios similares en OMXCodec para admitir el nuevo tipo MIME .
En MediaExtractor , tendrá que señalar el tipo MIME para la pista de video utilizando el tipo recién definido. Con estos cambios, su componente será seleccionado y creado.

Sin embargo, el reto sigue siendo: ¿Dónde realizar el descifrado? Para ello, también podría emplear la misma solución que se describe en la sección anterior, es decir, manejar el mismo como parte de la llamada OMX_EmptyThisBuffer .

Pros: Ninguno de los que pueda pensar ..

Contras: En primer lugar, la solución no es escalable. Tendrá que seguir añadiendo nuevos tipos MIME y seguir modificando el framework Stagefright . A continuación, los cambios en OMXCodec requerirán cambios correspondientes en MediaExtractor . Por lo tanto, aunque su enfoque inicial está en el extractor de MP4 , si desea extender la solución a otros formatos de contenedor como AVI , MKV , tendrá que incluir el soporte para los nuevos tipos de MIME en estos extractores.

Por último, algunas notas.

Como una solución preferida, recomendaría la solución 1, ya que es fácil y simple.
No he tocado en la implementación basada en ACodec del códec. Sin embargo, creo que la solución 1 sería una solución mucho más fácil de implementar, incluso si tal apoyo es necesario en el futuro.
Si no está modificando el núcleo OMX , no debe requerir modificar el libstagefrighthw.so . Sólo FYI, esto suele ser implementado por los proveedores como parte de sus módulos específicos del proveedor como en el vendor/<xyz>/hardware/... libstagefrighthw.so consultar con el proveedor de la plataforma las fuentes de libstagefrighthw.so .