Hi everyone,

When I try and render a project to any video format that includes embedded audio, rendering fails. This seems to be due to a memory problem with MELT. Perhaps a memory leak.

I have been able to render short videos (with embedded audio) with success if the video compression is high (end file size small). However, any "large" projects, i.e. long videos (i.e. 45 minutes in length), or even a short project rendered to weak or lossless compression format will always fail if it includes embedded audio. Note: in both these cases the final rendered file would be large, and this is a clue. Again, my theory has to do with a virtual memory leak in MELT during rendering (see below).

The reason I suspect that this is a MELT problem rather than a problem internal to KdenLive, is because I have exported the render script from KdenLive and executed it from a terminal command line and the render still fails at the same point.

I have been watching the Task Manager (Lubuntu's system monitor) to see what happens when rendering chokes. Here's what I see:

- The CPU is working hard to render the video (CPU usage 80% to 99%) which seems normal.
- As rendering progresses, both RSS and VM-SIZE memory usage climbs and climbs. There is no "plateau", it just keeps growing.
- Shortly after VM-SIZE reaches over 2.1GB it suddenly reports the impossibly large amount of 16777216.0 TB (Terabytes) then stays at this amount.
- Rendering seems to continue for a few minutes more until RSS memory reaches above 2.1GB usage. It then also suddenly switches over to show 16777216 TB (Terabytes) is being used.
- Moments later the MELT process then stops and disappears from the task manager. CPU usages drops to 0% to 3% (indicating rendering has ceased).
- If I'm rendering from the terminal command line I get the error message: "Rendering aborted, resulting video will probably be corrupted". The terminal doesn't crash but just returns to a command prompt.
- If I'm rendering from within KdenLive, the rendering progress bar usually just holds at this point. I cannot abort the job or clear it, but KdenLive itself doesn't seem to have crashed. I can still go into KdenLive and choose menu items, shut down the application normally, etc.
- However, sometimes the KdenLive rendering window will give me an error report - like this example:

Rendering of /media/brent/Media_Drive/Video/KdenLive_Test_Renders/Test_01.vob crashed
[wav @ 0x83d1fa0] max_analyze_duration reached
[wav @ 0x84d8d20] max_analyze_duration reached
[dvd muxer @ 0xb220b5a0] Value 10080000.000000 for parameter 'muxrate' out of range
[ac3_fixed @ 0xb2212860] channel_layout not specified
[ac3_fixed @ 0xb2212860] No channel layout specified. The encoder will guess the layout, but it might be incorrect.
[wav @ 0xb03037e0] max_analyze_duration reached
[wav @ 0xb0305ca0] max_analyze_duration reached
[dvd @ 0xb220b0a0] buffer underflow i=0 bufi=2011 size=5477 [dvd @ 0xb220b0a0] buffer underflow i=0 bufi=2011 size=5477
[dvd @ 0xb220b0a0] buffer underflow i=0 bufi=4035 size=5477

Either way, the resulting video file is only a few Kilobytes long and obviously doesn't play.

IMPORTANT NOTES:

If I render ONLY video (uncheck the render audio option) or ONLY audio, then rendering completes SUCCESSFULLY every time and both the RSS and the VM-SIZE shown in the task manager plateau and remain at "sane" amounts (much under 1GB). They don't climb and climb.

I am able to render short video+audio projects IF (and only if) the project is short enough that the render can finish before MELT's VM-Size and RSS memory values reach the 2.1GB point. The weaker/lower the video compression chosen during render (larger render file size), the faster the 2.1GB "barrier" is reached by MELT during render and the sooner the crash occurs (i.e. rendering to a lossless video format causes MELT to reach the barrier sooner than the same project rendered to a highly compressed format).

The crash/memory-leak/failure seems to ONLY happen when I try to render a video with embedded audio in ANY format which is above a certain size (enough for VM-SIZE and RSS to reach over 2.1GB when rendering). I think this is the clincher, but I don't know how to stop/correct for this issue. Any help would be appreciated.

I am using:

Operating System: Lubuntu Trusty Tahr 14.04
KdenLive version: 0.9.10 (the latest offered to me by the "ppa.launchpad.net/sunab/kdenlive-release/ubuntu trusty main" repository).
MELT version: 0.9.3+git20141005.22abed67-0ubuntu0~sunab~trusty1 (also the latest available to me)
libav-tools version: 6:9.18-0ubuntu0.14.04.1
FFMPEG version: I looked in Synaptic Package Manager (installed software) and was unable find anything simply labelled FFMPEG

The source material is DV video from a NTSC 16:9 consumer mini-dv camcorder (standard defition).
The output/target format is NTSC DVD widescreen CBR with AC3 audio (but tests to other output formats have also failed to render if audio is embedded).
My computer is an older dual core with 3GB of RAM (but this has always been fine for reliably running Sony Vegas in Windows and the rest of my video editing needs).

Note: I have removed all special effects from the video and it still fails.

I had thought I had finally found a video editor that would make me switch from Vegas/Windows...until I encountered this show-stopping bug. I hope it is fixable. I appreciate all help and suggestions, and will provide whatever information needed to diagnose this issue.

Thanks.

You probably meant Kdenlive 0.9.10, just a minor sidenote. Seeing that you are still on xxUbuntu 14.04, I' m afraid that there will be any support. Would it be possible for you to set up a fresh xxUbuntu 15.04 installation with KDE Frameworks 5, such as Kubuntu 15.04? If yes, would it be possible to you to not use the outdated and sometimes problematic repo versions, but instead compiling MLT and Kdenlive directly from recent stable source? There's actually a dedicated wiki article on compiling this stuff on a KF5 system: https://community.kde.org/Kdenlive/Development/KF5

I did this myself and had good results; however, please see here for switching to the correct source code snapshot after getting the Kdenlive sources: viewtopic.php?f=265&t=127460#p343871

Ugh. I really don't wish to abandon the current stable, LTS version of Lubuntu and re-install my complete operating system with a non-LTS version just to get KdenLive to work. Especially since it seems to work so well, except for this MELT render issue.

Is there any way to just upgrade MELT to a newer version - perhaps a bugfixed version - while keeping KdenLive 0.9.10 and my current Lubuntu OS version?
Even if there was a work-around for the memory bug, it would be helpful (maybe a parameter that can be set for MELT?).

I've read postings by other people who have complained of a similar MELT memory problem with 0.9.10 KdenLive. Some have gone back to the more stable 0.9.8 version. If I did that I wonder would I be losing many features? Previously I was using 0.9.6 of KdenLive and it was very unstable. Version 0.9.10 was a big improvement in stability for me (and finally made me consider dropping Sony Vegas).

You can try to get the recent MLT source code and compile it yourself. If you follow the instructions linked to in my previous post, you'll find that the first part is about compiling MLT. For testing purposes, install MLT to your own directory and change Kdenlive's configuration to point to your newer MLT. Then give it a try and see what happens. However, there may be bugs in dependent libraries that might be the cause for your memory leak, not necessarily MLT nor Kdenlive. It could also be Ffmpeg or that avlib side branch.

I think I've found a work-around for this problem. Essentially, I am exporting audio and video seperately to avoid the memory leak bug, then re-muxing with avconv. I typed up some instructions for myself so I'd remember how to do this and am posting them here for the benefit of others who are having this problem:

How to mux separate audio and video files into a single audio+video file without transcoding (on Linux).

Several users have reported that Kdenlive 0.9.10 video editor under Lubuntu 14.04 experiences a memory leak when rendering combined video+audio files. This will cause rendering to fail on large projects. However, if video and audio are rendered to separate files, respectively, then there is no such memory leak.

In my case, I tried to render a DVD .vob (mpeg2) with embedded .ac3 audio and encountered the memory leak.

As a work-around, I had to render a .vob video file without audio (uncheck the export audio checkbox in kdenlive's render window), and also render the audio without video to an .ac3 file. I then combined the separate audio and video files by muxing them with "avconv". "avconv" is included in Ubuntu distributions and is used from a terminal/command line (note: other Linux distributions use ffmpeg and a similar syntax to that shown below should work).

The benefit of this method is that NO transcoding is done to either the video or audio files. They are simply muxed (joined) together into one package. When no transcoding needs to take place the muxing process is very fast.

From a command line type the following:

avconv -i input_video_file.vob -i input_audiofile.ac3 -c:v copy -c:a copy output_muxed_file.vob

Substitute the input and output file names for those you need. Note, I believe the file extensions may be important as they help avconv to auto-detect the input file codec and then specify the output codec. If you were to use a different file extension on the output file name from that shown on your input video filename, then avconv would try and transcode the file to another format (wrapper?).

The "copy" parameter is also important as it tells avconv to NOT convert the audio or video from the original file. You can specify different parameters here if you DO want to transcode the audio or video.

I've only tested it with DVD .vob files, but in principle it should work with any codec that avconv can handle (which are many).

avconv is very powerful, and can do all sorts of processing and conversion on video and audio. To find out more type this is a shell:

man avconv

Sorry to be a late comer to this thread but I just ran into this problem. Updating MLT to latest does not change the behavior. I however do not think this is memory leak issue. Rendering a short project (<8 min.) does not cause a crash but the memory in my 4GB machine climbs to 3.8GB. After the rendering is done the memory drops back to 768MB. I observe the disk and memory usage and note that the disk is not being written to while the memory is building. Once the project completes the file is updated with the bulk of the rendering data. This only happens when video and audio are done at the same time as noted earlier. Looks to me like a bug. It also occurs when running from the script file from a terminal session. It also occurs in every other app that uses MLT. Pitty.

This memory leak issue is still there! (kdenlive 17.04.2, melt 6.4.1, installed from deb-multimedia binary packages for amd64).

A four-minute clip fills my 15GB swap partition then the rendering fails. The source material is recorded in 1080/50p and renders to mp4 just fine, but for the DVD version, trying to render the VOB just fills up memory and swap until it crashes. This is similar behaviour to the bug reported here... in 2014! https://sourceforge.net/p/mlt/bugs/221/ It supposed to be fixed now, according to https://sourceforge.net/p/mlt/bugs/221/#9dfc. Did it somehow not get applied in subsequent releases?

I see there is kdenlive 17.04.2 in debian exprimental, but other than that I am quite up-to-date. Is this something I'm going to have to patch myself, and build from source, or just wait until the next release comes out?

Nick/.