[gst-devel] reducing memory usage in avidemux

Stefan Kost ensonic at hora-obscura.de
Mon Feb 12 17:12:26 CET 2007


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  
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  


More information about the gstreamer-devel mailing list