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 see any indicator that it create VIDEO proxy clips... Audio-ones ... yes. But no Video proxies.? ? ---------- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20120207/9a97f157/attachment.html>
