GNOME Bugzilla – Bug 686327
mpegtsmux: fix refcount issue with input buffers
Last modified: 2012-11-13 14:34:19 UTC
Created attachment 226680 [details] [review] Fix refcount issue with input buffers It seems there is refcount error in stream_data_new and mpegtsmux is segfault with both schroenc and x264enc with the following pipeline: gst-launch-1.0 videotestsrc ! x264enc ! mpegtsmux ! fakesink (gst-launch-1.0:6206): GStreamer-CRITICAL **: gst_mini_object_unref: assertion `mini_object->refcount > 0' failed Program received signal SIGTRAP, Trace/breakpoint trap. [Cambiando a Thread 0x7ffff3b4b700 (LWP 6225)] 0x00007ffff75a3f95 in g_logv () from /home/andoni/cerbero/dist/linux_x86_64/lib/libglib-2.0.so.0 (gdb) bt
+ Trace 231056
This doesn't look like a good idea, as it seems that all buffers are leaked now.
GstCollectPads unref the input buffer, so it seems correct incrementing the reference count in stream_data_new as proposed in the patch. But still, it seems there is a memory leak somewhere else.
> GstCollectPads unref the input buffer Where does it do that? And input buffer to which function?
I think this may correlate with a problem Andreas was complaining about
Created attachment 226927 [details] [review] mpegtsmux: Don't make the same buffer writable twice. Fixes Bug 686327 - mpegtsmux: fix refcount issue with input buffers
The patch is incorrect in that CollectPads passes a refcount to the buffer when the callback is executed (it pops the buffer from the pad, and then passes it to mpegtsmux). The actual problem lies in the custom buffer clip function, where it calls gst_buffer_make_writable on the same input pointer twice - the first time gives away the reference to that buffer. Fix pushed.
*** Bug 686543 has been marked as a duplicate of this bug. ***