[Kdenlive-devel] slowness with hd video on quad core

Dan Dennedy dan at dennedy.org
Fri Nov 12 19:35:44 UTC 2010


On Fri, Nov 12, 2010 at 1:49 AM, Alberto Villa <avilla at freebsd.org> wrote:
> hello lists!
> how long! :)
>
> i have a problem with a user on freebsd:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=151938
> in few words, even with his quad core computer and his nvidia card,
> he's not able to work with hd video because it's too slow. only

He posted a bug in kdenlive.org/mantis and I immediately closed it
because a bug report that basically says "go faster" is useless. It is
too high; that is a goal, not a bug. Just like goals of being stable
or easy-to-use.

> recently i bought a laptop with nvidia (i had intel), so i know
> nothing about nvidia, vdpau, and all those terms i've not cared about
> too much in the past, and i'm not able to give it a try at the moment
> do you have any suggestions (fyi, we have a libvdpau port, but i don't
> know if it can be useful)?

Within Kdenlive/MLT, vdpau is not much faster than a modern, powerful
intel cpu. It is hard for people to understand or believe this because
they try to compare it with mplayer as he has done. In a player, the
decoded video can stay in video memory for display. In a video editor
(or playback with some enhanced filters) the uncompressed video must
transfer back to system RAM over PCI, processed - possibly through
multiple stages - and then transferred back to video RAM for
presentation. That is a huge bottleneck. OK, so, let's just use the
GPU for everything, right? Except we are small team of part-time
hobbyists. The the new Adobe Premiere Mercury Engine basically does
this, and it is very impressive, but Adobe has extensive resources to
pull that off.

Information about his video format is here:
http://www.kdenlive.org/video-editor/toshiba-camileo-s10

As long as it really is a MOV container, then it should not suffer the
lag of seeking in AVCHD TS files. Maybe if it progressive scan, it can
benefit from parallelized decoding, which can be set in the Advanced
tab of the Clip Properties. Is he using a source or binary package?
Either way, was his FFmpeg built with yasm installed and pthreads
enabled? Is he using a project setting profile that matches his video
clip? If not, then the must be scaled in software.

Basically, it is idiotic to compare a video editor to a media player.
How do you compare something that needs frame accurate seeking, higher
depth colorspaces (we convert yuv420 to yuv422 and rgba currently),
and compositions of mixed resolutions (necessitating scaling and
padding) to something as simple as sequential playback with typically
no post-processing and only moderate seeking requirements?

+-DRD-+




More information about the Kdenlive mailing list