Problema al llamar a ffmpeg.c dos veces que hace que la aplicación se bloquee?

Estoy tratando de llamar a ffmpeg.c para recortar un video basado en este código 'video-trimmer' . Así que cuando trato de ejecutar la actividad (que carga y utiliza la lib nativa) la primera vez que haga clic en trin funciona y yo podría recortar el video, pero cuando intento ejecutarlo de nuevo se bloquea (y sólo funciona con la aplicación se reinicia ).

Así que paso tres días buscando una solución para este problema, la mayoría de las respuestas dicen que el problema con las variables estáticas en ffmpeg.c y la creación de una lib que carga y descarga la clase corrige el problema ( answer1 , answer2 ). Así que traté de aplicar la solución que se basa en las respuestas y este reporte de github en el proyecto de recorte de vídeo, pero todos mis intentos fallaron.

¿Hay alguien sabe acerca de una bifurcación del proyecto 'video-trimmer' que corrige el problema ?. O alguien puede proporcionar paso a paso la respuesta de cómo implementar la solución en el proyecto de 'recortador de vídeo' (porque traté de seguir toda la solución en la web y aplicarlos en ese proyecto, pero sin suerte).

El problema parece estar con los valores inicializados (algunas variables se declaran como vars estáticos globales, presumiblemente para la facilidad de acceso, pero rompe los principios OOP y nos causa problemas como usted está enfrentando), sin embargo, hay algunas maneras alrededor de esto que yo Puede pensar en:

Escribir una función rápida para establecer manualmente los vars estáticos de nuevo a sus valores de init correctos (rápido y sucio, pero funciona). Una lista de los métodos que no se debe permitir encender como y cuando ellos por favor sigue:
- avcodec_register_all(), avdevice_register_all(), av_register_all()
- avcodec_find_encoder(), avcodec_find_decoder(), av_find_stream_info()
- avcodec_open(), avcodec_close()
  - Éstos podrían ser envueltos en un método controlado boolean por ejemplo de modo que si se han funcionado previamente no pueden funcionar otra vez.
Otra forma de controlar las cosas es forzar manualmente los valores de las variables (mediante el uso de una clase o estructura para controlar las vars globales de ffmpeg) que se están reinicializando en las ejecuciones subsiguientes, por ejemplo al ejecutar el método que actualmente provoca el fallo del código , El primer paso podría ser establecer manualmente las variables de nuevo a su configuración predeterminada para que se ejecuten correctamente como en el momento que sospecho que tiene los datos restantes residente entre iteraciones, y eso es lo que está causando problemas.
Puede utilizar mutexes para asegurarse de que los métodos antes mencionados se comportan de manera más responsable cuando se utilizan con subprocesos.

Apéndice:

También (en el nivel C) use libffmpeginvoke de preferencia a libffmpeg si va a invocar main () varias veces
Invocando a la fuerza Garbage Collection (esto es otro 'feo' arreglar) en la llamada para cargar la lib ffmpeg, que a continuación, limpiar las cosas que le permite llamar a otra instancia

Déjame saber si necesitas algo más en profundidad: Puedo intentar hacer un marco de prueba para replicar tus problemas y ver dónde obtienes, aunque eso necesita tener acceso a mi PC personal, como cuando estoy en el trabajo, no tengo SDK para Android.

Ayúdanos a ayudarte, proporcione tu código implementado o una parte de él. También Crash Log será útil.

Sugerencia: Inicialice el objeto / subproceso ffmpeg. A continuación, utilice una interfaz de devolución de llamada. Una vez que el VideoTrimmer se sobrepase, dé una devolución de llamada. En ese callback llama al destruir / matar el objeto / hilo ffmpeg.

Puede que este enlace le pueda ayudar.

Recientemente he usado el proyecto "android-ffmpeg-java" de github, esta es una biblioteca de trabajo, puedo garantizar. Sólo tienes que implementar un contenedor (aplicación de prueba) que hará el trabajo.
Compruebe este enlace para Fuente: android-ffmpeg-java
Compruebe este enlace por ejemplo: android-ffmpeg-cmdline . Vea si puede resolver con esto.

No estoy seguro de si esto ayudará, pero los archivos C suelen tener un encabezado donde se puede utilizar

Si no

Consulte lo siguiente: http://www.cprogramming.com/reference/preprocessor/ifndef.html

Utilice esa sintaxis para sandwhich la declaración en el archivo .h asociado para asegurar múltiples importaciones no causar un bloqueo en el código de importación.

¡Buena suerte!

Edit: Ok, parece que eso significaría recompilar ffmpeg al archivo .so. Usted sólo debe tratar de verificar que tiene un mecanismo como se describe anteriormente en la base de código y tratar de confirmar que no se carga de alguna manera dos veces.

Mientras que un poco crudo, una solución potencial podría ser utilizar / link a ffmpeg de un servicio (es mejor que lo esté haciendo de todos modos) que se declara en el manifiesto para ejecutar en su propio proceso en lugar de las actividades del cliente. A continuación, haga que el proceso termine – llamando a native exit () si es necesario – cuando la tarea está completamente terminada. Android no le gustará especialmente que suceda – no es una buena práctica – pero probablemente puede hacer que funcione.

Re-ingeniería de la biblioteca para poder restablecer a sí mismo a un estado fresco (o incluso hacer que sea totalmente contextual) sería mejor, pero para una enorme base de código legado puede llegar a ser un gran proyecto.