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: <pre>gst-launch-0.10 -e -v --gst-debug-level=3 \ souphttpsrc do-timestamp=true is-live=true typefind=true location=<a href="http://192.168.2.21/image1">http://192.168.2.21/image1</a> ! \ 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=<a href="http://192.168.2.21/image1">http://192.168.2.21/image1</a> ! \ 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! </pre>