mp4mux lets the memory usage increase to a huge size

[Eugen Funk]

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


For details see attached file.
The releases of gstreamer and gst-plugins-good are 0.10.35 and 0.10.30.
I would really appreciate your help!


Thank you in advance!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20110714/e647b21f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: valgrind_gst.log
Type: text/x-log
Size: 221390 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20110714/e647b21f/attachment-0001.bin>