No I didn't
can you give your sources.list line(s) concerning the PPA? maybe a mistake here?

For this specific problem, Kdenlive is not the culprit: MLT is actually concerned (check by rendering directly with melt command)...
but I have also seen this problem once with the latest version, so upgrading today wouldn't solve your problem 100% sure!

To get this solved, we need to have a reproducible and simple testcase, that I was not able to create as the problem disappeared for me.
Please try to provide us one (without heavy source videos to transfer & complex timeline to analysis) and we will try to find a solution.
Then we will patch KDE4 version as well

As a workaround, have you tried other video codec rendering? also try to remove the "properties=..." argument in the rendering profile, to drop MLT customizations and fall back on libavcodec default settings (much faster for MPEG2/HDV for example).

Hi,

I have the same problem since quite a few months. My workaround is to edit my videos on my workstation (i7 with Kubuntu 14.04 LTS) and then render them in a virtual machine (Mint 16 Petra, based on Ubuntu 13.10) using an older version of both kdenlive and melt.

I noticed that when the rendering in kdenlive stalls (between 10 and 1 second before ETA), the generated file continues to grow, but very very slowly, proving that melt is still working. The initial ETA is about the same in Kubuntu and Mint, except that in Mint the rendering ends more or less at the estimated time, while in Kubuntu it can take up to several hours with the countdown halted a few seconds before the estimated end.

