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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel > ------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
