GNOME Bugzilla – Bug 650323
[h264parse] leaks entire input if converting bytestream -> avc,au
Last modified: 2011-05-17 10:45:08 UTC
I launched this pipeline: gst-launch-0.10 filesrc location=clip.mts ! tsdemux ! h264parse ! matroskamux ! fakesink The pipeline gradually allocated enough memory to store the entirety of clip.mts (> 2GB, pushing my desktop into swap). No such behavior was observed with gst-launch-0.10 filesrc location=clip.mts ! tsdemux ! h264parse ! fakesink so I conclude that the bug is related to matroskamux.
Seems to be h264parse-related (works with legacyh264parse, fwiw): $ G_SLICE=always-malloc valgrind --suppressions=common/gst.supp --leak-check=yes ../gstreamer/tools/.libs/gst-launch-0.10 filesrc location=/home/tpm/samples/650323-clip.mts ! mpegtsdemux ! h264parse ! 'video/x-h264, stream-format=(string)avc, alignment=(string)au, width=(int)1920, height=(int)1080, parsed=(boolean)true' ! fakesink .... ==25730== ==25730== 3,644,375 bytes in 50 blocks are possibly lost in loss record 2,054 of 2,057 ==25730== at 0x4C2779D: malloc (vg_replace_malloc.c:236) ==25730== by 0x57BF392: g_malloc (gmem.c:164) ==25730== by 0x907FF3E: gst_adapter_take_internal (gstadapter.c:586) ==25730== by 0x9080EBA: gst_adapter_take_buffer (gstadapter.c:705) ==25730== by 0x9724400: gst_h264_parse_parse_frame (gsth264parse.c:745) ==25730== by 0x9087993: gst_base_parse_handle_and_push_frame.isra.8 (gstbaseparse.c:1613) ==25730== by 0x9088857: gst_base_parse_chain (gstbaseparse.c:2324) ==25730== by 0x97231D7: gst_h264_parse_chain (gsth264parse.c:1092) ==25730== by 0x4E9086B: gst_pad_push (gstpad.c:4685) ==25730== by 0x92D277F: gst_mpegts_demux_data_cb (gstmpegtsdemux.c:1203) ==25730== by 0x92DC39C: gst_pes_filter_push (gstpesfilter.c:564) ==25730== by 0x92D7EDD: gst_mpegts_demux_chain (gstmpegtsdemux.c:2144) ==25730== ==25730== 79,126,331 (362,304 direct, 78,764,027 indirect) bytes in 2,664 blocks are definitely lost in loss record 2,057 of 2,057 ==25730== at 0x4C2779D: malloc (vg_replace_malloc.c:236) ==25730== by 0x57BF392: g_malloc (gmem.c:164) ==25730== by 0x57D5FE6: g_slice_alloc (gslice.c:842) ==25730== by 0x57D6295: g_slice_alloc0 (gslice.c:854) ==25730== by 0x514DF5A: g_type_create_instance (gtype.c:1869) ==25730== by 0x4E85C31: gst_mini_object_new (gstminiobject.c:217) ==25730== by 0x4E60B60: gst_buffer_new (gstbuffer.c:334) ==25730== by 0x9080EC2: gst_adapter_take_buffer (gstadapter.c:707) ==25730== by 0x9724400: gst_h264_parse_parse_frame (gsth264parse.c:745) ==25730== by 0x9087993: gst_base_parse_handle_and_push_frame.isra.8 (gstbaseparse.c:1613) ==25730== by 0x9088857: gst_base_parse_chain (gstbaseparse.c:2324) ==25730== by 0x97231D7: gst_h264_parse_chain (gsth264parse.c:1092)
Indeed, noticed that recently: commit c203fd52e8cbbf7d1c71b4497750f59525c74c22 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Thu May 12 11:57:19 2011 +0200 h264parse: fix some buffer leaks Fixes #650323.