[gst-devel] e: reducing memory usage in avidemux

Ronald S. Bultje rbultje at ronald.bitfreak.net
Wed Feb 14 14:48:34 CET 2007

Hi Stefan,

On Feb 14, 2007, at 4:22 AM, Stefan Kost wrote:
> 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.

Of course, good point, I forgot about that.

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

I'm affraid not, b/c you still cannot seek. One option would be to  
select the frame _before_ the requested timestamp, which means you  
always seek back to 0 for the audio stream. I'm affraid this would  
lead to noticeable delay (how long does it take a modern time to  
decode 30min of mp3? A couple of seconds or so?) after each seek. You  
can probably also introduce a mp3 frame parser and drop all data up  
to the start timepoint after the seek, and then you only need to  
parse instead of decode, which would probably make it work OK.

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

Or just add new (guint32) fields (...) with offset-from-start-of- 
chunk and size-to-be-read-of-full-chunk so that deciding which stream  
to push data from (next frame in video stream or next generated  
"frame" in the audio stream?) would become easier. Although I guess  
you really don't want to add new fields at this point. But yes,  
something like this would probably be the best way to solve it,  
there's probably various ways to do it.


More information about the gstreamer-devel mailing list