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

[Alberto Villa]

On Fri, Nov 12, 2010 at 7:35 PM, Dan Dennedy <dan at dennedy.org> wrote:
> 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.

i was tempted to do the same, but i wasn't 101% sure i was doing
everything right

> 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.

this makes so much sense

> 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.

yes, they really do

> 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.

ok, i'll just try with this basic questions then, but i agree it's
definitely not worth a bug report

> 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?

thanks for the extensive clarification, it was interesting! :)
-- 
Alberto Villa, FreeBSD committer <avilla at FreeBSD.org>
http://people.FreeBSD.org/~avilla