[FFmpeg-devel] [PATCH] ffplay's primary function is not to trigger OOM killer
Aurelien Jacobs
aurel
Thu Feb 19 22:00:10 CET 2009
Hi,
Commit r16484 introduced an infinite loop allocating memory in ffplay.
This is very efficient at filling memory and triggering the OOM killer.
The relevant part of the main loop now looks like this:
for(;;) {
[...]
if(url_feof(ic->pb)) {
av_init_packet(pkt);
[...]
packet_queue_put(&is->videoq, pkt);
continue;
}
ret = av_read_frame(ic, pkt);
if (ret < 0) {
[...]
break;
}
[...]
packet_queue_put(&is->videoq, pkt);
}
So when the demuxer read the last frame of the stream, the ByteIOContext
reaches EOF but av_read_frame() correctly return a positive value as it
actually read a full frame.
Then at next iteration of the main loop url_feof() is triggered, which
allocate a new packet and go back to the start of the loop, and
triggers url_feof() again, and so on.
The NULL packet injection was added to force delayed frames to be
output. So I'm not sure if it's the best solution, be we could simply
limit the number of NULL packet injection to 16. This should take care
of the most pathological h264 cases.
Attached patch implements this very simple solution.
It fixes issue806.
Sample to test this situation (just let it play until the end, it only
last a few seconds):
http://samples.mplayerhq.hu/Matroska/rm-in-mkv.mkv
Aurel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffplay_memory_filler.diff
Type: text/x-patch
Size: 698 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090219/53138418/attachment.bin>
More information about the ffmpeg-devel
mailing list