Ok I was way off on the MLT version, it is

Code: Select all

melt 6.5.0

After further testing I saved the project as a small name (no spaces) and exported the project with a small name (no spaces) and turned off all GPU effects and sweet, sweet success, I am going to try adding GPU effects again to see if that is the problem. It would make sense seeing as I don't have a GPU only integrated graphics so we will see.

Edit: Simply Enabling GPU acceleration makes renders fail, this is on a file with no effects or transitions done to it, simply a render test.
Now let me try simply disabling GPU acceleration and rendering again. Hold Please.

Edit #2: Simply disabling GPU acceleration greatly improves render times and this time they actually finish, very weird, everything was exactly the same except for the GPU rendering, I wonder if this is a bug or the behavior of mlt when using Intel HD4000 graphics rather than a dedicated GPU. If anyone can give me more info I would be glad, I need a few of the GPU effects...

Have the same issue on different machines with different Hardware and ubuntu 16.04. Tried also ubuntu 16.10, but the same thing. Rendering chrashed by 99%. Sometimes also by 65% and so on.

At the moment ist very bad to create a Video with kdenlive. Especially when there are some bigger Projects ist not so easy to Switch to another Editor until the developers fix this in kdenlive.

Ist not clear for mer why the developers working on new Features and dont spend time in this significant bug which make kdenlive unusable.
Ist possible to make beautiful Projects but not to render them.

I solved the problem for me now finally.

After 10 years using linux, i bought yesterday a win 10 pro licence for 7,95.- €. I tried several video editors under Windows and there are a lot of good piecec of video software. Not expensive, from 20-70 € but working without problems and have support.

I love linux and open source but after this bug i was **** of totally and switched.

Good bye video editing under linux and good bye waiting that somebody fix a problem. Spending a lot of hours to create a great project with kdenlive but was not able to export it because of this bug.
Now its enough.

Have a good time with this things.

Farewell and good luck to get bugfixes faster for a PAID program.

capslock wrote:Farewell and good luck to get bugfixes faster for a PAID program.

Thank you.

Have tried the "PAID" program and have to say it dosnt have tons of bugs like kdenlive. And the next thing is, i reported somethign and get answer in a few hours with a solution.

And have you seen what wegwerf wrote in the bug report? They cant do anything, it depends on the distribution. hahaha, very funny.
Have this error under ubuntu (different versions), Mint, and last but not least, the same error with kdenlive under Windows.

But they cant do anything. Its more important to implement new features but a lot of this is not working. Video editing under Linux will always be like cutting a tree with a knife.

No, I didn't check the bugreport and comments But I can understand (as a software developer) and remember (as a long time user of kdenlive (since version 0.5)) that there have always been differences in distros and repositories that have led to a broad variety of hardly understandable errors. Arch seems to be quite robust and works 99% without drop outs.

If you are on the sunny side of video editing now - welcome, no matter that we are on different "islands."

oluja wrote:

capslock wrote:Farewell and good luck to get bugfixes faster for a PAID program.

Thank you.

Have tried the "PAID" program and have to say it dosnt have tons of bugs like kdenlive. And the next thing is, i reported somethign and get answer in a few hours with a solution.

And have you seen what wegwerf wrote in the bug report? They cant do anything, it depends on the distribution. hahaha, very funny.
Have this error under ubuntu (different versions), Mint, and last but not least, the same error with kdenlive under Windows.

But they cant do anything. Its more important to implement new features but a lot of this is not working. Video editing under Linux will always be like cutting a tree with a knife.

hey oluja,

i hope you understand that this is a community project and there are VERY FEW PEOPLE maintaining the project, for a long time we only had one developer but this is changing and more developers are joining the project. I use archlinux and don't have this issue, and i edit for a living.

unfortunately it is out of our scope to fix distro specific packaging issues. We are trying to provide binary packages that hopefully will fix these problems. maybe we can set a packaging guideline for distro's...

i understand you switching and i hope you get your job done.

happy editing (no matter what software you use)

ps
give kdenlive a try by the end of the year, maybe you'll like it

I also was struck by this bug. This wasnt really a showstopper, since the video did came out. Just the process never finished

We forget that we are not customers and developers are not trying to sell software here... Getting mad is really out of the question

The process is a little different when you are a user and not a customer. Maybe you could had use that money to try to put a bounty on this particular bug and maybe some developer would had pay more attention to it

I would have tried blender (yes, blender has a video render tab and it works quite nicely) before going to windows. But maybe its just me. Im not going to put up with windows as a whole just because a bug in a program

I am wondering if it is Distro specific, I downloaded the latest version in the .deb and it had these problems, what if I build from source? I am running elementaryOS Loki (it has an Ubuntu 16.04.2 base) so that could be a problem. I am wondering if someone has something they want me to try? I can't until Thursday because my laptop hard drive failed and I am waiting for a new SSHD and Intel WiFi card to come in. I will make a fresh install and try building from source, can someone give some guidance? I never have built from source. Thanks again for all the help guys!

I'm a bit lost with all these testimonies...
For everyone of you, did you try:
1) disabling GPU processing?
2) rendering zones to find if a special timeline section is the culprit (heard once that removing some dissolve/wipe transitions helped to complete render, long time back it was title clips that caused problems...) => that would help a lot in debugging
3) trying other codec/container formats?

vpinon wrote:I'm a bit lost with all these testimonies...
For everyone of you, did you try:
1) disabling GPU processing?
2) rendering zones to find if a special timeline section is the culprit (heard once that removing some dissolve/wipe transitions helped to complete render, long time back it was title clips that caused problems...) => that would help a lot in debugging
3) trying other codec/container formats?

Yup tried all of thee above, disabling GPU processing fixes the problem entirely with the sacrifice of amazing effects, rendering with GPU processing enabled at all(even if your not using a GPU effect) it would cause this bug. rendering a complete fresh video simply put on the timeline with no effects resulted in this bug with GPU Processing enabled but the exact same scenario with GPU Processing disabled it render just fine and also way faster.

I have exactly same problem. How now looks like GPU with Movit works fine for project building. Preview works fine without any glithes or freezes.
But rendering is not possible with GpU enabled, it always freezes on 99%. Always stuck with broken video file

Looks like I found a wrokaround or solution or reason.

According MltFramework specs gpu rendering should not be used with multicore processing.

Do not try to use parallel rendering threads with real_time > 1 or real_time < 1 at this time.

In my case I have generated script and removed from the end parameters with number of thread. And render finished well.
I tried to monitor load and CPU loading was not singlecore, gpu load was about 25%.