Actualización: Creo que lo he resuelto. Como ya tenía MCEBuddy ejecutándose en modo de línea de comandos, el “command=engine --action=start” estaba generando un error.
Cuando elimino esa línea, funciona perfectamente. Espero que esto ayude a alguien
Parece que tu controlador gráfico está teniendo un problema al inicializarse. Parece que hay una fuga de memoria:
2019-07-08T21:11:38 MCEBuddy.AppWrapper.FFmpeg → [hevc_nvenc @ 0000020a974c89c0] OpenEncodeSessionEx falló: sin memoria (10)
2019-07-08T21:11:38 MCEBuddy.AppWrapper.FFmpeg → [hevc_nvenc @ 0000020a974c89c0] No se encontraron dispositivos NVENC capaces
Intenta reiniciar tu sistema; si empieza a funcionar, entonces tu controlador gráfico tiene una fuga lenta que con el tiempo hace que se quede sin memoria. Tal vez prueba a bajar a una versión anterior/más estable.
Recordé que había descargado una versión de desarrollo de FFMpeg; probé reemplazarla por la versión 4.13 y hasta ahora no he tenido problemas.
Estoy usando la versión Studio de los controladores de NVidia; se supone que son más estables, ¡pero quizá solo necesito encontrar una configuración y mantenerla!
Después de recibir otra ronda de errores, volví a los controladores NVidia 4.19x: no he tenido problemas desde entonces.
Algo que me desconcierta: he procesado más de 90 archivos a través de la interfaz gráfica y no he encontrado problemas con la misma configuración y controladores. ¿Por qué la interfaz gráfica no muestra el problema de memoria, mientras que la línea de comandos o la invocación mediante script sí?
¿Tienes el enlace a los controladores para poder incluirlo en el post fijo?
¿Cambiaste el modo de ejecución del motor? La única vez que podrías notar una diferencia es si el motor se ejecuta como servicio en lugar de como motor de línea de comandos. Esto se debe a la forma en que Windows inicia ffmpeg. En el contexto del kernel, los controladores gráficos se comportan de manera diferente que en el contexto de usuario. Esta es una limitación de la arquitectura de Windows/controladores.
Las API de hardware gráfico suelen estar diseñadas para el contexto de usuario (por ejemplo, juegos o aplicaciones de diseño que se ejecutan desde el contexto de usuario). La mayoría de las aplicaciones de kernel no utilizan API de aceleración por hardware gráfico (porque no tienen interfaces de usuario nativas), por lo que hasta Windows 8 el kernel no ofrecía esas API gráficas a las aplicaciones e incluso después de Windows 8, la mayoría de los proveedores de gráficos no se molestan en probarlas adecuadamente en el espacio del kernel.
Todavía recibo errores, pero creo que puede deberse a que volví al modelo de servicio en lugar de la línea de comandos. Aquí está el enlace al controlador heredado: Driver Details | NVIDIA