Opened 13 years ago
Closed 9 years ago
#2937 closed defect (invalid)
avformat_new_stream() memory leak
| Reported by: | Jose Santiago | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | avformat |
| Version: | git-master | Keywords: | leak |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description
avformat_new_stream() calls avcodec_alloc_context3() which can allocate data that is not free'd by the manual freeing of the codec context done by ff_free_stream() which is called by avformat_free_context(). In particular the st->codec->priv_data is allocated, but not free'd. The attached patch modifies ff_free_stream() to call avcodec_close() to properly close the codec context allocated in avformat_new_stream() .
For instance in the following code:
AVFormatContext * formatCtx; AVCodec * codec; AVStream * avStream; AVOutputFormat * outputFormat; const char * shortName = "mpegts"; const char * outputURL = "file://somefile.ts"; outputFormat = av_guess_format(shortName, outputURL, NULL); assert(outputFormat != NULL); avformat_alloc_output_context2(&formatCtx, outputFormat, shortName, outputURL); assert(formatCtx != NULL); avio_open2(&formatCtx->pb, outputURL, AVIO_FLAG_WRITE, NULL, NULL); codec = avcodec_find_decoder(AV_CODEC_ID_H264); assert(codec != NULL); avStream = avformat_new_stream(formatCtx, codec); assert(avStream != NULL); avformat_write_header(formatCtx, NULL); av_write_trailer(formatCtx); avio_close(formatCtx->pb); formatCtx->pb = NULL; # Not all of the st[]->codec is free'd here. avformat_free_context(formatCtx);
Attachments (1)
Change History (8)
by , 13 years ago
| Attachment: | ffmpeg-muxer-memory-leak.patch added |
|---|
comment:1 by , 13 years ago
| Keywords: | memory removed |
|---|---|
| Priority: | important → normal |
Please send patches to the ffmpeg-devel mailing list where they will be reviewed.
(If you believe that this is not clearly explained on the New Ticket page, please tell us!)
comment:2 by , 13 years ago
OK. I sent the patch and the description to the ffmpeg-devel list.
comment:5 by , 10 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
comment:6 by , 9 years ago
| Resolution: | invalid |
|---|---|
| Status: | closed → reopened |
I think this is still a problem... maybe? I'm not very familiar with FFmpeg.
I posted a SO question about it. It's probably best viewed on SO, because there's external links in it and stuff - http://stackoverflow.com/questions/43389411/ - and overall it doesn't add much except for detail to the original report.
Is this a bug, or not?
If it's not a bug, how does one use the API in such a way that the problem doesn't arise?
Thanks,
--Tom
comment:7 by , 9 years ago
| Resolution: | → invalid |
|---|---|
| Status: | reopened → closed |
Please consider posting your question on the libav-user mailing list.
In general, reopening months-old tickets is rarely useful.



Patch to fix the muxer memory leak.