
<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>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. </span></div><div> </div><div>----------

Waren Sie schon auf: www.oettinger-games.net.tf . Helfen Sie mit.<br></div>  <div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "> <div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "> <div dir="ltr"> <font size="2" face="Arial"> <hr size="1">  <b><span style="font-weight:bold;">Von:</span></b> Simon A. Eugster <simon.eu@gmail.com><br> <b><span style="font-weight: bold;">An:</span></b> Stefan Naumann <snaumann2912@yahoo.de>; For kdenlive developers <kdenlive-devel@lists.sourceforge.net> <br> <b><span style="font-weight: bold;">Gesendet:</span></b> 20:26 Dienstag, 7.Februar 2012<br> <b><span style="font-weight: bold;">Betreff:</span></b> Re: [Kdenlive-devel] AVCHD<br> </font> </div> <br>On 02/07/2012 08:13 PM, Stefan Naumann wrote:<br>> Hey there - again.<br>------- 8< -----<br>> And the second point: AVCHD. (H264). I always record in H264 for it<br>>

 resulting in smallest filesizes with high CPU Load while decoding. :D I<br>> see it's a pretty hard video codec, but as far as I unterstand it there<br>> is one image fully defined and then only the changes based on the one<br>> full picture. If there is a change, that is too big or o heavy there<br>> will be another full frame. (i-Frame (????)) I see that even Adobe<br><br><a href="http://en.wikipedia.org/wiki/Group_of_pictures" target="_blank">http://en.wikipedia.org/wiki/Group_of_pictures</a><br>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).<br><br>> Premiere

 has its problems with this codec, but it is in my humble<br>> opinion the best one for sake of my harddiskdrives. Adobe (apparently)<br>> searched bad to the last i-frame and builds all later changes on top of<br>> it ... so it is pretty slow loading a random position in a video. But<br>> KDEnlive is too slow to accomplish a nice editing envirornment. The<br>> video in Timeline is too slow --- for 5 seconds then there is ja jump to<br>> the real position after the 5 seconds. I can understand it hanging for a<br>> while, when I clicked on a later point in time ... searching for last<br>> iframe ... but if it is always so slow... that's just unusable ... I<br>> hope this critics are not taken personally - And maybe I helped you to<br>> make an even better editing experience for video cutters all around the<br>> world. ;) (nice sentence, ain't it)<br><br>Actually not our problem since decoding is done by ffmpeg. H.264

 decoding will probably never be fast done in software.<br>We have proxy clips for this however. I have edited some projects with proxies already, works better than anything else.<br>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.<br><br>Simon<br><br><br> </div> </div>  </div></body></html>