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.

I disagree. I don't want the dependency of a database. This might make sense for certain workflows and custom integration, but this tool is designed for fellow average users. More than likely some members of the team would be willing to work on custom integration features under contract.

Filenames should not be hidden because that is not transparent. When things **** up as they will - after all its a computer - the filenames are helpful. Normal people understand files they create and how they are named. Keeping filenames in the process helps them understand what is going on instead of having to run manual database queries and mentally mapping label X to file Y.

Secondly, kdenlive does not have a "native format." Again, that is the realm of professional environments with automation systems and conformance requirements. Kdenlive already reads some MXF files because FFmpeg supports it, but it does not write any metadata into them.

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.

BTW, after trashing this idea here, I must admit that earlier today, I was taking a good look at OpenEdit Enter Media - a Digital Asset Manager. I think it would be nice to have asset management and database catalogs - just not tighly integrated and dependent. I am thinking another tab in the kdenlive environment could embed webkit and refer to a URL of any choosing. Then, there can be some DBus or web service API to allow database frontends and asset managements to send assets into kdenlive - individually or the entire project - with version tracking and all that. Some integration ideas can be learned from MLT's first video editor Shotcut:
http://mlt.svn.sourceforge.net/viewvc/mlt/trunk/shotcut/README?revision=620&view=markup

Oh, and Shotcut is a good example of something highly tailored to a certain workflow and designed for custom integration. And also a good example of something the general computer user does not want to use. :-)

BTW, as a result of Shotcut, MLT has an effect templating system, and you can use metadata to choose and fill in the templates. I do think this might be something a general user can use. There can be online sharing of these templates complete with stock graphics and what not. In my last video, I used a lower third title twice, and I could have used a template for that. As it were, I could not even successfully copy and paste it.

Heh, speaking of this talk of native formats, I read this in my inbox this morning:

"Will Final Cut Pro 7 allow real NATIVE editing of non-.movs?"
http://www.studiodaily.com/blog/?p=1522#more-1522

>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 :-)

"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."

While I think much of what you write is very interessting, I have to comment on the above: remember, we need to deal with the bugs (currently 325 open), that people all over the world file, many of them related to specifics about their source material. The clearer the connection is between that and the bugs people hit, the better for all involved.

Whenever kdenlive mature to the point of bugs beeing rare, perhaps filenames would play a lesser role.

I totally agree on that, and I understand what you mean. I am not aiming at making it impossible to get at, I would just prefer to be able to click and hide it and save that as a standard for my projects.

I don't know any "heavy" editor that work with thumbnails in their sources bins. They are all in text only mode. This mode is very similar to the "Details" mode of a Windows folder. A small icon to the left to determine filetype, then the clip name (can be long, but should usually be kept fairly short - film has it's own naming convention here), then I presonally like to display a column with duration of the clips. After that I usually put the column that show me what tracks are available, and then the one that show me any deleted tracks. There are more tracks in my usual setup, but I think you get the idea.

Also, it is important to be able to have several of these bins/folders open at the same time and freely move them around so that you can structure your story as you feel like.

I suppose a library view ala Amarok or other music jukeboxes is not a terrible thing. I think Kdenlive should consider taking advantage of KDE4 technologies like Nepomuk. It would be nice to have the KDE notes, tagging, and ratings available within Kdenlive as well as Dolphin and desktop search - not just for viewing, but also setting, sorting, and searching.