[BUG] Memory leaks when containers are opened and decoded in a loop

[oakaigh]

It appears that the container, when opened in decoding mode, does not release memory immediately when garbage collected.
Very frustrating because in applications requiring high parallelism (such as deep learning), the memory usage builds up extremely fast unless Python's GC is set to a lower threshold.

And such issue has already been documented, since at least 9.0:
https://pyav.org/docs/9.0.2/overview/caveats.html#garbage-collection
https://pyav.basswood-io.com/docs/17.0/overview/caveats.html#garbage-collection

Resolving this should be on the priority list IMO.

Sample memray output for reference:

Test was allowed to leak 1.0MiB per location but at least one location leaked more
----------------------------- memray-leaked-memory -----------------------------
List of leaked allocations:
    - 8.2MiB allocated here:
        av_malloc:<unknown>:0
        av_mallocz:<unknown>:0
        avcodec_alloc_context3:<unknown>:0
        __pyx_pf_2av_9container_5input_14InputContainer___cinit__:src/av/container/input.c:4289
        __pyx_pw_2av_9container_5input_14InputContainer_1__cinit__:src/av/container/input.c:3827
        ...
    - 8.2MiB allocated here:
        av_malloc:<unknown>:0
        av_mallocz:<unknown>:0
        avcodec_alloc_context3:<unknown>:0
        <unknown>:<unknown>:0
        avformat_find_stream_info:<unknown>:0
        ...

[lgeiger]

@oakaigh Do you have a minimal reproducible example that shows the memory leak you mentioned above?

[oakaigh]

@lgeiger The script is similar to this, except the container is opened/closed in a loop and the video stream is encoded using h265. Running it through memray should give you the results posted earlier.

As for the reproducible example I have not gotten time to work on it yet. However I believe the above should be sufficient to make the problem appear.