GNOME Bugzilla – Bug 722639
qtdemux: Memory usage is proportional to the time duration of m4a files.
Last modified: 2018-11-03 14:51:01 UTC
QuickTime stores media data in samples. The number of a samples in m4a files are huge. For example, a 6hr m4a file has about 950,000 samples. Because qtdemux.c creates a sample table whose size is proportional to the number of samples, the sample table could be very big. For an m4a file 6:11:46 long, I got: "qtdemux qtdemux.c:6306:qtdemux_stbl_init:<qtdemux0> allocating n_samples 960669 * 32 (29.32 MB)" Indeed, qtdemux has a cap of 50MB for this table: /* if the sample index is larger than this, something is likely wrong */ #define QTDEMUX_MAX_SAMPLE_INDEX_SIZE (50*1024*1024) The current design has two problems for m4a files: 1. m4a files with duration greater than 12hrs won't play: qtdemux qtdemux.c:6306:qtdemux_stbl_init:<qtdemux0> allocating n_samples 1921335 * 32 (58.63 MB) qtdemux qtdemux.c:6312:qtdemux_stbl_init:<qtdemux0> not allocating index of 1921335 samples, would be larger than 50MB (broken file?) Such a file can be downloaded at: https://dl.dropboxusercontent.com/u/54923483/White_Noise_320kbps_14Hour.m4a 2. It may impose a memory burden for embedded systems. Could somebody take a look at this issue and improve qtdemux? Discussions of this issue can be found at : http://lists.freedesktop.org/archives/gstreamer-devel/2014-January/045660.html
I am suffering from a similar issue. I guess that this issue will be occurred for a live content if the playback keeps for a quite long time. qtdemux_parse_trun() { if (stream->n_samples >= QTDEMUX_MAX_SAMPLE_INDEX_SIZE / sizeof (QtDemuxSample)) goto index_too_big; }
same problem. I can't listen to audio books.
(In reply to Ted from comment #1) > I am suffering from a similar issue. > I guess that this issue will be occurred for a live content if the playback > keeps for a quite long time. MP4 does not really support "growing" live files, so that shouldn't be a problem. And if fragmented MP4 is used, the sample tables will be reset on each fragment. I think for push mode there is nothing we can do here, however for pull mode it could make sense to only parse and store a part of the sample table and when more is needed go back to the moov and parse the newly needed part while dropping the old one.
Bug fix from java.net: https://bugs.openjdk.java.net/browse/JDK-8096534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/102.