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 741271 - rtph264pay: Buffer leak in H.264 payloader when using SPS/PPS
rtph264pay: Buffer leak in H.264 payloader when using SPS/PPS
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 1.4.5
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2014-12-08 20:24 UTC by Patrick Radizi
Modified: 2014-12-16 14:19 UTC
See Also:
GNOME target: ---
GNOME version: ---

Add missing unref in error handling. (1.07 KB, patch)
2014-12-08 20:34 UTC, Patrick Radizi
committed Details | Review

Description Patrick Radizi 2014-12-08 20:24:54 UTC
When using the rtph264pay element a buffer will leak if the pipeline is shutdown when a SPS/PPS header is being created. It's the buffer that would follow the SPS/PPS that is  leaked.
Comment 1 Patrick Radizi 2014-12-08 20:34:21 UTC
Created attachment 292331 [details] [review]
Add missing unref in error handling.
Comment 2 Sebastian Dröge (slomo) 2014-12-09 08:46:54 UTC
commit fef1a8d88a5e84421eae12b83ce4ae2d4fa329ec
Author: Patrick Radizi <>
Date:   Mon Dec 8 21:26:18 2014 +0100

    rtph264pay: Fixes buffer leak when using SPS/PPS
    Fixes a buffer leak that would occurr if the pipeline was shutdown
    while a SPS/PPS header was being created.
Comment 3 Patrick Radizi 2014-12-09 08:59:29 UTC
I just did some more tests and now it chrashed with the patch. I need to investigate it further
Comment 4 Sebastian Dröge (slomo) 2014-12-09 09:06:48 UTC
How does it crash for you? The patch seems correct, paybuf is unreffed (or taken over into the outbuf) in all other code paths, so would be leaked here on errors.
Comment 5 Patrick Radizi 2014-12-09 09:29:02 UTC
I thought it was ok to, but now it chrashes in gst_rtp_h264_pay_send_sps_pps:749 when it's inserting the PPS

GStreamer-CRITICAL **: gst_mini_object_unref: assertion `(g_atomic_int_get (&mini_object->lockstate) & LOCK_MASK) < 4' failed
Comment 6 Patrick Radizi 2014-12-09 13:53:30 UTC
I think the patch is ok. The problem seems to be that it changes the timing so that an 'old' bug is triggered. It only happens sometimes and is dependant on the debug level used.

I think that the commit 53ffd9e1cab086f334f94597973fdb0fcb175adc is the cause. Because of this commit two threads are simultaneously using rtph264pay->sps and rtph264pay->pps. One is the pipeline thread running in gst_rtp_h264_pay_send_sps_pps the other the thread doing the state change and calling gst_rtp_h264_pay_clear_sps_pps when going from paused to ready. 

Perhaps I'm missing something but I don't really understand why the return value of gst_rtp_h264_pay_payload_nal is ignored in gst_rtp_h264_pay_send_sps_pps, isn't this the cause of this problem?
Comment 7 Patrick Radizi 2014-12-11 09:34:17 UTC
I have created a new bug report of the chrash since it is a separate issue and that problem existed before:

The patch in this bug report (Comment 1) is thus ok and 'Comment 3' can be ignored.