Pregunta

Estoy tratando de construir un ejecutable C ++ / CLI al que enlazo estáticamente ffmpeg (libavcodec, libavformat, libavutil & amp; swscale). Funciona bien si lo compilo normalmente (sin / clr, por lo que no es compatible con CLR), funciona. Sin embargo, cuando agrego soporte CLR, no se iniciará con un 0xc000007b. A " Hola Mundo " Sin embargo, la aplicación C ++ / CLI funciona bien.

Supuestamente sucede lo mismo con Boost :: Threads, pero dado que ffmpeg es puro C, dudo que esté usando Boost.

Mi configuración:

  • Visual Studio 2008 Professional SP1
  • Windows XP Pro SP3 (x86)
  • .NET Framework 3.5 SP1

Gracias Robert

¿Fue útil?

Solución

Es posible que no use boost, pero probablemente usa hilos y almacenamiento local de hilos, lo que lleva al mismo problema. CLR no es compatible con __declspec (thread). Creo que no existe una solución simple, a menos que esté dispuesto a modificar el código ffmpeg (si es así, busque esas palabras clave en google para obtener ejemplos: clr, __declspec (thread)).

Sugiero aislar ffmpeg en un proceso diferente y usar algunos medios de comunicación entre procesos.

Otros consejos

He visto un problema similar que involucra DirectEditServices. La solución terminó por relacionarse con el tipo Thread Apartment. En .Net 2.0 y versiones posteriores, el tipo de apartamento de subprocesos predeterminado cambió de STA a MTA. Algunos objetos nativos de C ++ no son compatibles con MTA. Tuve éxito al generar un hilo y configurar manualmente el tipo de apartamento en STA. Tenga en cuenta que cualquier comunicación entre procesos con un objeto nativo de C ++ que no sea compatible con STA debe ocurrir en el hilo de STA que instancia el objeto.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top