ffmpegX Progress memory issue

[Jonas hmm]

It seems like the progress window eats alot of memory after a while, at least virtual memory. After a night of encoding the Progress takes 500 Mb VM and the computer is very sluggish. The encoding speed has dropped significantly. Don't know if this has got to do with the memory but the speed drops when running long periods.

Cheers.

[paulhagstrom]

I can vouch for this too -- I often leave ffmpegx on overnight encoding batches of things, but it often only makes it through the first few and then crashes. I can see as it's going that my swapfiles are more and more numerous. I generally quit everything but Progress in order to ensure it lasts as long as it can, but it would be nice if this were solved at some point.

One possibility is that the log files it keeps for each encode are building up and staying in memory. Since I am not physically present, I can't hit the "clear" button, but is there any way to send it an Applescript message to clear? I suppose I could look into that. Could those log files be written to disk instead of kept in memory? (And, while I'm at it, could the actual command with all the fancy piping and option settings be recorded at the top of the log so that one might recreate it from one's own command line?)

As I write this it occurs to me that a possible workaround would be to let Progress open a new terminal window for each encode -- it is conceivable that this will keep Progress from trying to keep its own log of the encode, and Terminal windows only have a finite backscroll memory.

? Just thinking out loud, but I also wanted to vouch for the problem as well. I'm running the newest ffmpegx on the most up-to-date MacOS X 10.3 on a dual 1.25GHz G4.

[paulhagstrom]

Just to follow up, I realized once I tried it that opening a Terminal window might work, except that it starts all encodes simultaneously rather than queuing them nicely like Progress does. And it seems that you can't have two encodes that decode using mplayer going at once, because they interfere with each other (/stream.yuv and /audiodump.wav are clobbered by each other's encoding process). So, opening everything in Terminal won't solve the problem (not to mention it really kills the speed of the machine when you have so many going simultaneously -- one at a time really isn't bad, and it's nice to see the CPU monitors pegged all the time, makes the machine seem useful).

The Progress line in top reads:

PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
571 Progress 16.7% 85:24.31 21 201 2400 462M+ 9.14M 113M+ 1.49G

and I bet it'll bomb out soon. Perhaps when it hits 1.5G, perhaps when it hits 2G, but it always bombs out after about this many encodes (5 or 6 or so).

Edit: It bombs out when it hits 2GB. Perhaps this is a memory addressing issue (it could have grabbed more VM if it wanted to, I think). But it shouldn't be building up so much memory anyway, I'd say, if there's any way around it in upcoming versions.