On Fri, Nov 12, 2010 at 7:35 PM, Dan Dennedy <d...@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 <avi...@freebsd.org> http://people.FreeBSD.org/~avilla ------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kdenlive-devel