Hi,
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,
On 2018-03-20 08:25 PM, Nicolas Dufresne wrote:
> Le mardi 20 mars 2018 à 17:09 -0700, HT a écrit :
>> Under Ubuntu 14.04 with gstreamer 1.12, 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 one 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
>>
>> Actually, it gets a bit more complicated. If pid is a 3 digit
>> number,
>> no leaks are detected, i.e., this 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
>>
>> (Tried this with msdkh265 encoder, with similar results.)
>>
>> Any thoughts?
> Can you file a bug to bugs.gnome.org, produce GStreamer component gst-
> plugins-bad. I confirm I can reproduce the run-time leak here. It get
> freed when leaving, but memory is growing really fast.
>
> thanks,
> Nicolas
> _______________________________________________
> gstreamer-devel mailing list
>
[hidden email]
>
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Locked
signature.asc (981 bytes)