I have no idea what Kdenlive is using for the project part, but I would like to see a MySQL backend that I could run on my home server. In addition, I would like to have the video clips in a shared folder on that server so that I can work on the same material and maybe even the same project from two or more different systems.
One good scenario for this would be to have one system capture media, while I am already starting the editing on a different PC.
Another HUGE benefit would be the possibility to remodel the project part of Kdenlive. Instead of having a project tree, I would prefer to be able to open a number of bins/folders at the same time to organise clips and sequences. The first step of a project is always to organise the sources, and a lot more metadata is needed than the few columns that are present there today.
Filename can be hidden as it is not relevant for editing. And thumbnail should be optional as you do not really need it after you have done the organising part. But an icon to signify what type of clip it is (video, audio etc.) might be useful. Name, duration, TC in (in some situations), Tracks (what tracks exist in the material V/VA1-2/VA1-4 etc.), Offline (missing tracks - someone deleted them), color coding, audio frequency, video format and any number of user created columns would be good to have. I usually add separate columns for location, persons, shot type and sometimes other things. It all depends on the type of project.
This flexibility is the reason behind Avid's success. And it is something that Kdenlive could use and build upon and this would actually put Kdenlivefar ahead of many of the established systems out there.
One more thing - all this metadata needs to be written to the mediafiles immediately. Even if the database crashes, it should be possible to get all the clip info back. I have no idea what the native format of Kdenlive is, but it needs to support metadata that can be changed without altering the data of the file.
Avid uses MXF as file container with whatever codec you choose to use, FinalCut uses QuickTime and others uses other types of containers. MXF would be a great choice if possible as it is a standard, but I have no idea if that standard is freely available.
More information on MXF can be found here
http://en.wikipedia.org/wiki/MXF
http://www.mxf.info/ (click on Forum in the left menu)
To be able to exchange information with other applications, a format called AAF has been developed. MXF is a sub-section of this. As an example, MXF is used as a source container in Panasonic's P2 cameras. And as Avid MediaComposer uses the same version of MXF (Atom - audio and video in separate files), the files from the P2 cameras can be directly opened in MediaComposer without any import or conversion. I would love to be able to do this in Kdenlive.
A last thing - the media files should never be touched again after being captured (exept for updating metadata). Any rendering would of course generate new mediafiles and the sequence takes care fo where it goes in the timeline.
Sorry for wandering off a little from the pure MySQL case, but it all ties in with each other, so I hope it is not too confusing. I'll try to answer as well as I can if anyone needs clarification.
>It sounds like you have a lot of experiencein this area. Perhaps a bit too much. We are not trying to build a monstrous, >feature-laden thing that is difficult to maintain, distros to build, and users to understand and fix when things go wrong. No, >that sort of thing is what the "professional" vendors try to sell to justify their prices, support contracts, and professional >services. Stop thinking professional, and start thinking about what your drinking buddy can use to make videos of his family, >travels, and hobbies.
Actually, in video, all "dumbing down" I have seen has been limiting what a person actually can do. It does not take them very long to grow beyond the limits of a "dumbed down" software, and then they go looking for something that work the way it should.
And if you think that "thinking professionally" means adding features in droves, you got it all wrong. The only reason companies add a lot of effects and fancy functions is because of inexperienced users that come with this first question: "How many effects does it have?". The real answer should be "One. Dissolve". That would make a LOT of pro-users happy.
What a pro-user wants is a system that can edit as fast as possible with as few keystrokes and clicks as possible. And, big coincidence, this will also be something that my drinking buddy will have no problem understanding.
Double click to load clip in player. Press button to play. Press button to set in. Press button to set out. Press button to add to timeline. Double click on next clip, and so on...
We all have to remember that video is about communicating a story and that the tool should not get into the way. Too much bling in the system or in the video takes the attention away.
A quick comment on using a database structure to allow for more metadata:
It is just another tool for helping build the story structure. It might be helpful for a tech guy to see the filenames when something goes wrong, but neither my drinking buddy or me waste any calories on filenames in the editing. What matters is the picture and whatever information about the content we can get our hands on.
Another thing: In general, I do not like that users mess around with the mediafiles directly in the folders. A lot of the times they end up deleting files that are vital to their project and need help to fix the problems. It would be better to have a database that can control what files are needed where and warn when the user is about to do something potentially harmful.
Just my 2 centavos :-)