Opened 13 years ago

Closed 13 years ago

Last modified 11 years ago

#144 closed defect (fixed)

ffmpeg 0.7c FFPLAY using CODEC_ID_H264 HUGE MEMORY LEAKS (1MB/s)

Reported by: alexandru Owned by:
Priority: normal Component: undetermined
Version: 0.7-rc1 Keywords: h264 leak
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

  1. I'm using ffmpeg 0.7c (your mt integrated version) taht I built with mingw32
  1. I run an h264 stream (a TV Channel) with ffplay on Windows , a full HD one (1920x1080), from DREAMBOX

the stream video-codec is :

h264 - mpeg4 avc (part 10) (h264) 1920x1080 frame rate 50

the audio codec is:

a52 audio (aca ac3) (a52) 7.1

(I confirm this information runing also the stream with vlc too)

  1. Command line : ffplay <h264-stream-url>

(I run also another HD TV Channel having the same memory leaks)

  1. BUG DESCRIPTION: during the playing, the memory quickly increased with aprox. 1MB/s, till the whole windows memory is exhausted after around 10-15min


  1. I put some debug trackings and comments in ffplay and compiling again, I saw that :
    1. - the used codec is CODEC_ID_H264
  1. - the place where additional memory is allocated is after each call to:

" len1 = avcodec_decode_video2(is->video_st->codec,

frame, &got_picture,
pkt);

"

Note: the pkt is always well deallocated in ffplay code

and the frame is deallocated only once at the of the loop in ffplay code, as usual)

  1. The memory leaks don't appear when playing non-hd channels (so when using other codecs)


  1. Viewing how huge is the memory leaks are (1MB/s) Seems that the AVFrame is set to some internal pictures that are never de-allocated

h264 decode_frame...

*pict = *(AVFrame*)h->next_output_pic;

But this is only a supposition, of course, could well be some other buffers...

  1. Practically the h264 codec cannot be used in this case.

and is the single way to play HD TV Channels due to the mt facility.

Change History (6)

comment:1 by Carl Eugen Hoyos, 13 years ago

Priority: criticalnormal
Status: newopen

Since I cannot reproduce your problem with a random H264/AC3/MPEG-TS file:

Is the memory usage only reproducible with ffplay or also with ffmpeg? (For example ffmpeg -i file -qscale 5 -acodec ac3 -ab 256k out.avi)
Is it also reproducible with -an or -vn?
Is it also reproducible with latest git master?

Please add complete, uncut output of ffmpeg (if the problem is also reproducible with ffmpeg) or ffplay (if the problem is only reproducible with ffplay).

(Afaik, ac-3 does not support more than six channels.)

in reply to:  1 comment:2 by alexandru, 13 years ago

Replying to cehoyos:

Since I cannot reproduce your problem with a random H264/AC3/MPEG-TS file:

I found the BUG in ffplay:

current video_thread function:
======================= CURRENT ffplay code =====================================

ret = get_video_frame(is, frame, &pts_int, &pkt);
pos = pkt.pos;

#endif

if (ret < 0) goto the_end;

if (!ret)

continue;

pts = pts_int*av_q2d(is->video_st->time_base);

ret = output_picture(is, frame, pts, pos);

#if !CONFIG_AVFILTER

av_free_packet(&pkt);

====================================================================

new video_thread function:
======================= CORRECTED ffplay code =====================================

ret = get_video_frame(is, frame, &pts_int, &pkt);
pos = pkt.pos;

alexandru_mg3 - BEGIN - NEW CODE
av_free_packet(&pkt);
alexandru_mg3 - END

#endif

if (ret < 0) goto the_end;

if (!ret)

continue;

pts = pts_int*av_q2d(is->video_st->time_base);

ret = output_picture(is, frame, pts, pos);

#if !CONFIG_AVFILTER

/* alexandru_mg3 - BEGIN - REMOVED CODE

av_free_packet(&pkt);

alexandru_mg3 - END
*/

....
====================================================================

NOTE: NEED TO FREE THE PACKET EVEN FOR WHEN WE HAVE ERROR OR NEED TO IGNORE THEM

comment:3 by alexandru, 13 years ago

I tested ffplay, with the above correction, and there are no memory leaks now...on HD streams.

Please integrate this correction in ffplay.

comment:4 by Carl Eugen Hoyos, 13 years ago

Please add at least:
Complete, uncut output of ffplay, information if the problem is reproducible with latest git HEAD and a unified diff for your patch (as produced for example by git diff ffplay.c).

comment:5 by Michael Niedermayer, 13 years ago

Resolution: fixed
Status: openclosed

Thanks for the debuging. Changes integrated locally will push soon.

comment:6 by Carl Eugen Hoyos, 11 years ago

Keywords: leak added; memory leaks removed
Note: See TracTickets for help on using tickets.