mp4mux lets the memory usage increase to a huge size

[Tim-Philipp Müller]

On Thu, 2011-07-14 at 17:30 +0200, Eugen Funk wrote:

Hi,

> I was happy today to manage to mux my h264 stream according to iso
> standards.
> But now I have a new, also serious problem:
> During the run of my pipeline:
> 
> gst-launch-0.10 -e -v --gst-debug-level=3 \
> souphttpsrc  do-timestamp=true is-live=true typefind=true location=http://192.168.2.21/image1 ! \
> video/x-h264, width=1280, height=720, framerate=30/1 ! \
> h264parse config-interval=1 ! mp4mux !  \
> filesink location=original.mp4

> I see the momory usage increase until my swap partition is full and everything breaks. (total size for gst-launch: 6 GB)
> 
> I assume that the problem lies inside of mp4mux: When I use the pipeline
> 
> gst-launch-0.10 -e --gst-debug-level=3 \
> souphttpsrc  do-timestamp=true is-live=true typefind=true location=http://192.168.2.21/image1 ! \
> 
> video/x-h264, width=1280, height=720, framerate=30/1 ! \
> h264parse config-interval=1 ! fakesink
> 
> the amount of allocated memory becomes stable.
> Does anybody know some tricks to avoid that?
> 
> I already run valgrind and here is the result:
> 
> ==17263== LEAK SUMMARY:
> ==17263==    definitely lost: 60 bytes in 1 blocks
> ==17263==    indirectly lost: 240 bytes in 10 blocks
> ==17263==      possibly lost: 113,240 bytes in 888 blocks
> 
> ==17263==    still reachable: 206,032 bytes in 1,732 blocks

It could be a bug with the h264parse in the latest -bad release, which
is fixed in git (https://bugzilla.gnome.org/show_bug.cgi?id=650323) .
With fakesink h264parse will likely just operate in passthrough mode
while with mp4mux might be forced to convert.

Run valgrind with

 $ G_SLICE=always-malloc valgrind
--leak-check=yes /usr/bin/gst-launch-0.10 ...

(make sure to run against gst-launch-0.10 and not gst-launch)

 Cheers
  -Tim