| Message ID | CAGTf1M=xzVEvRPSNjt5URZDbPwCNpoEMxAhQ7F4-C-EjzTqchQ@mail.gmail.com |
|---|---|
| State | Accepted |
| Commit | 3ee735901e08213a46a5f7339ca86c43524d6994 |
| Headers | show |
I just verified that patch is working. Build FFmpeg master with and without patch, run HLS live stream from Youtube (extracted by youtube_dl for Euronews live). ffmpeg -i https://manifest.googlevideo.com/api/manifest/hls_playlist/id/V2E-jOUVsd4.1/itag/95/source/yt_live_broadcast/requiressl/yes/ratebypass/yes/live/1/cmbypass/yes/goi/160/sgoap/gir%3Dyes%3Bitag%3D140/sgovp/gir%3Dyes%3Bitag%3D136/hls_chunk_host/r4---sn-5hnedn7e.googlevideo.com/ei/E2sXXOrRGdjGgAe_6abgBA/gcr/nl/playlist_type/DVR/initcwndbps/12170/mm/32/mn/sn-5hnedn7e/ms/lv/mv/m/pl/24/dover/11/keepalive/yes/mt/1545038545/disable_polymer/true/ip/80.255.245.45/ipbits/0/expire/1545060211/sparams/ip,ipbits,expire,id,itag,source,requiressl,ratebypass,live,cmbypass,goi,sgoap,sgovp,hls_chunk_host,ei,gcr,playlist_type,initcwndbps,mm,mn,ms,mv,pl/signature/517F67575565239FC2D7117212AB722FB68BA3A6.4A8F847C14BF8C702103AEC348C8AC553E812ECE/key/dg_yt0/playlist/index.m3u8 -c copy -t 30000 -f mpegts -y NUL 2> _out.txt Checking process memory (private working set) in Task Manager Both instances start at 27MB RAM footprint. Patched version within a minute grows to 31 MB and then stable. Unmodified master RAM keeps growing, and after one hour reaches 90MB. Thus 59MB leak in an hour! And keeps growing... Youtube updates variant playlists app. every 2 seconds, with 3600 fragments each. Means leak of 8(bytes)*3600(pointers in prev_segments)*30*60(playlists per hour) = 54M - correlates with experimental results. Of course, youtube is an extreme case, but leak also degrades over time any live HLS input. Please review.
Ping...
Any maintainer willing to review/push straightforward one-liner patch?
> Thus 59MB leak in an hour! And keeps growing...
On 22/12/2018 14:54, Valery Kot wrote: > Ping... > Any maintainer willing to review/push straightforward one-liner patch? > >> Thus 59MB leak in an hour! And keeps growing... Can you add to the commit message to explain what exactly is changed and why? 'Fix leak' isn't very useful. Cheers, - Derek
Valery Kot <valery.kot@gmail.com> 于2018年12月22日周六 下午10:54写道： > > Ping... > Any maintainer willing to review/push straightforward one-liner patch? > > > Thus 59MB leak in an hour! And keeps growing... Testing. will response after one or two days, you can attention the comment by Derek, Thanks Valery Steven > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Sat, Dec 22, 2018 at 6:33 PM Derek Buitenhuis <derek.buitenhuis@gmail.com> wrote: > Can you add to the commit message to explain what exactly is > changed and why? 'Fix leak' isn't very useful. Submitted a patch (http://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/238093.html) with updated commit message, Or is there a way to edit commit message of an already sumitted patch? Valery
> 在 2018年12月24日，下午5:28，Valery Kot <valery.kot@gmail.com> 写道： > > On Sat, Dec 22, 2018 at 6:33 PM Derek Buitenhuis > <derek.buitenhuis@gmail.com> wrote: >> Can you add to the commit message to explain what exactly is >> changed and why? 'Fix leak' isn't very useful. > > Submitted a patch > (http://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/238093.html) > with updated commit message, Or is there a way to edit commit message > of an already sumitted patch? AFAIK no, i always resend patch :D Thanks Steven > > Valery > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
diff --git a/libavformat/hls.c b/libavformat/hls.c index 8ad08baaed..63e1abe789 100644 --- a/libavformat/hls.c +++ b/libavformat/hls.c @@ -931,6 +931,7 @@ static int parse_playlist(HLSContext *c, const char *url, prev_start_seq_no, pls->start_seq_no); } free_segment_dynarray(prev_segments, prev_n_segments); + av_freep(&prev_segments); } if (pls) pls->last_load_time = av_gettime_relative();
Patch for https://trac.ffmpeg.org/ticket/7610 hls.c:933 free_segment_dynarray(prev_segments, prev_n_segments); cleans all elements of prev_segments, but does not frees prev_segments array itself. As a result, process slowly leaks memory every time it updates playlist. Added call to av_freep(&prev_segments) From 90f3f7abd3561ef12404686dfac99940e8c5167e Mon Sep 17 00:00:00 2001 From: vkot <valery.kot@4cinsights.com> Date: Fri, 14 Dec 2018 13:38:05 +0100 Subject: [PATCH] Fix memory leak in hls.c --- libavformat/hls.c | 1 + 1 file changed, 1 insertion(+)