CUDA is coming in the openGL playback plugins. However the basic openGL plugin does not need to do more than stretch/shrink the image to the screen size, so this should already use the hardware anyway.
openCV is starting to be used for some video effects/analysers (e.g. the experimental farneback_analyser). The only place it could be useful in the LiVES code itself is (possibly) by providing fastMalloc and fastFree. This would require the LiVES code to be ported to C++ first, and may not ptovide much of a speed up (LiVES uses the slab allocator from glib which is quite fast anyway);
LiVES already uses hw acceleration for resizing (vis SWscale) and uses threading for palette conversions and many of the effects
So it is already quite efficient. In fact in my latet tests I am able to play back a 1080p clip at 14.5 fps on a standard dual core desktop with a mid-range nvidia card.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
CUDA is coming in the openGL playback plugins. However the basic openGL plugin does not need to do more than stretch/shrink the image to the screen size, so this should already use the hardware anyway.
openCV is starting to be used for some video effects/analysers (e.g. the experimental farneback_analyser). The only place it could be useful in the LiVES code itself is (possibly) by providing fastMalloc and fastFree. This would require the LiVES code to be ported to C++ first, and may not ptovide much of a speed up (LiVES uses the slab allocator from glib which is quite fast anyway);
LiVES already uses hw acceleration for resizing (vis SWscale) and uses threading for palette conversions and many of the effects
So it is already quite efficient. In fact in my latet tests I am able to play back a 1080p clip at 14.5 fps on a standard dual core desktop with a mid-range nvidia card.