[gst-devel] reducing memory usage in avidemux
Stefan Kost
ensonic at hora-obscura.de
Mon Feb 12 17:12:26 CET 2007
Hi,
Quoting Tim Müller <t.i.m at zen.co.uk>:
> On Fri, 2007-02-09 at 12:39 +0100, Stefan Kost wrote:
>
>> I have an avi that is 300 mb. Unfortunately it has 446774 index
>> entries. One index entry uses 52 bytes. Therefore the index needs
>> 23232248 bytes, .... (snip micro-optimising)
>> Any comments?
>
> So that's one index entry for roughly every 700 bytes of data, right?
> Couldn't the demuxer just drop every, say, second index entry when it
> detects something like this, or does it really need to save all of them?
Yes, I have a patch that does something simillar here, but its
painful. The data in the avi looks like this:
header {id,size}, data
header [id,size}, data
In the current avidemuxer the index is created so, that the offset
points to the data, it would not read the header. The reason is that
there are possibly also files with one hige index entry and the
avidemuxer has code (from gst-0.8 times) that cuts it into smaller
chunks, namly entries pointing into data. Now its questionable to me
that this works with all decoders (maybe for raw data its okay), I
will try to see if I have any of those files. The addition was made by
Ronald.
The patch that we have at Nokia adds a kind of parallel avi reading
(during playback) that drops some of the index entries, but then also
parses the headers. It will play, by reading entry for entry. This is
more sane imho. Currently that patch drops all but entries marked as
keyframes. I wonder if there is a better metric to limmit the index
size.
Stefan
More information about the gstreamer-devel
mailing list