Memory usage seems to be proportional to file size when playing m4a files.

[Lei Miao]

On Sun, Jan 19, 2014 at 4:17 AM, Sebastian Dröge
<sebastian at centricular.com>wrote:

> On Fr, 2014-01-17 at 17:58 -0500, Lei Miao wrote:
> > After reading Apple's QuickTime File Format Specification and digging
> > into gstreamer's code, I figured out what caused my problem.
> >
> > I should first point it out that when playing m4a files, the memory
> > usage of gstreamer is proportional to the time duration of the file, not
> > the file size.
> >
> > 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 buffer could be very big. For an m4a file
> > 6:11:46 long, I got:
> >
> > [...]
> >
> > Could somebody take a look at this issue and improve qtdemux? Any
> > comments/suggestions are appreciated.
>
> It could be improved by only loading a sparse version of that table
> (e.g. every second entry only) or by lazy-loading the table (i.e. only
> remember where it is and load whatever is needed when it is needed
> during seeking). Or a combination of both approaches (note: the second
> won't work very well in push mode).
>
> --
> Sebastian Dröge, Centricular Ltd - http://www.centricular.com
> Expertise, Straight from the Source
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
Thank you for the input. I created a case at bugzilla: *Bug 722639
<https://bugzilla.gnome.org/show_bug.cgi?id=722639>* to keep track of this
issue.

LM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140120/fc33c123/attachment.html>