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

[Evert Vorster]

Hmm, thanks for the nice tips on how to make kdenlive go faster on quad cores...

:)

-Evert-

On Fri, Nov 12, 2010 at 7:35 PM, Dan Dennedy <dan at dennedy.org> wrote:
> 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-+
>
> ------------------------------------------------------------------------------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> _______________________________________________
> Kdenlive-devel mailing list
> Kdenlive-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
>



-- 
http://magnatune.com - Music shared the way it should be.