GNOME Bugzilla – Bug 794551
Memory leak in mpegtsmux
Last modified: 2018-11-03 14:19:24 UTC
Under Ubuntu 14.04, specifying pids in mpegtsmux program-map, causes memory leak, e.g. the following pipeline leaks: (As seen by "top") gst-launch-1.0 videotestsrc is-live=true pattern=zone-plate kx2=20 ky2=20 kxy=4 kt2=10 ! video/x-raw, format=I420,width=1280,height=720 ! videoconvert ! openh264enc ! h264parse ! muxer.sink_49 mpegtsmux name=muxer prog-map=program_map,sink_49=1 ! fakesink Whereas, this pipeline does not: gst-launch-1.0 videotestsrc is-live=true pattern=zone-plate kx2=20 ky2=20 kxy=4 kt2=10 ! video/x-raw, format=I420,width=1280,height=720 ! videoconvert ! openh264enc ! h264parse ! mpegtsmux name=muxer ! fakesink It gets a bit more complicated: If pid is a 3 digit number, no leaks are detected, i.e., the folowing pipeline does not leak: gst-launch-1.0 videotestsrc is-live=true pattern=zone-plate kx2=20 ky2=20 kxy=4 kt2=10 ! video/x-raw, format=I420,width=1280,height=720 ! videoconvert ! openh264enc ! h264parse ! muxer.sink_149 mpegtsmux name=muxer prog-map=program_map,sink_149=1 ! fakesink (Similar results holds for msdkh265 encoder.)
Just to mention, I can reproduce this with x264enc + git master. The memory grows, but it won't leak it when stop the pipeline, just to make it more fun to chase.
It turns out the problem was due to invalid PID range: mpegtsmux.c/new_packet_common_init : ... if (!mux->streamheader_sent && data) { guint pid = ((data[1] & 0x1f) << 8) | data[2]; /* if it's a PAT or a PMT */ if (pid == 0x00 || (pid >= TSMUX_START_PMT_PID && pid < TSMUX_START_ES_PID)) { GstBuffer *hbuf; if (!buf) { hbuf = gst_buffer_new_and_alloc (len); gst_buffer_fill (hbuf, 0, data, len); } else { hbuf = gst_buffer_copy (buf); } GST_LOG_OBJECT (mux, "Collecting packet with pid 0x%04x (len=%d) into streamheaders", pid,len); g_queue_push_tail (&mux->streamheader, hbuf); } else if (!g_queue_is_empty (&mux->streamheader)) { ... i.e., video pids were indefinitely pushed into streamheader queue. In my case, removing condition following "||" is all I need. However, perhaps, checking on the size of the queue, and flushing, may be more appropriate. Cheers,
Any idea how to fix this properly ?
I suppose if the motivation is to ensure that the target pid is PMT, by restricting the rage between TSMUX_START_PMT_PID and TSMUX_START_ES_PID, then ensuring that pid is indeed PMT would be the proper course of action. Alternatively, replacing buf type with a circular buffer, of appropriate size, should fix the do the trick.
Has this bug been fixed? Did memory leak was constant or after some time?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/668.