So I got myself a shiny new workstation for video editing with a Core I7-4770, 32GB RAM and an Nvidia GTX770 (plus an additional GTX560) and changed from Opensuse to kubuntu, just to find out that my workflow with KDEnLive is as lame as on my shabby old Phenom2 machine - or even worse. Well, the final rendering is a bit faster (fire up the number of render threads and actually get 70% total CPU usage!), but first and foremost, KDEnLive struggles heavily to display AVCHD files and if you apply even simple filters or transistions, it stutters badly. That should look quite differently! If I activate OpenGL playback, it gets even worse.
After some testing, I'm fairly convinced that libav and MLT (which KDEnLive bases the playback and effects on) do not utilize OpenGL/OpenCL properly although they should - in theory. Unless, of course, the Ubuntu packages are compiled with OpenCL disabled. OpenCL is set up properly on the system and e.g. darktable uses it without problems.

I am already transcoding all input material to DNxHD - which uses about 2GB per minute (!)... With that, it works fairly fluent but also, when I add a couple of filters - typically tone curve and such for grading - it starts stuttering at some point. But - really - I already have a 12TB storage system and if I have to use DNxHD for every project, that will overflow in a matter of weeks...

Shotcut (the new editor from the MLT project) e.g. is ragingly fast with hardware accel activated but unfortunetaly, it's in a rather early development stage and yet missing a number of (for me) essential filters and effects.

Can anybody provide some insight into this matter? I'm almost desperate enough to set up dualboot with Windows and get Vegas or something like that...

Sorry, I can't help you with openCL, but making use of proxy files would at least show higher performance in preview.

Proxy files are useless if you do more serious color grading and frame-accurate editing because their resolution is too low.

Then try a higher resolution Proxy Profile which I guess a lot of people do. I have no problem with frame-accurate editing. The default is good for low spec. systems.

I always leave colour grading to last and then disable the Proxy to colour grade the HD clip.

As soon as I go high enough with the resolution to actually be able to judge the results of the filters properly, I get stuttering again. It doesn't make a difference if I play an mpeg transport stream (proxy) or DNxHD then... It SHOULD/would make a difference if KDEnLive would actually use OpenCL, CUDA or at least VDPAU... ... ...

Is it possible that the project is dead? I mean, there are bugfixes but in a huge project like KDE, I guess, devs who fix bugs are not too hard to find.
IIRC there hasn't been any major evolution of KDEnLive in the last - what - 2 or 3 years? KDEnLive IMHO still offers the best workflow and most possibilities on Linux but a number of other projects are evolving very fast, like the mentioned shotcut.

And in a time, where professional 1080p movie cameras cost only $500 and you can get a professional 4k camera for $3000 (or simply use a $400 GoPro), lacking hardware accel is a major turnoff.

And with dead I mean "not actively developed any more"...

We nearly got some OpenGL stuff with the most recent version of kdenlive - via the MLT frame work. http://www.mltframework.org/bin/view/MLT/OpenGL

However, the kdenlive developers could not get the program to work in such a way that users with older GPUs could run kdenlive while also having users with more modern GPUs run kdenlive and take advantage of the OpenGL stuff - see http://kdenlive.org/mantis/view.php?id=3251.

Once that gets sorted out you should expect to see OpenGL stuff in kdenlive.

That looks like the Movit GLSL filters, right?
Or is this the fix for the general video output via OpenGL? When currently choosing OpenGL as an output channel in the settings it actually makes everything even slower for some reason.

