After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 631064 - Memory Usage increases considerably when using qtmux to record aac in mp4 format
Memory Usage increases considerably when using qtmux to record aac in mp4 fo...
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
0.10.20
Other Windows
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-10-01 05:08 UTC by Kunal Sinha
Modified: 2010-10-05 12:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Kunal Sinha 2010-10-01 05:08:43 UTC
1) Record a file using qtmux for aac in mp4 format using pipeline
  gst-launch -e audiotestsrc wave=0 ! faac ! qtmux ! filesink location=test.mp4 &

2) Check the memory usage using top command, the memory usage keeps on increasing.

3) As far as I have understood, we are queuing buffer in gstqtmux.c:gst_qt_mux_add_buffer() and appending trak samples on to AtomSTBL holding different trak structures' GList by calling atoms.c:atom_add_trak_samples(). I have a vague idea that this is for getting the duration.
[Please correct me if my understanding is wrong].

This can create problems in usecases where maximum heap size gets reached for example if we record for longer duration say 2-3 hours or even more.


Thanks
Kunal
Comment 1 Chris Shoemaker 2010-10-05 01:01:03 UTC
I confirm.  This leaks about 2MB/min. on my machine.
Comment 2 Mark Nauwelaerts 2010-10-05 12:40:48 UTC
atoms.c:atom_add_trak_samples() indeed collects metadata for each buffer. However, it does not do so (anymore) using GList (but a more compact array instead).  Also, it needs to keep track of more than simply durations (but also offsets, sizes, etc).  This is a bit more than usually required for other formats, but still quite feasible.  For instance, a typical AAC recording should use about 12 bytes per buffer, which amounts to give or take 36K/min.

Next, "min(ute)" is relative in the above examples.  Since the pipeline given above does not sync on the clock, it will run as fast as possible.  That is, 1 minute of execution time leads to a sample file very much longer than 1 minute (in which case metadata may add up to quite a bit).

Finally, running (e.g.)
----
valgrind --tool=massif gst-launch-0.10 -v audiotestsrc num-buffers=30000 samplesperbuffer=1024 ! audio/x-raw-int,rate=48000 ! faac ! mp4mux ! filesink location=test44.mp4
----
shows only minor (expected) heap increase (for a give or take 10min recording).