[Kdenlive-devel] AVCHD

[Simon A. Eugster]

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