Kdenlive/KDE4 Porting
From Wikibooks, the open-content textbooks collection
Contents |
[edit] Installing Kdenlive for KDE4 from SVN
Install KDE4.
You need a recent mlt compilation with qimage for qt4 producer.
Checkout mlt from svn:
./configure --prefix=/usr --enable-gpl --qimage-libdir=/usr/lib/ --qimage-includedir=/usr/include/qt4 --disable-mmx --avformat-swscale make clean make sudo make install
Checkout mlt++ from svn:
./configure --prefix=/usr make clean make sudo make install
Checkout kdenlive from svn:
svn co https://kdenlive.svn.sourceforge.net/svnroot/kdenlive/branches/KDE4
Then compile:
cmake -DCMAKE_INSTALL_PREFIX=/usr CMakeLists.txt make sudo make install
This is it!
New features and to-do-list
The aim of this page is to coordinate efforts in the KDE4/QT4 port of Kdenlive. Below you will find a TODO list, if you are interested in contributing, you can add your comments or send an email to the Kdenlive-devel mailing list.
Unless stated, nobody is yet working on these items.
- Project Tree
The project tree is currently being ported (j-b-m). A nice feature could be to use the Nepomuk tagging and rating stuff (in progress j-b-m).
- Effect List
There is currently some work on MLT that should enable Kdenlive to automatically get all effect names and parameters directly from MLT... (mostly done)
- Effect Stack
Overview over the Parameters like in the mockup: Complexparameter (also use this for constant paraemter, with breaking the filter into smaller parts)
- Transitions
We should find a better way to implement Transitions, ideas welcome
I think that the current way of adding transition between two tracks is not very intuitive. I think that should be better to have the possibility to add a transition between two clips in the same track, just dragging and dropping a transition in between the two clips. I imagine that at that point the transition is a sort of "overlay" between two clips in the same track, as shown in this mockup (A):Pointing the mouse near the borders of transition permits to "resize" the transition itself, in the very same way regular clips work. You can also "move" the transition to left and right (changing the entry and exit point of transition at the same time) and of course selecting it you can change its properties in the transition window. -- Augu * Idea is nice, but not implementable in this way i think (since the clips overlap each other, and so the start and endtime will change with this. later clips must then all moved in timeline (maby not good for some reasons) what about this (B):
--G.Marco * The problem with idea (A) is also that you cannot make transitions between 3 clips. For example if you work on an animation, using 3 tracks for different characters that should all have transitions, it is not possible in an intuitive way. I would rather see idea (B) implemented. -- j-b-m * Idea A is a lot better because it saves a lot of timeline space. The need for transitioning 3 or more clips could be satisfied (perhaps at that point we could call it multiple exposures?) by adding opacity rubber band to tracks. But I'm not sure if there is a "under the hood" problem with this. Almost all other NLE's use single track editing (idea A) so it could make Kdenlive more familiar. -- rudlavibizon * it is no internal technical problem, but a timeline problem. if a NLE uses this kind of transitions (like ULEAD ??) then you have no timeline. if you have in track A 2 clips and in track b another, and you put a transition between the two in track A, then the second clip in Track A moves left and is not in sync with track B anymore (with the transition of 2 clips you have a lost of frames, beacuse they overlap). can you explain how this should be solved ? -- G.Marco * It would only loose sync if the start of the clip is the actual start of the source clip but this is a moot point since, obviously, you need some "slack" if you want to do a dissolve in the first place. This means that the part of the clip which is being "mixed' in transition is not actually seen on the timeline but is represented by the transition rectangle itself. Here is an explanation for this in Premiere: [1]This the way that editors marked transitions on the traditional editing tables. They would mark the in and out points of the transitions on the celluloid of the both clips then splice half of it out (on each clip) and join the two clips, mark the space from the in point of the transition (!) of the first clip to the out point of the second to be done in the lab. If you have a clip B (in sync) the editor should anticipate that (in case there is no "slack" on the clip) she or he should move all other clips that come after it to make the slack needed for the transition just as she or he should move them in the other case where putting the clips one above the other in order to make a transition. I know that Premiere, FCP, Avid, Cinelerra, Edius and probabaly Vegas have this way of transitioning. Premiere had the A type up until the 6.5 version but changed this when Pro got out. --rudlavibizon * i think, if the editor must take care of keeping some spare frames at the beginning, this is not so good for beginners (pro users maybe can handle this). the idea (A) is shorter than (b) ans would save space in timeline, but what if you have some yours of video in the timeline with hundredts of transitions and you decide to make in the middle an transition longer or shorter, or make one where a hard cut was before ? then you must move ALL clips after that ? if this all would handable the idea is good. i think i must take look who others NLE did this. in the premiere link i did not see ho they handle the video after the clip , after inserting the transition 2nd: we have sure with this a technical problem ! mlt has only transitions from one track to another. then me must rewrite the time with (clip a ) -> (clip b) on track 1, so that we have 2 tracks with that. --G.marco But isn't this problem the same in any case if you want to make the intervention in the middle of the sequence? If you want to make a longer transition in case A you just extend clips, in case B you extend transition handles. If your clips in point is also the sources in point, you have to move all clips beyond it towards the beginning. Only in case A you adjust it over or under the first clip of transition and in case B you move the edit point (the in point) further in. All other clips after that edit/transition would have to follow these adjustments ofcourse --rudlavibizon
- Undo History
Done (j-b-m)
- Project overview
It would be cool to have a widget showing a thumbnail of the entire project, with all tracks and clips, and the area currently shown in the timeline could be highlighted. This could also be used to navigate quickly through the project by dragging the highlighted area Maybe Qtractor could be worth to take a look on that? BTW - also the audio thumbs looks nice...
- Titler
Rewrite the titler, QT4 should allow to create much better image titles, with transparency settings for each object
A simple Titler is in kdenlive now. is should support two viewports (for scrolling, moving titles) save the title extra in kdenlive and load this with an extra producer (TODO) in mlt --G.Marco
- Timeline
Rewrite the timeline. The Ruler could use the KDE KRuler class (in progress: j-b-m and G.Marco).
I think that selection and zooming can be improved. For example SHIFT key can be used to select a region in the timeline (click at time A, hold SHIFT and click at time B -> region between A and B is selected), another useful features could be "zooming to selection", for example to fine tune a transition (see above). -- Augu
Split clip tool could be improved if the feature where you can see the exact frame in the monitor by hovering over the clip stays. For example, you could trim the clip by finding the place to cut and then click and drag mouse left or right to delete the remainder of the clip (left or right) at the same time. By using the shift or ctrl or alt + click and drag you could "ripple" delete the empty space as well -- rudlavibizon
- Audio Thumbs
Audio thumbs could probably be improved, for example the QT4 Traverso audio editor has some great thumbnails, maybe someone could have a look at it and why not use the same thumbnail format as they use...
mainly done, but traverso stores the whole clip in memory and create thumbs from this (not good for long clips) --G.Marco
- Rendering
Rewrite render dialog Make render jobs use a separate process, so that rendering does not abort if Kdenlive crashes(done, j-b-m) Show progress in KDE's Job Viewer (done, j-b-m)
- Capture
Mostly done (j-b-m). Now we also support capture from Video4Linux2 devices (webcam) through FFmpeg
- Control devices
Add support for Jog Shuttle devices (mostly done, needs testing - j-b-m)
- Clips
Transparency setup for every clip with keyframes. A cut in a clipshould not allow resize over the start/end of the cut.
[edit] Installing Kdenlive for KDE4 from SVN - the easy way
The Kdenlive Builder Wizard can build the KDE4 (or KDE3) version of Kdenlive from current development sources. It is available from [2] and is suited both for one-shot builds, or automated nightly builds (the later requires obtaining the sources to the Wizard, available from the page).
[edit] Possible problems
If your compilation ends with something like:
MakeFiles/kdenlive.dir/projectlist.o: In function `ProjectList::slotAddClip(DocClipBase*, bool)': /home/jan/src/kdenlive/src/projectlist.cpp:293: undefined reference to `Nepomuk::Resource::Resource(QString const&, QUrl const&)' /home/jan/src/kdenlive/src/projectlist.cpp:293: undefined reference to `Nepomuk::Resource::~Resource()' /home/jan/src/kdenlive/src/projectlist.cpp:174: undefined reference to `Nepomuk::Resource::~Resource()' /home/jan/src/kdenlive/src/projectlist.cpp:174: undefined reference to `Nepomuk::Resource::~Resource()' collect2: ld returned 1 exit status make[2]: *** [src/cmake_bindir/kdenlive] Error 1 make[1]: *** [src/cmake_bindir/CMakeFiles/kdenlive.dir/all] Error 2 make: *** [all] Error 2
Then you have to install soprano and soprano devel package and rerun cmake or use wizard builder once more time.

