On 02/07/2012 08:47 PM, Stefan Naumann wrote: > What? I have to "manually" create them? VLC does it way faster than
??? > KDEnlive ... there are some differences between the two projects, but I > think VLC does it nicely whereas KDEnlive is pretty slow... And I don't VLC is just a player. Just one layer. No editing. > see any indicator that it create VIDEO proxy clips... Audio-ones ... > yes. But no Video proxies. http://userbase.kde.org/Kdenlive/Manual/Projects_and_Files/Clips > ---------- Waren Sie schon auf: www.oettinger-games.net.tf . Helfen Sie mit. > ------------------------------------------------------------------------ > *Von:* Simon A. Eugster <simon.eu at gmail.com> > *An:* Stefan Naumann <snaumann2912 at yahoo.de>; For kdenlive developers > <kdenlive-devel at lists.sourceforge.net> > *Gesendet:* 20:26 Dienstag, 7.Februar 2012 > *Betreff:* Re: [Kdenlive-devel] AVCHD > > On 02/07/2012 08:13 PM, Stefan Naumann wrote: > > Hey there - again. > ------- 8< ----- > > And the second point: AVCHD. (H264). I always record in H264 for it > > resulting in smallest filesizes with high CPU Load while decoding. :D I > > see it's a pretty hard video codec, but as far as I unterstand it there > > is one image fully defined and then only the changes based on the one > > full picture. If there is a change, that is too big or o heavy there > > will be another full frame. (i-Frame (????)) I see that even Adobe > > http://en.wikipedia.org/wiki/Group_of_pictures > H.264 not only uses P-frames (which is what you described; basically > they are predicted from preceding I-frames and the I-frame data corrects > the error that is created hereby) but also B-frames which are predicted > from anywhere, like from the last I-frame or the next P-frame. All very > CPU intense, therefore the decoding algorithm is often implemented in > hardware today (e.g. on the GPU or other chips like also on smartphones). > > > Premiere has its problems with this codec, but it is in my humble > > opinion the best one for sake of my harddiskdrives. Adobe (apparently) > > searched bad to the last i-frame and builds all later changes on top of > > it ... so it is pretty slow loading a random position in a video. But > > KDEnlive is too slow to accomplish a nice editing envirornment. The > > video in Timeline is too slow --- for 5 seconds then there is ja jump to > > the real position after the 5 seconds. I can understand it hanging for a > > while, when I clicked on a later point in time ... searching for last > > iframe ... but if it is always so slow... that's just unusable ... I > > hope this critics are not taken personally - And maybe I helped you to > > make an even better editing experience for video cutters all around the > > world. ;) (nice sentence, ain't it) > > Actually not our problem since decoding is done by ffmpeg. H.264 > decoding will probably never be fast done in software. > We have proxy clips for this however. I have edited some projects with > proxies already, works better than anything else. > Note that you have to enable them in the project preferences, then you > can right-click on your clips in the project tree and select ?generate > proxy? or so. > > Simon > > > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > > > > _______________________________________________ > Kdenlive-devel mailing list > Kdenlive-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