I have found some indications that KDEnLive is supposed to support VDPAU already for a long time (s. http://www.kdenlive.org/kdenlive-nvidia ... mpeg-patch) but that doesn't seem to work on Ubuntu 14.04 either.

Besides, I'm using sunabs stable PPA.

Edit:
VDPAU is set up properly and works e.g. with vlc...

Code: Select all

sgofferj@enterprise:~$ vdpauinfo     
display: :0   screen: 0
API version: 1
Information string: NVIDIA VDPAU Driver Shared Library  331.38  Wed Jan  8 19:13:15 PST 2014

Video surface:

name   width height types
-------------------------------------------
420     4096  4096  NV12 YV12
422     4096  4096  UYVY YUYV

Decoder capabilities:

name               level macbs width height
-------------------------------------------
MPEG1                 0 65536  4032  4048
MPEG2_SIMPLE          3 65536  4032  4048
MPEG2_MAIN            3 65536  4032  4048
H264_MAIN            41 65536  4032  4080
H264_HIGH            41 65536  4032  4080
VC1_SIMPLE            1  8190  2048  2048
VC1_MAIN              2  8190  2048  2048
VC1_ADVANCED          4  8190  2048  2048
MPEG4_PART2_SP        3  8192  2048  2048
MPEG4_PART2_ASP       5  8192  2048  2048
DIVX4_QMOBILE         0  8192  2048  2048
DIVX4_MOBILE          0  8192  2048  2048
DIVX4_HOME_THEATER    0  8192  2048  2048
DIVX4_HD_1080P        0  8192  2048  2048
DIVX5_QMOBILE         0  8192  2048  2048
DIVX5_MOBILE          0  8192  2048  2048
DIVX5_HOME_THEATER    0  8192  2048  2048
DIVX5_HD_1080P        0  8192  2048  2048

Output surface:

name              width height nat types
----------------------------------------------------
B8G8R8A8         16384 16384    y  Y8U8V8A8 V8U8Y8A8
R10G10B10A2      16384 16384    y  Y8U8V8A8 V8U8Y8A8

Bitmap surface:

name              width height
------------------------------
B8G8R8A8         16384 16384
R8G8B8A8         16384 16384
R10G10B10A2      16384 16384
B10G10R10A2      16384 16384
A8               16384 16384

Video mixer:

feature name                    sup
------------------------------------
DEINTERLACE_TEMPORAL             y
DEINTERLACE_TEMPORAL_SPATIAL     y
INVERSE_TELECINE                 y
NOISE_REDUCTION                  y
SHARPNESS                        y
LUMA_KEY                         y
HIGH QUALITY SCALING - L1        y
HIGH QUALITY SCALING - L2        -
HIGH QUALITY SCALING - L3        -
HIGH QUALITY SCALING - L4        -
HIGH QUALITY SCALING - L5        -
HIGH QUALITY SCALING - L6        -
HIGH QUALITY SCALING - L7        -
HIGH QUALITY SCALING - L8        -
HIGH QUALITY SCALING - L9        -

parameter name                  sup      min      max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH              y         1     4096
VIDEO_SURFACE_HEIGHT             y         1     4096
CHROMA_TYPE                      y 
LAYERS                           y         0        4

attribute name                  sup      min      max
-----------------------------------------------------
BACKGROUND_COLOR                 y 
CSC_MATRIX                       y 
NOISE_REDUCTION_LEVEL            y      0.00     1.00
SHARPNESS_LEVEL                  y     -1.00     1.00
LUMA_KEY_MIN_LUMA                y 
LUMA_KEY_MAX_LUMA                y 


libav also has VDPAU support

Code: Select all

sgofferj@enterprise:~$ avconv -codecs | grep vdpau
avconv version 9.14-6:9.14-0ubuntu0.14.04.1, Copyright (c) 2000-2014 the Libav developers
  built on Jul 15 2014 13:57:40 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
DEV.L. mpeg1video           MPEG-1 video (decoders: mpeg1video mpeg1video_vdpau )
DEV.L. mpeg2video           MPEG-1 video (decoders: mpeg2video mpegvideo_vdpau )
DEV.L. mpeg4                MPEG-4 part 2 (decoders: mpeg4 mpeg4_vdpau ) (encoders: mpeg4 libxvid )
DEV.LS h264                 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_vdpau ) (encoders: libx264 )
D.V.L. vc1                  SMPTE VC-1 (decoders: vc1 vc1_vdpau )
D.V.L. wmv3                 Windows Media Video 9 (decoders: wmv3 wmv3_vdpau )


So, theoretically, KDEnLive should be able to use it - if it was complied with VDPAU supprt, that is...

Hello,

GPU decoding improves video navigation... if the display remains in OpenGL.
Unfortunately OpenGL monitor in Kdenlive is not really as good as it could be, so not the prefferred setting at the moment.
In any case, as soon as you add effects or transitions, processing is done in CPU and slow 2-ways memory transfers are unavoidable (until we switch to Movit and stick to only what it provides, no frei0r etc).
To get an idea of what we could reach in short/mid term, try with Shotcut.

You can benefit from the power of your machine mainly when rendering, encoding in complex format like H264.
MLT processing multithreading was problematic and is now disabled by default, but it is not that slow for most effects.
Encoding FullHD in H264 is often the most heavy part, and there libx264 can use your CPU almost fully.
For this task it could also be possible to use GPU, like GStreamer-VAAPI, but not yet available through FFmpeg/MLT.

BR,

Vincent

old thread , but why you want to transcode your files into DNxHD ? if you want to load in vegas, then you can go for mpg, which may occupy your space less.

Because h.264 is a delivery codec, not an edit codec. Editing in h.264 is slow and lossy. Using a dedicated intermediary/edit codec is fast and (almost) lossless.
But I already changed from DHxHD to ProresHQ.
MPG is even worse than h.264 with regards to loss and compression artefacts.