[Kdenlive-devel] KDEnlive Bugs I encountered

[Dan Dennedy]

2012/1/20 Stefan Naumann <snaumann2912 at yahoo.de>:
> the second can. I guess. Adobe Premiere has so small projects - why can't
> KDEnlive have this small projects?

What makes you think Kdenlive has large projects? If the XML were
compressed it would be smaller.

> Running stuff as seperate process would be nice, for example the transcoding
> dialog, if KDEnlive crashes, the dialog should still be present and

It the parent process dies, then so do the child processes unless the
children are fully detached like a daemon. To run ffmpeg detached
means you can no longer pipe the ffmpeg text output to the parent
process to monitor its progress and show errors. So, a wrapper that
uses dbus, HTTP, or other IPC mechanism needs to be created and
debugged.

> Another thing: why is AVCHD not supported? Or let's say badly. Editing it -

Because it is a difficult engineering task and lacks the attention of
qualified contributors to libav and ffmpeg. For the technical detail
on the difficulty of the engineering task you need to ask a libav
software engineer familiar with the topic. They may say seeking is not
so costly, but they tend to think in terms of media player or whole
file transcoder. A video editor not only needs frame accurate seeking
but also that frame needs to be decoded cleanly. Initially, we had
much faster seeking, but as soon as you set the in point other than 0,
your project became useless due to artifacts.

> there should be proxy clips (I like the ffmpeg way - so if you'll have more
> presets: do not remove the ffmpeg-way), and when the project is rendered -
> why should the renderer care about it being AVCHD or not? When in doubt: run
> ffmpeg over it with that high bitrates, that there can't be a loss of
> quality.

Huh? What is your point? Kdenlive already supports proxy clips, and
the renderer already does not care whether is it AVCHD or not.

-- 
+-DRD-+