[gst-devel] reducing memory usage in avidemux

[Stefan Kost]

Hi Ronald,

the patch we have is dropping all the index entries that are not  
marked as KEYFRAMES. The problem is that this patch is a 1500 line  
diff to the gstreamer gvidemuxer because of the of the feature I  
questioned in
http://bugzilla.gnome.org/show_bug.cgi?id=407433.
Because of the index chopping, the index is layed out so that offset  
point right to the data part in the stream. The actual streaming part  
is not reading {id,size} blocks.
If we trimm the index, we can only use the index to find a  
continuation point and then parse the stream (that is read {id,size}  
headers.

I trust you when you say that the massage_index() feature is needed. I  
remeber your efforts in the 0.8 time. I just wonder if the queue  
elements that one put after each demux pad would also solve the issue.  
I will try to find such a file.

One possible sulution might be to add another flag. Right now we mark  
index some entries as KEYFRAMES. Why not mark some as GENERATED. If  
they are generated, then the streaming code should not read the  
{id,size} headers, but use the values from the index and also advance  
the index (continue doin this until it hits a non generated one).

Stefan

Quoting "Ronald S. Bultje" <rbultje at ronald.bitfreak.net>:

> On Mon, 2007-02-12, tim Muller wrote:
>> 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?
>
> Don't know what codecs the above-mentioned file uses, but at first
> sight, audio appears to be the main problem. For a full hour of video,
> 30fps, you wouldn't see more than 60*60*30 index entries, which is ~50k,
> leaving ~400k for for audio. For video, still, at least all the
> non-keyframe ones could be ignored, leaving (say 1 keyframe per second)
> only 60*60 (3,6k). For playback, you don't need the audio ones
> otherwise, since the video one always lags, so all audio ones apart from
> the ones right after each keyframe (~1/s again) can be ignored, which
> would decrease this to ~7,2k, or a decrease by ~98,5%. For editing, a
> special "keep-all-indexes" could be created to keep them all and trash
> your memory as requested.
>
> cheers,
> Ronald
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your   
> job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>