Yesterday I made some comparative testing with a relatively small video project (about 20 minutes) and, as you said, the problem seems to be melt, or maybe parameters in the script generated by kdenlive (don't know the meaning of all that parameters). Here are my results ....

Kubuntu (K): kdenlive 0.9.8, melt 0.9.0
Mint (M): kdenlive 0.9.6, melt 0.8.8
Test 1 converting from .ts (recorded on my PVR) to mpg, video + audio:
- duration K: 00:41:17 minutes
- duration M: 00:05:39 minutes
- resulting file size: 645 MB

I run a 2nd test on K rendering video only, without audio:
- duration K: 00:04:19 minutes

Then a 3rd test on K rendering only audio, no video:
- duration K: 00:34:46 minutes

It seems that the audio rendering is the trouble maker.

Interesting result for the same test (video + audio) rendering to mp4:
- duration K: 00:17:49 minutes
- duration M: 00:13:54 minutes

There is less difference for mp4 rendering, also for bigger projects.

A last test with rendering to avi:
- duration K: 01:00:38 hours
- duration M: 00:25:45 minutes

I run all the tests in parallel, surfing the internet during the rendering. Out of my workstations 12GB RAM I attributed 4 to the VM and also 4 processors. In kdenlive I set the "encoder threads" to 4 on both the workstation and the VM. In my opinion the VM should have been suffering under my workstations load, but yet it provided by far the better rendering times.

As a result of my test and observations, I think about downgrading melt on Kubuntu 14.04 to version 0.8.8, but don't know how to do it and if it's possible. Anyway, it would just be another workaround not really solving the problem. Any ideas?

Regards

Michel

Hi again,

I bought a new laptop with Ubuntu 14.04 LTS pre-installed, installed KDE and Kdenlive, and run the same test on it. Same kdenlive and melt versions as on my Workstation. Test result: it took about 15 minutes to render the video without stalling. The rendering time is acceptable considering that my laptop has a less powerfull i5 processor and that I granted only 2 encoder threads.

I checked the kdenlive set-up on both my workstation and my laptop, and the only difference I found was when running the config wizard it puts an error mark in front of "DV module (libdv)" on the "installed modules" tab of the "checking MLT engine" page. As far as I can see libdv4 is installed. Could this error be the reason for the slow rendering or what other parameters should I check?

Any idea?

Regards

Michel

Hello,

This bug is recurrent since ubuntu 14.04, maybe linked to libav, but still not found a workaround...
Do you have title clips in the end ? It seems these clips are causing hangs.
Else, did you try with a container other than MP4/MOV ? For example what's the result with MKV/Theora/Vorbis ?

LibDV check was dropped in subsequent versions: MLT dropped this lib to rather use ffmpeg far DV capture.
No link with render time.

Cheers,

Vincent

Kdenlive is in the need of a stable 64bit release, the team needs to focus in keep doing video editing to find the bugs and correct them. I see develop people here hungry to create new features and the users keep desperate to use the software without bugs... this way serious people will move to paid software...

Give a try on keep half processor threads for decode and half processor threads for encode, try MP4 file format with CBR (constant bit rate) one pass encoding with audio and select to render the work area. this works for me in small rendering with 32000 for video and 192 for audio (fullhd), I did not try long rendering yet... In the end of rendering there is a small time to finish because the encoder needs to pack the audio and video together and copy to the destination folder, but this is a small time.

Hi Vincent,

vpinon wrote:Do you have title clips in the end ? It seems these clips are causing hangs.

No title clips in my test video. No other effects either.

vpinon wrote:Else, did you try with a container other than MP4/MOV ? For example what's the result with MKV/Theora/Vorbis ?

I tried MKV but there remains a difference in rendering time, i.e. 14 minutes under Kubuntu 14.04 and 8 minutes under Mint 16.

As I mentioned in my first post, the rendering time is "normal" when I choose to render without audio. It's audio-only or audio+video that slows the rendering process substantially down. Let me again give the figures of my test, rendering a 20 minutes video to mpg:

Mint 16 video+audio: about 5 minutes

Kubuntu 14.04 video+audio: about 41 minutes
Kubuntu 14.04 video only: about 4 minutes
Kubuntu 14.04 audio only: about 34 minutes

Based on these figures it looks to me as if the issue is strongly tied to the audio rendering.

Best regards,

Michel

christopherwere wrote:Any idea why Mint doesn't see 0.9.10 in the PPA?

Are you looking in the release old ppa. Because I see 0.9.10 there. https://launchpad.net/~sunab/+archive/u ... elease-old

It's been almost a year, and I still haven't resolved the issue. I guess that this bug (MLT or kdenlive) isn't happening in 16.04 (and the new KDE kdenlive), and that's the reason that this thread has "frozen". But has anyone tried the new versions? is this still an issue? I can't upgrade yet to test this.

P.S: If I install Ubuntu 16.04 to a virtual machine, and the latest kdenlive, could I migrate the project from kdenlive 0.9.2 without major proplems?

Thanks

Hi.
A few weeks ago, I made a fresh installation of Maui KDE with plasma 5.8.1, any problem with Kkdenlive.

A few days ago, I need change my hard disk and made a fresh installation of Maui KDE with plasma 5.8.2.

Now, my version of Kdenlive is 16.08.2

I have the same problem.
Arrives to 99%, and the video are finished of rendering, but continue the toolbar process and stop in 99% (always, around 40 seconds for finished).
I wait until 8 or 10 hours, but any change.

This bug/issue is alive still. I too am having this issue. But maybe my issue can give some insight:

I have kdenlive installed and up to date on Debian Testing repos on my laptop to do A/V syncing, then generate script and offload all processing to a desktop. I had OpenGL disabled because of other issues. Built up said desktop back in the beginning of October (Debian testing as well to take advantage of bleeding-edge software versions). Both were able to render no problems.

Fast forwarding, I swapped the HDD in the Desktop to a different one with considerably more processing power, better monitor, video card, etc. Enable the OpenGL acceleration to take advantage of my new shiny RX480. Worth noting that it hadn't been apt upgraded since beginning of October, so it was still on kdenlive 16.8.1). Create a new project, sync audio/video up, get transitions right, filters, etc. Tell it to generate script, and start it up inside of a screen session. Gets to 99% and won't finish. CPU usage is maybe 1%, RAM usage is over 4GB, not progressing frames (based off of the <filename>.mp4.txt) and let it sit for ~8 hours with absolutely no progression. I try again with a different project, same thing. Upgrade all the packages to the latest, same thing. Change containers from MP4 to MKV and try to just do the first 5 seconds or so of the project via the GUI. Still no luck. Rebooted and same case.

I've not tried my laptop again, but strange that the configuration did work, move it to different hardware, enable OpenGL rendering, and now it won't. I will disable the OpenGL acceleration tonight (or when I get a chance this weekend) and give the laptop another chance (when it has successfully rendered before) and update.

Hello,
I've seen a commit from JB this weekend finally (!) fixing this problem:
it seems the progress indicator fails when there is a space in the file name or path,
but the resulting output should be good anyway
(you don't really know when, just check that the file size hasn't changed for some several seconds/minutes and you're done).
Best is to avoid space in names for releases <16.12.0 (to be tested within few weeks)

Wish I could say that I had better luck this weekend.

Disabled OpenGL on the Debian Testing RX480 Desktop setup, and it wouldn't let me jog/skip/go to a user-input time. Nope. I made a backup of the drive and installed Ubuntu 16.04.1 LTS, added the kdenlive repo, updated, installed, upgraded, etc. Quickly realized Ubuntu doesn't support the RX480 nearly at all, so I downloaded & installed the official AMD GPU drivers, which made it run very nice. Went to import files and try from a clean install, and kdenlive wouldn't run at all. I'd be happy if a developer would like to try a few things out on this box at a later date to see if it works to help iron out things.

Reverted back to my Debian Testing install, and I found a setup that kind of worked. OpenGL playback, processing threads set to 1, encoder threads set to 1, and not using the built-in render status tracking. I honestly found I had better luck generating a script file, closing kdenlive completely, and executing it from an SSH+screen session or at a TTY and checking back on it occasionally. Even then, it still occasionally gets hung up at 99%. In these cases, I would control+alt+F1 or so and in my mind, it sometimes helps it get over that barrier. I'm not sure how much of this is computer snake-oil, but it's working-ish for now. I'd love something that can better take advantage of GPU rendering, but Ubuntu is out for the time being, official AMD drivers don't support Debian (but they're just a bunch of .deb files, so I might go down that path some), and while there are the GPU-transformations, I found that if I had 3 tracks with effects stacked on top, one of the tracks just isn't displayed until all of the effects complete, which forced me to revert to old-school Affine transition to handle my fade in/fade out/sizing.

I'm actually taking the talks presented at a recent computer security conference and overlaying captured slide video, camcorder video of the speaker, and a title slide, fading in/out and resizing the video at start/end. 19 total, and I'm down to the last 2-3 now.

vpinon wrote:Hello,
I've seen a commit from JB this weekend finally (!) fixing this problem:
it seems the progress indicator fails when there is a space in the file name or path,
but the resulting output should be good anyway
(you don't really know when, just check that the file size hasn't changed for some several seconds/minutes and you're done).
Best is to avoid space in names for releases <16.12.0 (to be tested within few weeks)

In response to this, I was rendering to the MP4 container. After sitting at 99% for an hour or so and no additional frames were processed (checking the <filename>.mp4.txt) and the filesize hadn't increased, I killed the process. Doing so resulted in the moov atom not being found and left with 400+ MBs of a worthless file (I hate the MP4 container). Tried it with the MKV container instead, tweaking the rendering profiles accordingly, using the same x264 CRF video and aac cbr audio settings, and it got stuck at 99%. Killing it after no progress showed that everything up until a few seconds at the end was rendered, then just abruptly stops. This happened before I played with the threads=1 realtime=-1 options, so this might have been a result of a different issue still.

For what it's worth, I also tried the latest self-contained AppImage yesterday thinking that maybe there's something with Debian's libraries not playing well. It quickly stopped working all-together and would crash when trying to render a frame when I skip to an area.

Hopefully, I'm making some sense in these ramblings and my descriptions can help somewhat. I'm willing to help test if needed. I realize not everyone has the same hardware/software combination as me.

I've got the exact same issue here: at 99% the rendering task halts and doesn't finish . It only happens with "use GPU processing (Movit library)" enabled.
Without movit library enabled, videoplayback is unbearably slow (AMD FX 4100@4.5GHz, 16GB RAM, SSD Drive, HD7870), but rendering works.

Current workaround: To edit videos I need to have Movit enabled and then for rendering I have to disable it.

Software versions:
Kdenlive: version 16.12.1, KDE Frameworks 5.26.0, Qt 5.6.1 (built against 5.6.1), The xcb windowing system
OS: Ubuntu 16.10, kernel 4.8.0-34-generic
Graphics: Gallium 0.4 on AMD PITCAIRN (DRM 2.46.0 / 4.8.0-34-generic, LLVM 5.0.0), Mesa 17.0.0-devel - padoka PPA

Any help, someone?

Same problem, up-to-date Gentoo and kdenlive 16.08.3. Any more ideas? I'm trying to rebuild these packages. I am not able to check the error log.

I have this problem with the latest version of Kdenlive that is available for elementaryOS(basically Ubuntu), I got everything working very well, edited a video and tried to export it, no problems until I woke up in the morning to find that it still hadn't finished, looking at the .txt file it shows that it gets stuck at 99%, I will post some logs when I get home and versions, I think melt is version 1.5 or so but I am at school right now so I can't check. Wondering if there are any work arounds, I haven't been able to find anything with melt having problems like this anywhere so I am wondering if its Kdenlive? I have a 3rd gen Dual core Core i5 running at 1.8ghz with hyper threading. No GPU with Intel HD4000(I know terrible) and it takes a while but it should work. I am using the latest MESA drivers for my CPU. Can anyone help?