Kdenlive   bug tracker Home page

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001954KdenliveCapturepublic2010-12-30 22:382011-03-20 00:24
ReporterFrizou 
Assigned Toddennedy 
PrioritynormalSeverityminorReproducibilityalways
StatusassignedResolutionopen 
PlatformPC Mobile AMD Acer Aspire 7520OSLinuxOS VersionMandriva 2010.2
Product Version0.7.7.1 
Target VersionFixed in Version 
Summary0001954: ffplay Huge Memory Usage - System slow
DescriptionWhen acquiring DV tape from cam, ffplay process seems to keep in memory all DV acquisition raw data (around 7 Mo every 2 seconds).

First, I stop acquisition around 10 minutes video (2 Go RAM + 2 Go swap almost full)... but it never crashes even if you acquire more video !

ffplay stays stable with 3071 Mio and only 300 Mio free memory to the rest of the (very slow) system !

Launching new application may make them crash because of lack of free memory (hem: in fact, I am very surprised by the excellent stability of Linux system in this configuration: my whole DV acquisition continues despite swap, 100% CPU usage... And I hardly found to launch an application that crashes (Kino)).

I all that ffplay memory usefull ?
Could it be possible to free this memory ? (Memory Leaks ?)
Steps To ReproduceConnect cam to PC with firewire connector
chmod a+rw /dev/raw1394
Launch Kdenlive
Acquisition Monitor: Record
Cam: Play
Kdenlive Acquisition Monitor: timecode starts (no image, just "Initializing...", but it works)
Mandriva Menu: Tools - System Tools - System Monitor
System Monitor, ┬žProcess: track ffplay process with memory and virtual memory, continuously climbing (2250 Mo for 10 minutes DV acquisition, 3071 Mo for 15 minutes DV acquisition...)
System Monitor, ┬žSystem load: track memory & swap (continuously memory consumption, then swap)
When RAM + swap is full, ffplay keeps it memory and lets only 300Mio free for the rest of the system.
The system is very slow (swapping) and launching a lot of new applications fails.
I stop record at 40 minutes, then ffplay process disappears, and Huge memory now available !
Additional Information$ ffplay -version
FFplay version SVN-r22960, Copyright (c) 2003-2010 the FFmpeg developers
  built on Jun 15 2010 14:20:22 with gcc 4.4.3
  configuration: --prefix=/usr --enable-shared --libdir=/usr/lib --shlibdir=/usr/lib --incdir=/usr/include --disable-stripping --enable-postproc --enable-gpl --enable-pthreads --enable-libtheora --enable-libvorbis --disable-encoder=vorbis --enable-x11grab --enable-runtime-cpudetect --enable-libdc1394 --enable-libschroedinger --disable-decoder=aac --disable-encoder=aac
  libavutil 50.14. 0 / 50.14. 0
  libavcodec 52.66. 0 / 52.66. 0
  libavformat 52.61. 0 / 52.61. 0
  libavdevice 52. 2. 0 / 52. 2. 0
  libswscale 0.10. 0 / 0.10. 0
  libpostproc 51. 2. 0 / 51. 2. 0
FFplay SVN-r22960
libavutil 50.14. 0 / 50.14. 0
libavcodec 52.66. 0 / 52.66. 0
libavformat 52.61. 0 / 52.61. 0
libavdevice 52. 2. 0 / 52. 2. 0
libswscale 0.10. 0 / 0.10. 0
libpostproc 51. 2. 0 / 51. 2. 0
$
TagsNo tags attached.
Build/Install MethodDistribution package
Attached Files

- Relationships

-  Notes
(0006611)
ddennedy (developer)
2011-03-20 00:24

I tested this, but I could not reproduce it. However, I did have problems with slow video framerate and stalling in the preview. It seems ffplay's sync algorithms do not like the discontinuity of pipe input from dvgrab. It could be that in your version of ffplay this also results in some memory leak. I tried a lot of ffplay options to try to make it dumber and more tolerant, but I did not succeed yet. This area needs work.

- Issue History
Date Modified Username Field Change
2010-12-30 22:38 Frizou New Issue
2011-02-08 09:41 ddennedy Assigned To => ddennedy
2011-02-08 09:41 ddennedy Status new => assigned
2011-03-20 00:24 ddennedy Note Added: 0006611


Copyright © 2000 - 2014 MantisBT Team
Powered by Mantis Bugtracker