GNOME Bugzilla – Bug 645502
[h264parse] leaks fatally on certain streams
Last modified: 2011-04-12 12:29:57 UTC
i wrote an app which remuxes ts to m2ts and generates a table of keyframes and their packet start offsets using mpegtsdemux, h264parse and mpegtsmux. while this works fine with a various set of hd dvb recordings, i found one where h264parse leaks memory so massively that the app gets killed after just a little (some 20ish MB on our embedded box). this is independent from that indexing that i've added to m2tsmux because it still happens when i set it to use the indexing and contrariwise doesn't like if i replace h264parse by a simple capsfilter. i'm working with git plus these extra patches of mine https://bugzilla.gnome.org/show_bug.cgi?id=644429 https://bugzilla.gnome.org/show_bug.cgi?id=644890 https://bugzilla.gnome.org/show_bug.cgi?id=645412 i'll upload a part of the delinquent movie stream
http://opendreambox.org/~fraxinas/20110316_0020_-_RTL_HD_-_Dr_House.ts
okay i'm setting g_object_set (G_OBJECT (app->queue_video), "max-size-buffers", 0, NULL); g_object_set (G_OBJECT (app->queue_video), "max-size-bytes", 0, NULL); g_object_set (G_OBJECT (app->queue_audio), "max-size-buffers", 0, NULL); g_object_set (G_OBJECT (app->queue_audio), "max-size-bytes", 0, NULL); in my code so it might as well be that. anyways, i need to find out why this streams causes the problems. maybe because it's High@L4.0 instead of Main and has a higher bitrate
gst-launch -v filesrc location="20110316_0020_-_RTL_HD_-_Dr_House.ts" ! mpegtsdemux name=d d. ! audio/x-ac3 ! queue2 max-size-buffers=0 ! m. d. ! video/x-h264 ! h264parse ! queue2 max-size-buffers=0 ! m. mpegtsmux name=m m2ts-mode=true ! fakesink
Running valgrind on some filesrc ! mpegtsdemux ! h264parse ! fakesink variant, I would say there never was "fatal" leaking, and that some small leaking has been handled by following commits: commit cfb22fe9858ba6ad776d57af034b8a2d278ed7be Author: René Stadler <mail@renestadler.de> Date: Thu Mar 24 21:46:09 2011 +0200 h264parse: free PPS NAL buffers on cleanup Obviously a typo. Fixes bug #645502. commit 3e4e198c5ed26c58d703b28eb417410b85e35370 Author: René Stadler <mail@renestadler.de> Date: Thu Mar 24 21:44:07 2011 +0200 h264parse: don't leak all NAL buffers gst_buffer_replace() doesn't steal the ref. Partial fix for bug #645502. commit 82a152533db90a1207dce352df4592c291b07e0f Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Tue Mar 22 13:18:03 2011 +0100 h264parse: chain up to parent finalize