I wanted to migrate to GNU ("Linux") for years, but could not because of the lack of some programs or functions in programs. This changed with one of the recent versions of "Openoffice". So I looked for the last thing to make me happy: A video cutter.

And I found it! Of 2 acceptable Linux Cutting-Programmes, one, Kdenlive, was supporting the .m2ts-files of my camcorder. Voila!

Then I needed some time to install it, because the installation via Ubuntu, Kubuntu, Mint or however you call it only works with two additional lines in some configuration file, and it took a very long time to google for that. In the end i found it, but not on the Kdenlive site.

Ok, now it finally worked! Heureka!

BUT:

a) if you want to open .m2ts-Files, you have to select "all files" first, because it's not one of the "supported" filetypes.
b) finally you can import .m2ts-files. But the PREVIEW is SLOW like a snail!
c) trying to click something in the clip-window nearly freezes the system

The additional problems are

1) Simple preview only uses one core
2) There is no native GPU-Support
3) Working with Proxies does not work for me

I don't say that all those problems cannot be solved with some tricks. But is the user, that migrates to a GNU-System, really expected to do all that things, inform about bugs, learn to compile programs for broken dependencies, install the vdpau-version of ffmpeg and risk instability, etc. just to cut his HD home videos?

Not even simply buying the latest hardware solves all that problems, because the only solution would be more MHz, and in CPU-production they go other ways now because of physical reasons.

HD is not future, HD is real now. And the support of .m2ts is not given only by letting slap that files onto your timeline, but by creating an environment that works fine with those formats.

Not only to do bad critics, I love Kdenlive. And I'll wait for it, until it meets my cams requirements.

Hi and sorry, but this is not true!

your point 3 is the key: use proxying! If it does not work, you use a bad packaged kdenlive or an old version. (I guess: x64-bit system with codec mishmash.) Once you set-up proxy support HD-editing is very fluid and works completely transparent.

It looks like your problems are more migration type problems. Linux is not Windows and you have to learn a few things before stuff works and this needs a little bit of time. As Linux distributions can not offer unfree (patented) codecs its double hart to start with Linux in productive multimedia area.

When you learned, what kdenlive IS, than you will notice that your points do belong mainly to dependencies of this project, hardware-support, libs and codecs kdenlive uses but does not maintain.

So my tip: try to analyse, why proxying does not work. I'm sure, this forum can help you, but we have no crystal balls ;-)

Have Fun

Thorsten

1 - I wouldn't say that kdenlive is quite ready for the general public yet. If you aren't familiar with cloning a copy of the git repo, taking care of dependencies, compiling, getting a back-trace when it crashes, etc then it is going to be a bumpy ride.

2 - For what it's worth, I use it for HD content without any issues that I don't know how to work around. Having a good understanding of how codecs actually work, their strengths and weaknesses, and how well they are supported by libraries like FFMPEG, is also key to creating a sane and usable workflow.

3 - Commercial video editing suites also have all sorts of technical issues to deal with, but they are mostly (not always) hidden from the end user by taking care of all that in the installation process. Kdenlive does not directly control how packages are built and distributed in distros, so there can be system integration issues arise from that aspect.

Kdenlive is the only Linux NLE that actually does work with HD in my opinion. I use it edit DSLR 48MB h264 and 25MB HV30 m2ts files without transcoding and do it on an old Sempron 3400 using proxies amongst other machines.

Adding those two PPA lines which I think is what you're mentioning to Synaptic because you actually have the benefit of a Ubuntu based distro has made it even easier for you to get the latest builds without need to compile, the method doesn't take hours of googling its mentioned repeatedly in the forum here. Generally the best place to research an app is the authors site, usually.

I think the problems you are experiencing are down to a lack of Linux knowledge and unfamiliarity with kdenlive, to say kdenlive is not ready for HD is vastly incorrect.

Be aware also that although you may want to do this move to Linux and who hasn't, (I've been using it for over 15yrs), your disappointed with software performance but no one owes any of us anything, if software is not up to anyones standard than we can just move on, we can work within the problems or if able help in some way.

The devs here work hard in their free time to provide kdenlive / MLT.

Stick with it and you'll find kdenlive is very good. :-)

I have to add a few things.

1.) Yes, I am a GNU noob, and all what I was saying is that Kdenlive is not HD-ready for noobs.

2.) Yes, I am working on a 64-bit-system, which is installed extra for kdenlive. So if there is a "driver tohuwabohu", that would be a failure of the Ubuntu project. And no, as a noob, I am not ready to compile my whole GNU system for myself.

3.) Now, tell me, if system requirements rise, where will Kdenlive go? More MHz will not be the future. This is a very interesting question for me.

As mentioned, I repeat that it is possible to get kdenlive HD-ready. But not out of the box.

I am definitely not complaining. But I want to do constructive critics, by asking, how I can recommend GNU to other friends, when after installation of the new, user-friendly releases like Ubuntu everybody tells you "no wonder, that nothing works, you didn't compile your whole system for yourself!".

Again sorry your noobness is showing, I recently installed 64bit Ubuntu on a new drive, added sunabs PPA and used xfce as desktop manager with absolutely no problems to get kdenlive from svn running.

No compiling straight of the box. Sorry but your criticism is a little unfounded.

If you have specific issues there are many here to help.