I am new to gstreamer but not to Linux/UNIX of other types.
I don't want to file a bug report if this is expected behavior, however,
if this should be reported I will be happy to follow up.
I am using Fedora 9 and have built with the latest stable gstreamer plus
base and good plugins source downloads in order to test with valgrind.
Using matroskamux from gst-plugins-good-0.10.10, also the Fedora
released versions which are older have the same behavior, I noticed the
process size increasing as buffers pass though. To make this easy to
reproduce I used this simple pipeline.
Process starts at ~ 700k and increases to 3.1 MBytes
Repeat the same line with 200,000 buffers and the final size is 5.4 MBytes
So that is about 2.3 MBytes / 100,000 buffers through matroskamux or
about 23 or maybe 24 bytes per buffer.
If the pipeline does not contain matroskamux then the process size does
not increase, tested to 1,000,000 buffers.
With the latest stable source I compiled and used the gst-uninstall
script to launch a shell and use the local libraries under my account.
From there I ran valgrind with memtest using detailed reporting against
the above pipeline and nothing is reported as a leak. The gst-launch
spends a considerable amount of time at final size until the pipeline
shutdown messages occur. I figure the final shut down of the pipeline is
actually cleaning up this memory.
My question is should this element actually behave this way? Once a
buffer is passed through a filter there should be no held reference. I
have suspicions about the gst_buffer_new_and_alloc in function
gst_matroska_mux_create_buffer_header() is not getting unreferenced
until the program ends but I don't know this code well enough yet. It
could also be something held in the matroska libraries?