Andraz,
Alright then.  It just seemed odd to me that so much memory would be
used.  I will keep an eye on the VIRT and RES columns for Cinelerra
while I work on my project and let you know if the memory keeps rising
above 1GB.

scott

On Fri, 2007-02-09 at 22:57 +0100, Andraž Tori wrote:
> I don't know wat exactly you want to tell me...
> 
> btw: total memory used in top is wrong metric by any means.
> you should just be looking at VIRT and RES columns for each application,
> cinelerra in this case...
> 
> if "virt" number goes up to a gig or more and keeps going up, then
> something is wrong, if not, cinelerra is working ok... yes, it needs
> quite some memory
> 
> bye
> andraz
> 
> On Fri, 2007-02-09 at 16:42 -0500, Scott C. Frase wrote:
> > Hi Andraz,
> > I compiled v989.  I did a warm reboot of the box for a fresh start.  My
> > computer configuration specs are here:
> > http://content.serveftp.net/video/qtcompatibility.ods.html
> > 
> > I am using my project that I had described in my audio sync problem
> > post.  It has one 720P HDV (MPEGTS) video track with two stereo audio
> > tracks (one wav/one mp2) at 48kHz.  You can refer to my previous post
> > for the exact details of the project format stats.
> > 
> > I monitored "top" while I performed a few operations in Cinelerra.  I
> > only used Cinelerra during the test interval:
> >   
> > operation                   mem used
> > before starting cinelerra       297MB
> > after starting cinelerra        500MB
> > open project                    605MB
> > play first 30s of vid           681MB
> > click and play diff 10s of vid  742MB
> > click and play diff 10s of vid  756MB
> > click and play diff 20s of vid  800MB
> > click and play last minute      915MB
> > select all in timeline          918MB
> > rendered audio as WAV          1036MB
> > click and play diff 30s of vid 1113MB
> > click and play diff 30s of vid 1165MB
> > render video using ffmpeg      
> > (cancel after five minutes)    1342MB
> > apply histogram and play 30s   1367MB
> > quit cinelerra                 1139MB
> > 
> > * 1139MB still used after quitting cinelerra
> > 
> > Here is the top output after quitting cinelerra:
> > Tasks: 117 total,   1 running, 116 sleeping,   0 stopped,   0 zombie
> > Cpu(s):  1.5% us,  1.0% sy,  0.0% ni, 96.8% id,  0.0% wa,  0.3% hi,
> > 0.3Mem:   2070884k total,  1143208k used,   927676k free,    18604k
> > buffersSwap:        0k total,        0k used,        0k free,   978248k
> > cached
> > 
> >   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> >  2695 root      15   0 42668  17m 8684 S  1.7  0.8   0:04.27 gnome-termi
> > 2588 root      14  -1 67572  26m 8304 S  1.3  1.3   1:18.39 X
> > 
> > oops..just realized swap not enabled on reboot.  I will fix that.
> > 
> > if you need a test MPEGTS file from my cam to work with, here's one:
> > http://content.serveftp.net/video/jvchd10u_output.m2t
> > 27MB
> > 
> > scott
> > 
> > After starting Cinelerra, my used memory read 590K.  As I clicked in the
> > timeline and played back (about four times), the memory  used grew to
> > about 720K.  I then selected the entire track and hit shift-R to render.
> > My memory usage shot up to about 1.8MB.  I rendered the audio to wav.
> > After rendering the wav audio,
> > 
> > On Fri, 2007-02-09 at 22:00 +0100, Andraž Tori wrote: 
> > > please try out new builds so we will know if this fixes your problems or
> > > not... report back please.
> > > 
> > > bye
> > > andraz
> > > 
> > > On Fri, 2007-02-09 at 15:00 +0000, [EMAIL PROTECTED] wrote:
> > > > Andraz,
> > > > As I have been suffering from the consequences of mpeg decoding leak, I 
> > > > am very excited to test this when I get home this afternoon.  Thanks!
> > > > 
> > > > One question: what is a crush?
> > > > scott
> > > >  -------------- Original message ----------------------
> > > > From: Andraž Tori <[EMAIL PROTECTED]>
> > > > > This is a fix for obvious leak when reopening mpeg from index files. 
> > > > > 
> > > > > Previous fd was not released in all cases. Now it is. 
> > > > > 
> > > > > This leak also caused crushes due to memory exaustion and creating 
> > > > > extreme 
> > > > > number of waiting threads eventually... The way it crushed is not 
> > > > > completely 
> > > > > obvious to me, but now the crush is gone.
> > > > > 
> > > > > Opening mpeg files that have index is still awfully inefficient, 
> > > > > since every 
> > > > > file that already has TOC created is opened twice - first time just 
> > > > > to read the 
> > > > > number of video streams present. This could be done better...
> > > > > 
> > > > > bye
> > > > > andraz
> > > > > 
> > > > 
> > > > 
> > > > email message attachment
> > > > > -------- Forwarded Message --------
> > > > > From: Andraž Tori <[EMAIL PROTECTED]>
> > > > > To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> > > > > Cc: cinelerra@skolelinux.no <cinelerra@skolelinux.no>
> > > > > Subject: [CinCVS] mpeg decoding leak & crush
> > > > > Date: Fri, 9 Feb 2007 12:44:02 +0000
> > > > > 
> > > 
> > > 
> > > _______________________________________________
> > > Cinelerra mailing list
> > > Cinelerra@skolelinux.no
> > > https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
> > 
> > 
> > _______________________________________________
> > Cinelerra mailing list
> > Cinelerra@skolelinux.no
> > https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
> 
> 
> _______________________________________________
> Cinelerra mailing list
> Cinelerra@skolelinux.no
> https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra


_______________________________________________
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Reply via email to