mp4mux lets the memory usage increase to a huge size

[mojontp]

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!

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

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


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[mojontp]

Hi Tim,

thank you very much for your response! It was a really good news for me to see, that it is probably a known problem.
And valgrind with suggested options indeed pointed me to the h264parser.

However, I could not compile the master branch of gst-plugins-bad  from source.

I setup an extra thread for this topic.
After I have new results about the memory leak problem I will put them here.

Thanks again for your valuable help!

[mojontp]

I hacked the sources from
http://gstreamer.freedesktop.org/src/gst-plugins-bad/
according to diff of the h264-bug

http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=c203fd52e8cbbf7d1c71b4497750f59525c74c22

and it works fine!
:)

Thanks again!