Hi Steve, thanks for the mail, and welcome here! Great to have you working on Kdenlive. As Anna asked, can you make it to Randa, at least for a few days? https://sprints.kde.org/sprint/212 This would be a great opportunity to discuss those points with the developers. And to taste some Original Swiss Raclette!
Simon Am 27.06.2014 00:22, schrieb Steve Guilford: > Greetings Kdenlive developers.... > > > Inroduction > > I'd like to introduce myself. My name is Steve Guilford and I'm located > in Los Angeles, Ca. Some may have noticed my postings on the forum. > > I have over 32 years of programming experience. My speciality is in > creating frameworks, API and toolkits. Mainly in the realm of systems > integration tasks, hardware integration etc. In 32 years I've done a lot > of systems programming, architecture design, user applications, systems > integration, database design, data transformations, hardware > integrations, software/systems conversions, forensic analysis etc. etc. > I dropped out of college in 1982 in order to go to work. I've been > self-employed for 20+ years. Computers are still like toys to me. > > My Oracle expertise dates back to 1984. In 1986 I was part of a 4 man > team that converted the Oracle DB - from source - to run on the Wang-VS > line of mini-computers (that sure dates me). I'm fluent in multiple > languages, databases, operating systems and object oriented programming > frameworks. In the '90s I made a living selling telecommunications > software that I created. I had some installations that lasted, with > lucrative support contracts, for upwards of 15 years or more. > > I also created the enabling technology in the '90s for a very successful > medical services firm. This product tracked the admission and > discharging of patients from hospitals and provided doctors w/ a PDA > that uploaded patient info (via an old-fashioned modem !!!) to a central > server. Customized, dynamic surveys were then created and reports > generated for fax delivery to primary care physicians. > > > My Media Framework > > Lately, I been working on a very compact and powerful framework for the > Oracle database that allows it to be used as a warehousing, streaming, > transcoding, editing and rendering platform. This is done in a manner > that eliminates the need for physical files. All assets are stored in > the database. The framework allows you to keep video data in any > table. It does not impose any 'schema' restrictions whatsoever. This > framework is 'ready to go' !!! > > I've modified Kdenlive in a very succinct and discrete manner to allow > it to source it's project from the DB as well as edit and render content > to-and-from in the manner just described. My modifications are 'compile > time' enabled via a build switch. The modifications are contained > within '#ifdef' statements. I modified 8 source files as well as some > header files. I added 5 UI modules and corresponding UI widgets to > allow for the sourcing of projects, access/assignment of content to a > project and a 'render' screen. I've modified the CmakeLists.txt file to > enable the compile time inclusion of these features. > > Kdenlive now has the potential to be the first cloud enabled, location > independent, database capable video editing platform. Given that the > need for physical files has been eliminated, it also qualifies as > potentially the most secure architecture available. I hope to be able > to post my modifications upstream in the near future. > > > Kdenlive's Long-Term Viability > > In my opinion, the only way that Kdenlive can survive is to have a > 'corporate sponsor'; one that has a vested interest in seeing the > project supported and improved. I am trying to build just such a > business model. I am looking to build a location independent, cloud > enabled video editing environment. In this model, seats on the system > are free !!! There would be no charge for use of the editor. The cloud > system however does provide secure location independent storage and > access as well as consolidated high-performance rendering/transcoding > services. That's what you pay for. This model could be attractive to > media productions that must incorporate content from multiple locations > with the secure delivery of "daily's" for approval by lead > directors/editors. There are other benefits as well but I'll leave that > for another thread. > > I've become somewhat familiar with Kdenlive's internals. From what I've > been seeing in the forum/dev-list traffic, there are not many that have > an in-depth knowledge of Kdenlive. That's obviously a big problem. > > *I'd like to help !!!* Hopefully my 32 years of practical experience > can be useful. Kdenlive can be a terrific platform for open-source > collaborative work. Developers that work on Kdenlive would get exposure > to a wide variety of programming disciplines and concepts from > multi-threading, multi-processing, frameworks, build systems, graphics, > hardware, documentation etc. etc. Not every open-source project offers > the breadth of disciplines that Kdenlive does. I think it could have > strong potential as a 'teaching tool' within academia and the > open-source community. If that happens, the quality and support > associated w/ Kdenlive could rival the small group of high-end > professional NLE's. There would also be spillover to projects such as > Blender, Audacity etc. etc. > > > A Way Forward > > That said, there's some significant steps that need to be taken before > that can happen. Here's how I see it. > > We need to build a current roster of developers - a list posted online - > w/ skills and specific areas of responsibility. > > We need to create a developer's roadmap and documentation. This is > critical. In order to attract other coders we need to make it as easy > for them to come-up-to-speed as possible. We also need to dispel the > myth that a video editor is way to complicated 'for me' when somebody > approaches this project for the first time. The roadmap would take > somebody from start-to-finish in terms of getting them going. Here's > some of the things it would contain: > > * Specific and tested instructions for creating a local source-tree > from GIT. > * Instructions on how to upload your changes/mods/bug-fixes. > * Details on the bug system used, how to take responsibility for and > post a fix for a bug. > * Instructions on how to utilize an IDE (i.e. Kdevelop, QtCreate, > Eclipse) and create an appropriate IDE project. > * Details on using a UI builder such as QtDesigner. > * Coding standards. > * Kdenlive source tree layout (so you know where to find things and > what something is for) > * Details on Kdenlive's build system. > * Kdenlive data sources - a description of where Kdenlive keeps it's > files (i.e. project, proxies, temp files) > * A description of the Kdenlive editing project file layout. > * Details on how signals and slots are connected together in order to > implement UI tasks and other asynchronous tasks within Kdenlive. > * A UI interface gallery so that one can flip through a group of > images in order to find the desired UI and controlling 'view' module. > * A description of how multi-threading and multi-processing is used > within Kdenlive (i.e. generating proxies, thumbnails, rendering etc). > * Details on Kdenlive's internal data structures. > * A C++ class layout/diagram. > > The developer's roadmap would be an evolving set of documents w/ > provisions for user comments and contributions etc. I think some of > these items in the roadmap need to be in place before we start altering > code. Other items can be filled in as we go along. > > We need to advertise Kdenlive as a viable, attractive 'learning' > platform in order to attract academia an other members of the OpenSource > community. We need a build a reputation of being a worthwhile project > to be involved in. > > > Code Changes > > As far as code changes are concerned, I definitely have my opinions on > that. Please excuse me though - I have 32 years of coding habits built > up and over time I've seen a lot and done a lot. Kdenlive's source code > suffers greatly from 'formatting' issues. I know some would argue, but > after 32 years and countless projects and teams that I've either been > part of or led, or done by myself, there's really no way to brace and > indent code other than GNU style. Yes, it increases the vertical size > of code somewhat but do remember that when K&R style was introduced, we > were coding on VT-102 terminals w/ 80x24 screens. (I have an original > edition of K&R's Learning to Program in 'C' book - a classic - but I > digress) So, vertical size was an issue then. Now - not so much. > However, in my mind, K&R style's legacy of hard to read code and > style-induced bugs prevails. > > As you might have surmised, Kdenlive uses K&R style. So, that would be > the first code change I'd recommend - and it really would not involve > any logic changes whatsoever. It would be relatively straightforward > and easy. Braces on separate lines and 2 character indent levels. I > think that making these changes would be very important to our ability > to attract other coders. Hard to read code is always a turn-off. > > Once that is done the next area I'd address are the 'massive' routines > and the kludgey if/else/if/nested-forever statements that appear > throughout the code. In this instance I'm speaking of routines that > accomplish way too much (they need to be broken up into smaller chunks) > and 'if' statements that have too many levels to them. Breaking up > routines that are too big has a direct benefit of making the code more > 'self documenting'. This also tends to make it easier, later on, to > modify sections w/out adversely impacting other areas of code. Making > these changes would serve as a lead-up and the beginnings of a > refactoring effort. > > Refactoring the code so that its easier to understand and modify will be > crucial if we are to have a platform that is conducive to encompassing > new features and capabilities. The refactoring effort would also > include a re-organization of the source code tree. This provides a > means of splitting the code into distinct MVC sections and have source > files organized within separate subdirectories. > > > Thanks For Reading This Far !!! > > That's all I've got for right now. I hope some find this interesting > and I look forward to possibly helping out w/ Kdenlive. If anybody has > access to an Oracle DB (you can download and install one for free for > evaluation/development purposes) I'll set you up w/ my Multimedia > framework. It's all of *1.5Mb* in size (I rounded up). > > If you need help setting up an Oracle DB, I can help w/ that too. It's > easier than it looks.... > > Sincerely.....Steve Guilford...>>> > > -- > Steve Guilford > http://www.dbplugins.com > > > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > > > > _______________________________________________ > Kdenlive-devel mailing list > Kdenlive-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel >
