Memory eating

[GoogleCodeExporter]

Importing about 10 footage creates a problem. Flowblade seems to eat memory. 
Same problem with kdenlive. Maybe the issue belongs to mlt ver 0.8.1. This page 
tells that it has fixed major memory leak issue. 
http://mltframework.blogspot.in/2012/08/version-082-released.html

How to make flowblade use mlt ver 0.8.2? Or how can i resolve memory eating 
problem?

Original issue reported on code.google.com by mohan...@gmail.com on 1 Sep 2012 at 4:45

[GoogleCodeExporter]

Nope. upgrading to mlt ver 0.8.2 also didn't solve my memory eating problem..

Original comment by mohan...@gmail.com on 4 Sep 2012 at 1:52

[GoogleCodeExporter]

Could you please give some numbers that describe memory eating. Linux always 
uses maximum available memory for disk caching, so when you load clips it will 
use all the memory that is available to hold video data (actually it holds disk 
blocks that have been read).

Original comment by janne.li...@gmail.com on 4 Sep 2012 at 7:10

[GoogleCodeExporter]

Loading about 10 files 100mb of Full HD H.264 content will take around 1.5 gb 
of ram. I don't think this would be practical solution if i want to load about 
100 shots into the bin. If all the memory has been consumed then how can i edit.

Original comment by mohan...@gmail.com on 5 Sep 2012 at 6:04

[GoogleCodeExporter]

Ok, I'll try to get some feed back on this from MLT guys.

Original comment by janne.li...@gmail.com on 6 Sep 2012 at 11:30

[GoogleCodeExporter]

I already recently did extensive repair on this that went into the latest 
release. I know mohan says he tested v0.8.2, but I am not able to reproduce it. 
I need evidence to support the claim at this point. How do I know the new 
version is really being used? How do I know how the memory is being measured?

This is the bug report that went into the fixing.
http://sourceforge.net/tracker/?func=detail&aid=3551459&group_id=96039&atid=6134
14

Original comment by ddenn...@gmail.com on 6 Sep 2012 at 4:28

[GoogleCodeExporter]

mohanohi, have you tried loading MORE then 10 clips because as ddennedy states, 
MLT caches max 10 clips at a time and memory use should not significantly grow 
after that?

Original comment by janne.li...@gmail.com on 6 Sep 2012 at 5:19

[GoogleCodeExporter]

Hi Janne,
This is what i did.
1) open flowblade from terminal, 
2) shows using mlt ver 0.8.2
3) Load Full HD content recorded Canon 550D DSLR camera.
4) Watch memory eating with system monitor's Memory and Swap History.
5) And the system crawls....

Original comment by mohan...@gmail.com on 7 Sep 2012 at 5:17

[GoogleCodeExporter]

I see that flowblade defaults to 10 tracks. The level of caching increases with 
the number of tracks (you could be compositing and mixing on all of those 
tracks). Janne, max is actually #tracks + 1, not 10, and the minimum is 4. ~1.6 
GB memory consumption is about what I expect with 1080 HD material and 10 
tracks.

Now, in contrast, I just played 14 HD clips with melt at the command line using 
'melt *.MTS' and it only consumed max 711 MB. Multitrack HD editing with MLT 
does require a fair amount of memory, and this is not something I am going to 
address. You could provide a way to have less tracks or simply say 2GB free RAM 
is required for HD.

Original comment by ddenn...@gmail.com on 7 Sep 2012 at 6:04

[GoogleCodeExporter]

Flowblade does indeed default to 10 tracks (9 user editable tracks and one 
hidden track for trimming and clip display).

I'm marking this WontFix because:

1) MLT is working as expected, and uses lot of memory to ensure smooth playback.

2) I believe it is reasonable to require 2 GB free RAM for editing HD, as this 
requirement can be met on practically all currently available new systems. I'll 
make this requirement known on this web page.

3) Video editing is resource intensive by nature, and user can be expected to 
close other programs to get maximum performance.

3) Having a fixed number tracks and no vertical scrolling on timeline has been 
a major design decision for Flowblade because of the "solid" feeling you get 
for it.

I'll look into possibility to create projects that have a smaller number of 
tracks, but the number of tracks will probably always stay fixed after project 
creation.

Thanks to ddennedy for technical input.

Original comment by janne.li...@gmail.com on 7 Sep 2012 at 7:01

• Changed state: WontFix

[GoogleCodeExporter]

mmohanohi, I've decided to make creating projects with fewer number of tracks 
possible, and this will help when trying to edit HD material on lower end 
devices, see new issue below: 

http://code.google.com/p/flowblade/issues/detail?id=20&can=1

Original comment by janne.li...@gmail.com on 7 Sep 2012 at 7:29