Memory leaks in melt CLI with and without input

Commit: 6b2310240433960b59b4f6f1f4945dfc9bd0462d
CMAKE_BUILD_TYPE: Debug
Sample used: https://samples.mplayerhq.hu/MXF/Quantel%20widescreen%20test.mxf
Valgrind output edited for brevity. Running melt so that it only prints usage:

$ valgrind --leak-check=full --suppressions=suppress melt
HEAP SUMMARY:
    in use at exit: 253,582 bytes in 584 blocks
  total heap usage: 4,754 allocs, 4,170 frees, 1,177,549 bytes allocated

4,046 (32 direct, 4,014 indirect) bytes in 1 blocks are definitely lost in loss record 262 of 269
   at 0x483AB65: calloc (vg_replace_malloc.c:760)
   by 0x486E200: mlt_properties_new (mlt_properties.c:123)
   by 0x4876DD7: mlt_repository_init (mlt_repository.c:73)
   by 0x485E619: mlt_factory_init (mlt_factory.c:209)
   by 0x10CD35: main (melt.c:921)

LEAK SUMMARY:
   definitely lost: 32 bytes in 1 blocks
   indirectly lost: 4,014 bytes in 15 blocks
     possibly lost: 0 bytes in 0 blocks
   still reachable: 1,952 bytes in 22 blocks
                      of which reachable via heuristic:
                        newarray           : 1,536 bytes in 16 blocks
        suppressed: 247,584 bytes in 546 blocks

With actual input:

$ valgrind --leak-check=full --suppressions=suppress melt -producer avformat:Quantel\ widescreen\ test.mxf out=1 -consumer null terminate_on_pause=1
HEAP SUMMARY:
    in use at exit: 353,220 bytes in 1,289 blocks
  total heap usage: 22,616 allocs, 21,327 frees, 101,383,279 bytes allocated

32 bytes in 2 blocks are definitely lost in loss record 126 of 304
   at 0x483AB65: calloc (vg_replace_malloc.c:760)
   by 0x485CF27: mlt_deque_init (mlt_deque.c:64)
   by 0x802963C: ???
   by 0x80273B7: ???
   by 0x8024B90: ???
   by 0x48772D2: mlt_repository_create (mlt_repository.c:248)
   by 0x485E904: mlt_factory_producer (mlt_factory.c:345)
   by 0xF79C555: ???
   by 0xF79CC01: ???
   by 0x48772D2: mlt_repository_create (mlt_repository.c:248)
   by 0x485E904: mlt_factory_producer (mlt_factory.c:345)
   by 0xF79D035: ???

32 bytes in 2 blocks are definitely lost in loss record 127 of 304
   at 0x483AB65: calloc (vg_replace_malloc.c:760)
   by 0x485CF27: mlt_deque_init (mlt_deque.c:64)
   by 0x8029651: ???
   by 0x80273B7: ???
   by 0x8024B90: ???
   by 0x48772D2: mlt_repository_create (mlt_repository.c:248)
   by 0x485E904: mlt_factory_producer (mlt_factory.c:345)
   by 0xF79C555: ???
   by 0xF79CC01: ???
   by 0x48772D2: mlt_repository_create (mlt_repository.c:248)
   by 0x485E904: mlt_factory_producer (mlt_factory.c:345)
   by 0xF79D035: ???

2,144 bytes in 2 blocks are definitely lost in loss record 288 of 304
   at 0x483AEB8: memalign (vg_replace_malloc.c:906)
   by 0x483AFCE: posix_memalign (vg_replace_malloc.c:1070)
   by 0x900BB64: ???
   by 0x9873E33: ???
   by 0x802A19C: ???
   by 0x8029614: ???
   by 0x80273B7: ???
   by 0x8024B90: ???
   by 0x48772D2: mlt_repository_create (mlt_repository.c:248)
   by 0x485E904: mlt_factory_producer (mlt_factory.c:345)
   by 0xF79C555: ???
   by 0xF79CC01: ???

2,144 bytes in 2 blocks are definitely lost in loss record 289 of 304
   at 0x483AEB8: memalign (vg_replace_malloc.c:906)
   by 0x483AFCE: posix_memalign (vg_replace_malloc.c:1070)
   by 0x900BB64: ???
   by 0x9873E33: ???
   by 0x802FC75: ???
   by 0x803020E: ???
   by 0x80303F4: ???
   by 0x486B9EE: producer_get_frame (mlt_producer.c:663)
   by 0x4878735: mlt_service_get_frame (mlt_service.c:581)
   by 0x486BC2E: producer_get_frame (mlt_producer.c:714)
   by 0x4878735: mlt_service_get_frame (mlt_service.c:581)
   by 0x486A1F6: producer_get_frame (mlt_playlist.c:2066)

2,316 (2,144 direct, 172 indirect) bytes in 2 blocks are definitely lost in loss record 290 of 304
   at 0x483AEB8: memalign (vg_replace_malloc.c:906)
   by 0x483AFCE: posix_memalign (vg_replace_malloc.c:1070)
   by 0x900BB64: ???
   by 0x9873E33: ???
   by 0x802D1A1: ???
   by 0x802DE6B: ???
   by 0x80303DE: ???
   by 0x486B9EE: producer_get_frame (mlt_producer.c:663)
   by 0x4878735: mlt_service_get_frame (mlt_service.c:581)
   by 0x486BC2E: producer_get_frame (mlt_producer.c:714)
   by 0x4878735: mlt_service_get_frame (mlt_service.c:581)
   by 0x486A1F6: producer_get_frame (mlt_playlist.c:2066)

4,046 (32 direct, 4,014 indirect) bytes in 1 blocks are definitely lost in loss record 293 of 304
   at 0x483AB65: calloc (vg_replace_malloc.c:760)
   by 0x486E200: mlt_properties_new (mlt_properties.c:123)
   by 0x4876DD7: mlt_repository_init (mlt_repository.c:73)
   by 0x485E619: mlt_factory_init (mlt_factory.c:209)
   by 0x10CD35: main (melt.c:921)

LEAK SUMMARY:
   definitely lost: 6,528 bytes in 11 blocks
   indirectly lost: 4,186 bytes in 17 blocks
     possibly lost: 0 bytes in 0 blocks
   still reachable: 1,952 bytes in 22 blocks
                      of which reachable via heuristic:
                        newarray           : 1,536 bytes in 16 blocks
        suppressed: 340,554 bytes in 1,239 blocks

Suppressions used:

{
   Ignore dlopen bug.
   Memcheck:Leak
   ...
   fun:_dl_open
   ...
}
{
   Ignore dlopen bug.
   Memcheck:Leak
   ...
   fun:_dl_init
   ...
}

Reproduce the two Valgrind commands from the issue, then inspect mlt_properties_new in mlt_properties.c, mlt_deque_init in mlt_deque.c, mlt_repository_create in mlt_repository.c, and the initialization path at melt.c:921. Trace the reported allocations through producer_get_frame and the playlist path. Done means the reported leaks are addressed and the same Valgrind runs show no corresponding definite leaks.