ffmpeg C API comportamiento extraño cuando se ejecuta

Preguntas Android
⏰ 6 minutos de lectura

Tengo un proyecto C++ que he estado usando durante un tiempo (ahora en una compilación estable), recientemente tuve una nueva configuración de Debian hace unos días y configuré todo. Configuré ffmpeg como siempre lo hago y algunos de mis otros proyectos que también dependen de ffmpeg parecen estar funcionando bien. Revisé ffplay y funciona, junto con los muchos videos de entrada diferentes con los que estoy probando. Sin embargo, cuando trato de ejecutar el proyecto mencionado, obtengo varios comportamientos extraños en diferentes videos. Por ejemplo: algunos de ellos dicen moov atom not foundalgunos de ellos arrojan una falla de segmento, otros simplemente bloquean el programa sin advertencias ni fallas de segmento ni nada.

Como he dicho, esta es una nueva compilación de Debian y el proyecto está funcionando bien en otras computadoras, incluida esta computadora antes de que obtuviera un Debian nuevo (también era Debian antes).

Así es como configuré ffmpeg:

  1. Extraiga ffmpeg de su página de github y pague hasta la última rama de compilación estable (5.1)
  2. Sudo instala dependencias como libx264-dev y nasm y algunas más
  3. correr ./configure --extra-libs="-lpthread -lm" --ld="g++" --disable-static --enable-shared --enable-gpl --enable-gnutls --enable-libfreetype --enable-nonfree --enable-libx264 --enable-opencl --enable-opengl
  4. correr makeentonces sudo make install y finalmente sudo ldconfig.

Sobre los errores:

  • Si no obtengo una falla de segmentación pero el programa simplemente falla sin ningún error, cuando ejecuto valgrind no dice nada (principalmente en archivos .mp4 y .avi). Así que corrí con el --leak-check=full flag y obtenga el siguiente resultado (recortado algo):
...
==220709== 132 bytes in 1 blocks are possibly lost in loss record 323 of 386
==220709==    at 0x483AB65: calloc (vg_replace_malloc.c:760)
==220709==    by 0x8C67DA0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.8)
==220709==    by 0x8BE51E4: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BE8589: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BCB531: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BC49C7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709==    by 0x40100E8: call_init (dl-init.c:30)
==220709==    by 0x40100E8: _dl_init (dl-init.c:119)
==220709==    by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==220709== 
==220709== 148 bytes in 1 blocks are possibly lost in loss record 327 of 386
==220709==    at 0x483AB65: calloc (vg_replace_malloc.c:760)
==220709==    by 0x8C67DA0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.8)
==220709==    by 0x8BE4FEA: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BE8589: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BD4B2B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BC49D1: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709==    by 0x40100E8: call_init (dl-init.c:30)
==220709==    by 0x40100E8: _dl_init (dl-init.c:119)
==220709==    by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==220709== 
==220709== 148 bytes in 1 blocks are possibly lost in loss record 328 of 386
==220709==    at 0x483AB65: calloc (vg_replace_malloc.c:760)
==220709==    by 0x8C67DA0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.8)
==220709==    by 0x8BE4FEA: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BE8589: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BCFBF3: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BC49D6: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709==    by 0x40100E8: call_init (dl-init.c:30)
==220709==    by 0x40100E8: _dl_init (dl-init.c:119)
==220709==    by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==220709== 
==220709== 184 bytes in 1 blocks are possibly lost in loss record 339 of 386
==220709==    at 0x483AD7B: realloc (vg_replace_malloc.c:834)
==220709==    by 0x8C67DE7: g_realloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.8)
==220709==    by 0x8BE3B76: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BE87AC: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BD67DE: g_param_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BD915A: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BC49DB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709==    by 0x40100E8: call_init (dl-init.c:30)
==220709==    by 0x40100E8: _dl_init (dl-init.c:119)
==220709==    by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==220709== 
==220709== 1,502 (352 direct, 1,150 indirect) bytes in 1 blocks are definitely lost in loss record 368 of 386
==220709==    at 0x4838DEF: operator new(unsigned long) (vg_replace_malloc.c:342)
==220709==    by 0x1D19819D: ???
==220709==    by 0x1D177ED3: ???
==220709==    by 0x1D18AAC9: ???
==220709==    by 0x1D1683B0: ???
==220709==    by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709==    by 0x40100E8: call_init (dl-init.c:30)
==220709==    by 0x40100E8: _dl_init (dl-init.c:119)
==220709==    by 0x4F82AEC: _dl_catch_exception (dl-error-skeleton.c:182)
==220709==    by 0x4014057: dl_open_worker (dl-open.c:758)
==220709==    by 0x4F82A8F: _dl_catch_exception (dl-error-skeleton.c:208)
==220709==    by 0x40138F9: _dl_open (dl-open.c:837)
==220709==    by 0x8D9B257: dlopen_doit (dlopen.c:66)
==220709== 
==220709== LEAK SUMMARY:
==220709==    definitely lost: 384 bytes in 3 blocks
==220709==    indirectly lost: 1,230 bytes in 20 blocks
==220709==      possibly lost: 1,352 bytes in 18 blocks
==220709==    still reachable: 189,789 bytes in 1,437 blocks
==220709==                       of which reachable via heuristic:
==220709==                         stdstring          : 1,845 bytes in 46 blocks
==220709==                         newarray           : 1,536 bytes in 16 blocks
==220709==         suppressed: 12 bytes in 1 blocks
==220709== Reachable blocks (those to which a pointer was found) are not shown.
==220709== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==220709== 
==220709== For lists of detected and suppressed errors, rerun with: -s
==220709== ERROR SUMMARY: 21 errors from 21 contexts (suppressed: 0 from 0)
  • Al momento de escribir esto, no pude replicar el error que recibí antes sobre cuando obtengo una falla de segmento. A partir de ahora, ya sea que obtenga o no una falla de segmento, estoy obteniendo el mismo resultado que el anterior.

¿Cuál podría ser la razón de ésto? ¿Estoy configurando mal ffmpeg?

  • No creo que el control de fugas proporcione ningún detalle útil. Sugeriría centrarse en reproducir un bloqueo y recopilar más información al respecto.

    – tetera418

    6 de febrero a las 10:34

  • @ teapot418 Estoy de acuerdo, es lo mejor que tengo, estoy haciendo todo lo posible para reproducirlo.

    – Turgut

    6 de febrero a las 11:10

  • Si sospecha que la biblioteca está saliendo de su programa (con exit?) prematuramente por alguna razón, puede intentar registrar un enlace atexit y hacer que se bloquee allí para obtener un seguimiento de volcado de núcleo/pila, etc.

    – tetera418

    6 de febrero a las 11:15

  • @ teapot418 No creo que ese sea el caso, una pista que obtuve es que una vez recibí un error de valgrind que me dijo que estaba en av_read_frame pero no estoy seguro y no he podido reproducirlo todavía. Mirando su código fuente en ffmpeg.org/doxygen/trunk/demux_8c_source.html parece que no hay salida.

    – Turgut

    6 de febrero a las 11:17

  • Cuál es el primero error que informa Valgrind? Ahí es donde debes empezar.

    –Paul Floyd

    6 de febrero a las 14:34

¿Ha sido útil esta solución?