[FFmpeg-trac] #7630(avformat:closed): Memory leak in avformat_free_context
FFmpeg
trac at avcodec.org
Wed Dec 19 20:06:26 EET 2018
#7630: Memory leak in avformat_free_context
-------------------------------------+------------------------------------
Reporter: Ace17 | Owner:
Type: defect | Status: closed
Priority: normal | Component: avformat
Version: unspecified | Resolution: invalid
Keywords: leak | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+------------------------------------
Comment (by Ace17):
Dear cehoyos, thanks for your comments.
>> avformat_write_header() will obviously allocate resources at least for
some formats:
I agree it's obvious that this function might allocate.
However it's non-obvious that it might require the caller to do an
explicit deallocation step (av_write_trailer).
Especially with file formats that don't have a trailer (e.g mpegts).
I'm sincere ; tracking down this leak took me three days!
>> These can only be freed by calling av_write_trailer(), how else could
this work?
I think it could work in the following way: avformat_free_context does the
deallocation itself, if needed.
This way, the avformat code has to keep track of whether something owned
(and only visible) by the AVFormatContext needs to be deallocated (at the
moment, the caller code has to do this).
Does it make sense?
Please don't dismiss this use case: there really are situations where you
want to cleanly destroy the app without keeping the output file (and, more
importantly, without writing more stuff to the filesystem, which might be
on a dying network). At the moment, the only way to do this is to let
avformat_free_context leak memory.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/7630#comment:3>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list