Memory leaking when export video

Bug #1469845 reported by Shamil
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
OpenShot Video Editor
Confirmed
High
Unassigned

Bug Description

I created a project with 56 tracks. Each track included one clip from 10 to 15 seconds and one 3 second transition (blinds sliding). Resolution of the clips were 2304 x 1296 (H.264 / AVC, 25 frames per second). When I started exporting video to AVI(h.264) HD720p 25 fps I faced with memory leaking. System monitor showed a constant growth of memory usage up to 100 percent.
I found a solution but I hope that my letter will help you to fix your program.

Solution was the next. I had to split my project into three parts, export them separately and then merge them together. I also mentioned that there was no memory leaking when I merged video clips without changing resolutions. So that may be a good idea to work always with converted versions of the clips.

Environment:
64 bits,
ubuntu 14.04 LTS (OS is not installed, starts from flash disk without swap partition)
Openshot 1.4.3
PC with AMD FX(tm)-6300 Six-Core Processor × 6, 8GB RAM

Revision history for this message
Olivier Girard (eolinwen) wrote :

Hi

Yes we are aware and it is a reason of the creation of Libopenshot. Another reason can be that you are starting from a flash disk. But I don't think really.
BTW you can convert them in dnxhd with Enkodeur-Mixeur. I've seen that at rmll 2011 at Strasbourg. Laurent have done that for a new user on an netbook. This guy was not able to do that on Window with the software which was coming with his camera...Impressive.

Changed in openshot:
status: New → Confirmed
importance: Undecided → High
Revision history for this message
Adam (ajenkins-wisecat) wrote :

Similar problem noticed with a 3 track video of about 8min duration. Memory and swap were both filled upon rendering with the export eventually failing.

As a workaround, I attached a 2TB drive formatted for swap and engaged swapon. Then tried rendering again. Memory usage reached about 2GB (IIRC) before the export reported completion. However the resultant video file was empty (0b).

Finally, split the video into 2 parts for rendering and created a new project to splice the two bits together. That worked perfectly as if the previous problem never happened. No memory chewing.

Revision history for this message
twowheeler (cdhassell) wrote :

This bug is old but it looks like I am having the same issue.

I am running Openshot 2,5,1-dev2 on ubuntu 18.04.4, with 6GB memory and 2GB swap. I used OpenShot to pull in a series of short video and audio clips to make a 35-minute video. The process went fine until trying to export the result. After working for about an hour, it would get to about 75% complete and then freeze the system, with the disk light on full time. If I waited long enough it would eventually come out of the freeze, but OpenShot closed without finishing the export. I tried several different output formats, but it didn't change the outcome.

Since I had access to a Macbook, I installed the Mac version of OpenShot, and copied over the folder from the ubuntu system with all of the files to the Mac. The Mac has 8GB of memory. The export ran fine on the Mac and I got my video done. Success!

As an experiment I tried it again on another Ubuntu system with 16GB memory and 20GB swap. It still crashed at the same point as before, despite having acres of RAM. The system log report is as follows:

[ 5401.109711] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=openshot-qt,pid=2469,uid=1000
[ 5401.109852] Out of memory: Killed process 2469 (openshot-qt) total-vm:40318340kB, anon-rss:15581236kB, file-rss:0kB, shmem-rss:488kB
[ 5402.989441] oom_reaper: reaped process 2469 (openshot-qt), now anon-rss:0kB, file-rss:0kB, shmem-rss:456kB

So it looks like the linux version has a memory leak that is not present in the MacOS version. I like OpenShot and I'm hoping you guys can fix it.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.