After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 650323 - [h264parse] leaks entire input if converting bytestream -> avc,au
[h264parse] leaks entire input if converting bytestream -> avc,au
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal blocker
: 0.10.23
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-05-16 15:47 UTC by bens
Modified: 2011-05-17 10:45 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description bens 2011-05-16 15:47:36 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.
Comment 1 Tim-Philipp Müller 2011-05-16 16:58:31 UTC
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)
Comment 2 Mark Nauwelaerts 2011-05-17 10:45:08 UTC
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.