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

[alexandru]

1. I'm using ffmpeg 0.7c (your mt integrated version) taht I built with mingw32

2. 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)

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

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

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

4. I put some debug trackings and comments in ffplay and compiling again, I saw that :
   1. - the used codec is CODEC_ID_H264

2. - 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)

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

4. 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...

5. 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.

[Carl Eugen Hoyos]

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.)

[alexandru]

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

[alexandru]

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

Please integrate this correction in ffplay.

[Carl Eugen Hoyos]

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).

[Michael Niedermayer]

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