Created attachment 239511 [details] [review]
add a missing gst_sample_unref in qtdemux_tag_add_blob to solve the leak

There's a sample leak in qtdemux_tag_add_blob (qtdemux.c:8639) where the sample created by in line 8639 is never unreffed. This sample is added to the debug tag list with gst_tag_list_add. This function stores a copy of the sample (transfer-none). The author might have thought that it was a transfer-full hence didn't unref it.

Here's the relevant log info where the sample is created and added go demux's tag_list

0:00:00.567363657  8509      0x123e850 LOG                   sample gstsample.c:110:gst_sample_new: new 0x7f775c0043a0
0:00:00.567369811  8509      0x123e850 TRACE        GST_REFCOUNTING gstminiobject.c:360:gst_mini_object_ref: 0x7f77600239a0 ref 1->2
0:00:00.567376669  8509      0x123e850 TRACE        GST_REFCOUNTING gstminiobject.c:440:gst_mini_object_unref: 0x7f77600239a0 unref 2->1
0:00:00.567383982  8509      0x123e850 DEBUG                qtdemux qtdemux.c:8685:qtdemux_tag_add_blob:<qtdemux1> adding private tag; size 23, info application/x-gst-qt-_tim-tag, style=(string)iso;
0:00:00.567392442  8509      0x123e850 TRACE        GST_REFCOUNTING gstminiobject.c:360:gst_mini_object_ref: 0x7f775c0043a0 ref 1->2
0:00:00.567404329  8509      0x123e850 TRACE        GST_REFCOUNTING gstminiobject.c:360:gst_mini_object_ref: 0x7f775c0043a0 ref 2->3
0:00:00.567411881  8509      0x123e850 TRACE        GST_REFCOUNTING gstminiobject.c:440:gst_mini_object_unref: 0x7f775c0043a0 unref 3->2


when the demuxer gets destroyed, it lefts a dangling reference to the sample:

0:00:15.742385760  8509      0x104dd80 DEBUG       GST_ELEMENT_PADS gstelement.c:2751:gst_element_pads_activate:<qtdemux1> pad deactivation successful
0:00:15.742392880  8509      0x104dd80 TRACE        GST_REFCOUNTING gstminiobject.c:440:gst_mini_object_unref: 0x7f7760023120 unref 1->0
0:00:15.742410289  8509      0x104dd80 LOG               GST_BUFFER gstbuffer.c:507:_gst_buffer_free: finalize 0x7f7760023120
0:00:15.742417539  8509      0x104dd80 TRACE            GST_LOCKING gstminiobject.c:248:gst_mini_object_unlock: unlock 0x7f77600043d0: state 00010000, access_mode 4
0:00:15.742424057  8509      0x104dd80 TRACE        GST_REFCOUNTING gstminiobject.c:440:gst_mini_object_unref: 0x7f77600043d0 unref 1->0
0:00:15.742431616  8509      0x104dd80 DEBUG             GST_MEMORY gstmemory.c:86:_gst_memory_free: free memory 0x7f77600043d0
0:00:15.742438672  8509      0x104dd80 TRACE        GST_REFCOUNTING gstminiobject.c:440:gst_mini_object_unref: 0x7f776005d8a0 unref 1->0
0:00:15.742454473  8509      0x104dd80 TRACE        GST_REFCOUNTING gstminiobject.c:440:gst_mini_object_unref: 0x7f775c0043a0 unref 2->1

this bug end up leaking two samples per media played, in my case. since in my application several medias are played in sequence, this leads to a huge leak after a few days of execution.

The attached patch against v1.0.5 adds a gst_sample_unref at the end. It solved this bug, no sample leaks anymore.