Re: [CinCVS] a bug fixed
Pierre Marc Dumuid wrote: Oops! That was supposed to be replied to a personal email address. Please .. non-devel's and non-tester's don't use the git unless you are planning on bug-reporting / testing... and contact Christian (cehteh on IRC) or myself if you plan to do so. exactly ;) The machine that is hosting the git is on a bandwidth limited machine, and we don't want everyone using up all his bandwidth!ject Now since it is public (well, wasn't really secret), maybe someone has a machine with more bandwidth/volume (mine is 10GB/month on DSL, just a static IP) and would like to dontate some resources to the cinlelerra project. I can assist in setting up a mirror where noone else needs an account (thus quite a safe setup) and just plain HTTP needs to be served. Git is actually freedom in the way sourcecode can be shared and I can not/don't want to make just another centralized node here. My idea was only about providing mirror space for people without persistent internet connections. This is still somewhat experimental since I have no clue how much people out there will use it, lets see in 1-2 weeks how it turns out. Anyways, if someone is still interested in using git, join the git-mob on irc.freenode.net and ask about more infos. For anyone else, use the SVN. The git trees are developer branches and are merged back to svn when something becomes useable/stable. SVN is still the authorative development tree. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra documentation
Alex Ferrer wrote: Merge with ? By default I am open to any other format or anything that helps... so whatever it is I am for it. On a side note, what I am taking from this thread is: A) The wiki is slow - Agree.. I will try to cajole the guys at taxnetusa.com to see if they can move us to a faster server .. (I am getting the bandwith for free.. so I will see what some begging can do ) 2) Having to be online to browse the wiki is a problematic. Again agree.. I will see if the export to HTML plugin can solve that one.. It would be great to ship the documentation with the source. 3) The wiki is broken into too many pages and is hard to navigate. Am I reading this right ? if so, anyone can create a single wiki page that refers to as many pages as you wish in a single page. basically it would be a gigenormous page that should look a lot like Secrets of Cinelerra, + pictures Just generating a static version from the wiki often doesnt suffice, a wiki is at best structured for browsing, often rather unstructured (ok the cinelerra wiki get this right) I showed how to solve this on my wiki with a few simple steps: - Create a 'hardcopy' page which includes other (less structured) wiki pages in a well intended manner. - use the wiki's print-view and htmltops (or some similar tool) to generate a static version which is useable for printing. so how does that look like in real (just a example, not complecte content): The 'hardcopy' page in raw syntax: http://www.pipapo.org/pipawiki/Cinelerra/Print?action=raw Print-View: http://www.pipapo.org/pipawiki/Cinelerra/Print?action=print and a example PDF generated from that could look like: http://www.pipapo.org/pipawiki/Cinelerra/Developers?action=AttachFiledo=gettarget=text.pdf there are still some problems, and I use a moin-wiki not a twiki, but twiki has similar features and the bugs left, formatting glitches can easily be fixed by some sed-script hooked into the process. Idea behind would be to generate the static version occationally and check that into the source tree. The scripts doing this should be part of the distribution too. (a static html version with wget or a mirror tool is also easy) I think that if I get the server to be faster, it will solve a lot of issues. the main one being to attract more people to contribute material to the wiki. I agree and using a wiki is the simpliest way to attract people. If we agree on a workflow like I sketched above, it would be nice to feed 'Secrets of Cinelerra' into the wiki. Christian (2nd try, first post stuck in a moderator approval) ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] merge editing modes
Andraž Tori wrote: a patch that completely merges both editing modes of cinelerra into a single one, with shift key being the modifier ... editing modes are one of the hardest things for new learners of cinelerra to comprehend (by my experience) and there is really no reason not to merge them, since most of people expect to use shift for selecting. Compromise: Keep both editing modes as current but add the shift-key to toggle into the alternate mode. Then people can work like before AND the new single edit-mode work and anyone is happy. Christian (2nd try, first post stuck in a moderator approval) ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] AUTHORS file in svn
my svn-git sync broke recently because of a unknown author (welcome rafael2k :P), no big problen and easy to fix but anyways: How about maintaining the AUTHORS files instead leaving it empty? currently I have http://www.pipapo.org/.cinelerra-svn_sync/authors I would just suggest to check that into the svn as AUTHORS. Then I can remove the lowercase version and whenever a new auhtor appears someone (maybe me, in the git tree, since I will notice when it breaks) would care about new commiters. May someone with svn access do this? then i'll update my script. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] AUTHORS file in svn
Pierre Marc Dumuid wrote: Hi Christian, We could make a file called, SVN-COMMITTERS. Though you need to fetch the file before you run git-svn ... I don't think there is a need for just another kind of AUTHORS file. specially when then primary one isn't maintained. Also, I seem to be the quickest to note that the sync isn't working, so if you make the author file on pipapo cinelerra-group writable, and give access to the output logs, then I could fix it as soon as I see a problem also... i'd chgrped the cinelerra-svn_sync/ stuff to 'cinelerra' and set write perms. So anyone who is in group cinelerra can alter the authors file. Take care. Note 1: Just fixing the file isn't enough to make the sync work again, git stucks somewhere in nowhere and one has to reset the HEAD and restart the sync. Best solution would be of course to fix the authors file before someone new commits and the sync stalls. Anyways this problem occurs rarely and is not that critical (how often are new committers added?) I'll just plan to fix it when it strikes. Note 2: The authors file is not managed under svn or git, I just put it into the tree by coincidence. Maybe we could put it somewhere else. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] http://www.pipapo.org/.cinelerra-svn_sync/authors
Heroine Virtual Ltd. wrote: Johannes Sixt [EMAIL PROTECTED] minmax=Andraz Tori [EMAIL PROTECTED] herman=Herman Robak [EMAIL PROTECTED] baver=Richard Baverstock [EMAIL PROTECTED] pere=Petter Reinholdtsen [EMAIL PROTECTED] tfheen=Tollef Fog Heen [EMAIL PROTECTED] andreask=Andreas Kielb [EMAIL PROTECTED] theraz=Tyler Geddes [EMAIL PROTECTED] dyce=Gergely Erdelyi [EMAIL PROTECTED] dreamlx=David Arendt [EMAIL PROTECTED] ga=Gustavo Iniguez [EMAIL PROTECTED] memenk=Michael Eric Menk [EMAIL PROTECTED] benjif=Benjamin Flaming [EMAIL PROTECTED] cobra=Kevin Brosius [EMAIL PROTECTED] taraba=Mark Taraba [EMAIL PROTECTED] nate=Nathan Kurz [EMAIL PROTECTED] mammique=Camille Harang [EMAIL PROTECTED] kbielefe=Karl Bielefeldt [EMAIL PROTECTED] alexf=Alex Ferrer [EMAIL PROTECTED] pmdumuid=Pierre Dumuid [EMAIL PROTECTED] giskard=Riccardo Setti [EMAIL PROTECTED] jstewart=Joe Stewart [EMAIL PROTECTED] doudou=Sylvain Joyeux [EMAIL PROTECTED] rafael2k=Rafael Diniz [EMAIL PROTECTED] Was that some kind of jab at Jack Crossfire/Heroine Virtual Ltd? Whether you agree with it or not, you should credit original authors if you copy their work. Sorry about that, I am absolutely agree with you that you deserve the most credit! This authors list is just used to map login-names from SVN to real authors names/emails and was set up only containing those. Maybe you read my earlier post (The Subject: [CinCVS] AUTHORS file in svn thread). I would happly include any name you suggest to me in that list (or as proprosed in that thread, make it a offical AUTHORS file). Please note that this lowercase 'authors' file is internal to the avn-git setup and in no way versioned, part of the distribution neither even in the revision control by itself. I even thinking about taking the internal checkout (the .cinelerra-svn_sync directory) out of the webserver, then only the git would be reachable. I apologize if I didn't explained the current purpose of the file clear enough. Please let me know if you have any further questions, in fact I think the CV developers would like to work more closely with you and hear about your opinions more often. Happy new Year Christian Note: please send me a list about whom you would like to have included in the authors file, I don't want to make another error by revealing the wrong emails or wrong names/pseudonyms ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] setup changes for git users on pipapo.org
I made some changes in the server setup, which should ease mamagement and allows anyone to setup repos on his own. For now it's all done in a way that it is compatible with the old setup, when something gets broken, notify me, that is a bug. I create a page on my wiki describing the new setup: http://www.pipapo.org/pipawiki/Cinelerra/ServerSetup Please use that when you create a new repository. Existing anonymous repository access which is available as cinlerella-USERNAME are now deprecated in favor of cinelerra/USERNAME. I'll fix the wiki pages explaining that, explain that in new documents and change your registered archives. Anyways the old names are still reachable, maybe I remove them sometime in future (in a few months or so) but nothing going to be broken soon. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Rendering farm
[EMAIL PROTECTED] wrote: Hi Rafael Yes I did. Let us say I have machine A, B, C, D A is where I have my files (150 Gb), B, C and D are the extra machines supposed to help on B, C and D I typed as root : # cinelerra -d, and got the prompt back Ok On A the machine I use $cinelerra or #cinelerra Still nothing :-( You nfs-mounted the working dirs everywhere? ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] cinelerra/svn git mirrored to repo.or.cz
I've just mirrored the cinelerra/svn repo to repo.or.cz (pull mode). For all Developers who mirror their repo on pipapo.org, I suggest to register their repository as 'fork' there too. To do this, just go to http://repo.or.cz/m/regproj.cgi?name=cinelerra_cv/ and fill out the form. If you don't have the time to deal with it you can reply me this mail with a password, then i'll set that up for you. I just didn't want to do it without your commitment. Greetings Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] fixing cinelerra, using standard C++ libs etc.
Finally I found some time to look at some cinelerra bugs. Cinelerra use quite some own things (which is natural since the cinelerra codebase predates the C++ standard). I believe the code complexity could be lowered by replacing some things with standard or defacto-standard libs rather fixing the problems in cinelerra's ad-hoc implementations. I give it a try and start using the C++ stdlib and few sane parts of boost. I'll just try the next few days to get something fixed and then we'll see how it turns out. But I would like to hear opinions from the other developers which parts of cinelerra should be improved this way. I am fully aware that this can lead to a big intrusive change. But making cinelerra easier to maintain and more stable is really worth the efforts imo. Some short list where I am working on: Remove the Garbage collector in favor of boost::shared_ptr, the GC has some nasty bugs, partially together with threads. By replacing ALL Asset* with boost::shared_ptrAsset these should be fixed on expanse of some performance. Manage Assets in std::vectorboost::shared_ptr / std::listboost::shared_ptr. When this works then refactor some uses of the shared_ptr to using references instead, this will regain most of the performance loss from above. When still not fscked up, then refactor the arrays/lists to hold normal pointers (or boost::ptr_vector/ptr_list) with clear ownership semantic. Maybe add some debugging allocator which tracks per-thread ownership of objects, aiding in finding complicated bugs. Maybe apply the above steps to other classes (File, EDL, etc...). Maybe add some pooled allocator which could improve performance even more. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] fixing cinelerra, using standard C++ libs etc.
[EMAIL PROTECTED] wrote: Am Mittwoch, den 07.03.2007, 10:20 +0100 schrieb Christian Thaeter: Finally I found some time to look at some cinelerra bugs. Cinelerra use quite some own things.. I believe the code complexity could be lowered by replacing some things with standard or defacto-standard libs rather fixing the problems ... Hello Christian, I am much in favour of the cleanups you propose, indeed, many aspects of cinelerra source are hard to work with... but, as I see it, the main problem is: will such changes be accepted upstream?? Who knows :). Maybe Adam likes it and I hope when I/we get this good it has some chance to be accepted by him. Anyways this is Free Software and I use my free rights to fit it to my needs. This is still a personal experiment (first results later, looks promising so far). If not, we will end up with a de-facto code fork. (I state this without intending any pun or hostility). /If/ we wanted a completely forked Community-Cinelerra, we would need much more dev manpower CinlerraCV is already a de-facto fork, with friendly relations to upstream and kept to be somewhat mergeable (which is a hell of work). I try to keep my branch mergeable with CinelerraCV (Which is much easier to merge for sure). Future will tell how this works. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] fixing cinelerra, using standard C++ libs etc.
Nathan Ryan wrote: Hey all, First off, apologies if I am replying to this incorrectly - I usually read mailing lists, rarely post. I thought Hermann's comment about dev manpower was worth me coming out of my shell. I work as tech support at a film department in an University of fine art. I have been expounding the virtues of using an open source model in an educational and artistic setting for a few years now. It seems that ears are beginning to perk up. One main point of interest has become the Cinelerra project. We recognize Cinelerra as an amazingly powerful tool, but one which is not particularly usable for us as an institution in its present form. We have begun to piece together a two pronged approach for our film department with regards to open source software development - partnership with another local University and their computer sciences dept, and pursuing research grants. We have talked about some specific film related programs which currently don't exist, at least in the open source realm. We are also talking about Cinelerra. Here is where the community can really help out - and hopefully we can really help you guys too. I'm not a programmer by any stretch of the imagination, but I do have some idea of how big a project Cinelerra is. We've outlined a http://www.dwheeler.com/sloccount/ Totals grouped by language (dominant language first): ansic: 310217 (53.96%) cpp: 247874 (43.12%) sh: 10580 (1.84%) asm: 5936 (1.03%) perl: 258 (0.04%) sed: 16 (0.00%) Total Physical Source Lines of Code (SLOC)= 574,881 Development Effort Estimate, Person-Years (Person-Months) = 157.97 (1,895.69) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 3.67 (44.00) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 43.08 Total Estimated Cost to Develop = $ 21,340,200 (average salary = $56,286/year, overhead = 2.40). YMMV about this results ;) few things which we feel need to be fixed up before we can be serious about using Cinelerra as a core part of our program - reliability and ease of installation and use being two areas. Currently it seems there are functions which are not working properly - firewire import for one. I proposed some time ago to throw the FW import away and instead make a dvgrab frontend at that place. Thats probably the best and simplest way to fix it. Maybe without live preview. Installation is also somewhat convoluted (though projects like Ubuntu Studio might help alleviate that problem). One large feature which is missing (or so it seems) for us is support for DVCPro HD in MXF wrappers (from the HVX200 camera). Any thoughts or advice you as the developer community can pass on would be great. In particular I would like to know more about how we could work with you guys to create the best possible software. Also, in the case of the grants (if and when) - are there any cinelerra/linux developers out there who would consider working with us on contract? I do, but I am quite new on board. I'd step back for anyone else who want's this job. How about HV? I will remind everyone out there in cinelerraland that this is still in the very early stages of planning, but the idea does have the support of admin here at the school, so it is something that isn't just a pipe dream. Please email me directly with ideas and suggestions, be it with the program itself, or with regards to how we as an institution with specific goals (which conceivably could differ from the CV project) do not can work positively with the community. To sum up our basic goals for the project: 1. Have a feature rich, professional quality HD video editor which is usable as a teaching tool. Mission already completed. 2. Stable codebase Neverending work, but under way. 3. Streamlined work flow. Cinelerra could be used in diffrent ways/workflows, some could be improved for sure but I'd rather dont want't to miss any existing ones. 4. Must not require a degree in computer science to install and set up to use. apt-get install cinelerra 5. Develop codecs to support our file type of choice - DVCPro HD in MXF wrapper. (Red camera may expand this requirement.) Sounds like much work. 6. Maintain GPL status of project, and provide community with all research and development progress. GPL can't be taken back Cheers Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] fixing cinelerra, using standard C++ libs etc.
Christian Thaeter wrote: you might pull it with git git clone git://git.pipapo.org/git/cinelerra/ct correction: git clone git://git.pipapo.org/cinelerra/ct or git clone git://repo.or.cz/cinelerra_cv/ct.git not yet ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] fixing cinelerra, using standard C++ libs etc.
Johannes Sixt wrote: On Wednesday 07 March 2007 19:25, Christian Thaeter wrote: Remove the Garbage collector in favor of boost::shared_ptr, the GC has some nasty bugs, partially together with threads. By replacing ALL Asset* with boost::shared_ptrAsset these should be fixed on expanse of some performance. Is boost::shared_ptr thread safe? If not, this replacement does not fix anything, in particular not the thread related bugs. http://www.boost.org/libs/smart_ptr/shared_ptr.htm#ThreadSafety so its not fully, but it employs the locking which already exists. The only problem could be when the internal use-count drops to zero and the thread prepares to delete a object, if then a context switch occurs and another thread increments the use count to 1 we have a problem. But this case is avoided because ALL pointers are shared pointers now. This costs little performance but guards against that case. I have Cinelerra running under valgrind for hours here now, loading some hundred assets and valgrind didnt report a single error with asset handling, thats at least far better than before :). Even if there is some corner case left where thread safety play against us, it's now possible to replace the shared_ptr easily with something else. But as long I don't observe such glitches I concentrate on improving a debugging frameworks which aids in finding race conditions, deadlocks and unspecified ownership of objects. The shared_ptr transistion is only a prelimary step, somewhat better than a bandaid to fix some bugs, later to be optimized mostly out again. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] fixing cinelerra, using standard C++ libs etc.
Johannes Sixt wrote: On Wednesday 07 March 2007 22:46, you wrote: Replacing Asset* in parameter lists by Asset is certainly not worth it. You gain absolutely nothing, but only introduce a lot of unnecessary code changes. Please don't do that. replaced Asset* with Asset_GC which is boost::shared_ptr, any yes that are a lot of nessary code changes. Some of them can be reverted back to Asset for performance reasons, that is if the callee will only read them and not copy them, then passing references is sane, they could be reverted to Asset* to but since they already got modified once, i'd now prefer the transistion to more sane references. With all these modifications do not forget, that we intend to merge from upstream again. Therefore, avoid those code changes at all costs that do not change (= improve) the behavior. Consequently, *I* will not include the modifications you currently have in your git in the SVN, because they make upstream merges more difficult than necessary. Agreed, I didn't intended all my changes to be merged to the SVN main trunk. Instead have to maintain my branch from now on. Unless HV merges my changes, it will become difficult to merged into SVN. I'll try to merge SVN regulary into my tree. I stated, that this is just my personal experiment (in the same spirit like HV works on cinelerra for his own purpose). I would really like if some developers from CinelerraCV bless it as CinelerraCV_improved and maybe create a branch in SVN (or just use git for collaboration), but thats out of my control. The changes are of a kind that you will have to lobby at HV directly. And then you need a *very* good reason that they are an improvement. References are more sane will not be enough. My repository it open and I like comments on it, nevertheless I'll hack freely on what I want to have there. I can only invite others to review it and maybe cherrypick from it. Decide yourself, I don't intend to make a Lobbying campain. If HV wants to collaborate more (opening his repository publically or to some developers) I would really welcome it, he deserves my greatest respect, Cinelerra is a incresible piece of software, but he decided to do the releases as he does now and we have to take that. There is nothing I can and want to do currently to improve merging with HV. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] DVpro
Andraž Tori wrote: On Fri, 2007-03-09 at 09:39 +1300, Edouard Chalaron wrote: Hi all Simple question : is DV50 supported under Cinelerra ? Thanks a lot simple answer: no yesterday we talked about Google SoC 2007 projects, DV50 made it into the proprosals, there is some hope. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] cinelerra gpl license header for review, sketch how to solve the license issues
Sorry, the topic gets boring but I added a license header to a C++
sourcefile (cinelerra/cache.C) I edited which reads:
/*
Copyright (C) Heroine Virtual Ltd.
1996-2006, Jack Crossfire [EMAIL PROTECTED]
Copyright (C) CinelerraCV
2007, Christian Thaeter [EMAIL PROTECTED]
et al.
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of the
License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
This file is actually mostly rewritten by me so the 'et al.' is only a
safety measure, but for other files I don't want to figure who else
touched them manually.
I'll go on to add such to all files where I apply non-tivial edits, any
objections?
If anyone feels left out in some file, please notify me, I'll add you.
For future I would suggest the following (already sketched that on irc):
Write a smart script which can deduce licenses by:
- checking the type of file, we only handle text files,
binary files need exception rules
- grepping for copyright/license information in the file
- checking if the directory where the file is has a license file
- check against a manually maintained exception list
if the script can NOT safely figure out the license (ex: detected a
copyright note but no license, ...) then it should notify the user for
human inspection for adding it to the exception list after manual review.
if the script can safely figure out under which license a file falls
then use the SVN history to figure out who edited it when and in which
revision.
We need a list associating revisions with people for exceptional cases,
it could take file patterns(or regex) like this example:
# for all revisions all fonts belong to 'ms'
*: *.ttf:ms
# *:hv denotes a upstream merge,
# foo/bar.C:j6t was also edited by Johannes etc.
r1234: *:hv foo/bar.C:j6t ...
next we need an association of user and the license they usually use
ms FONTSEULA
hv GPL
j6t GPL
maybe also a syntax for exceptional licenses foo/barf.C:j6t!BSD
if the script detects a collision it should notify this for fixing in
the exclusion list.
having all this information (date/person) we can automatically construct
a copyright header including year('s) and person.
This is only a sketch, such a script should have some more logic and
should be applied in a 'dry-run' while developed. At least I think this
approach is much easier than manually reviewing the history of 5000+
files. Further the development and history of this script and its
exception list will be tracked in revision control this gives some open
and reviewable process and I also believe this way is far less prone of
human errors which will happen on a manual review.
Finally we should put a big DISCLAIMER into the sourcetree which
explains this process and note that anyone who spots a problem shall
notify us and it will be fixed.
So, now the bad news: When someone else starts it, I will help to work
out the details. But I will not code it! I will not participate in a
discussion if we could/should do it this way, just do it or leave it.
Christian
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] cinelerra gpl license header for review, sketch how to solve the license issues
Nicolas Maufrais wrote: Hello Christian, On Sat, Mar 10, 2007 at 12:44:56AM +0100, Christian Thaeter wrote: This file is actually mostly rewritten by me so the 'et al.' is only a safety measure, but for other files I don't want to figure who else touched them manually. Is the 'et al' legal? Couldn't it be, how could I say, dangerous? I mean, it's safer to get an exhaustive name of the people who worked on the file. That's the way it should be done IMO. However, I understand you're not sure about who wrote that file apart you... I am not lawyer while I suspect that the legality of such a clause depends on the legislation which is applied. But even if it is not valid it should only invalidate the 'et al.' clause and not the whole license notice. For the worst case, when it invalidates the whole license notice, then at least here in germany that means that the license is void, but copyrights are still at the authors, it will not fall into Public Domain or such. A potential user has to contact the Authors for legal licesnse terms. In the other case I am adding a copyright notice to code which is not completely written by me, this means if a original author gets upset because I forgotten to add him, he could probably sue me an claim that I stole his copyrighted material. With adding a 'et al.' (and this archived mailinglist thread) I could hopefully convince a judge that my intention was not to steal code. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] where's the manual?
Mark Grieveson wrote: RTFM, I tell myself. Yet, when I view the man page, or check out /usr/share/doc/cinelerra, I find them both sadly lacking. So, where's the manual? I'm having real problems with this program. Mark ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra http://cvs.cinelerra.org/docs.php ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Launch error
Franz wrote: Recently installed Cinelerra on Ubuntu edgy launches OK, but always displays this notice first: echo 0x7fff /proc/sys/kernel/shmmax I don't know what it means, but can I avoid having to do this everytime I launch cinerella ?+ Franz When you have the procfs tools installed then you can add it to /etc/sysctl.conf: $ tail -1 /etc/sysctl.conf kernel.shmmax=0x7fff ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Build System enhancement (any helpers?)
I started to transform the recursive ('SUBDIRS') Makefile.am builds into
'include' statements (see 'info automake' chapter 7.3). The idea behind
this is to make rebuilds much faster and more sane and utilize a distcc
cluster much better. The rationale about is, that a distcc build here
will waste about 50% of its time in doing serialized subdir builds in
the plugin folder and even minimal changes at the code will cause a time
consuming full subdirs traversal.
You can view get the code from my 'automake_nosubdir' branch:
http://www.pipapo.org/gitweb?p=cinelerra/ct;a=shortlog;h=automake_nonsubdir
This is still work on progress I want to announce it early, maybe
someone wants to help me with that.
Some Notes:
* the work is done on top of my 'cinelerra/ct' branch but I plan to
backport it to the SVN version when the other Developers agree. I think
this is moderate intrusive since it is more a mechanic transformation
than much coding effort (well still some work) and it won't introduce
incompatibilities/merge problems with upstream sice we use our own build
system anyway. The benefits should outweigth the little disribution in
merging this.
* some manual (clean-something:) make targets are commented out, should
be fixed soemhow
* I only did *works-for-me* efforts so far, that is:
+ buildinfo will be unconditionally recreated
+ works only --with-external-ffmpeg (I didnt decided yet if to keep
SUBDIRS for ffmpeg or also to turn it into a include)
When someone wants to fix this issues, just go on and send me patches
they are of lower priority to me I would only work at last on them when
I am back (see below).
* It generates one big fat Makefile (which is good in this case, only
one make instance which will have a broad insight over the whole project)
* It builds all objects in $(top_builddir) if you don't do of-dir
builds then this might look strange, but should be no problem. When
anyone finds out how to build objects in subdirs beyond $(top_builddir)
I would be glad to integrate his patches (while I think this is not needed)
Whats left to do:
I just started to transform the themes and plugins will be next; guicast
isn't yet done. The guicast transformation is simple if someone want to
do it, just drop me a note. I will work the next days on the plugins
dir. If someone wants to (promise to) help in the plugins dir please
tell me ASAP then we can coodinate work (like I do all plungins starting
with letter 'a' or such).
There is a small synconization problem since I will be out of office for
about 1-2 weeks from saturday on, I don't know if I will be able to
connect to the internet, but I take my laptop with me an work little bit
on the code when time permits. I'll be reachable via email or on IRC
until tomorrow (friday) late evening (GMT). When you want to help on
this, either use git to keep your changes or just send me patches, but
please keep them back until I am back from my travel, else the chances
that I oversee some emails are high. Alternatively you can add
information about your patches on my wiki
(http://www.pipapo.org/pipawiki/Cinelerra/GitBranches) this will be
persistent and not be lost.
Christian
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra crash at startup
Martin Ellison wrote: /usr/local/bin/cinelerra Cinelerra 2.1CV SVN 1006M (C) 2006 Heroine Virtual Ltd. Internal ffmpeg Compiled on Sun Mar 11 22:31:51 HKT 2007 Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra. PluginServer::open_plugin: /usr/local/lib/cinelerra/1080to480.so: undefined symbol: _ZN8DefaultsC1EPc PluginServer::open_plugin: /usr/local/lib/cinelerra/chromakey_hsv.so: undefined symbol: _ZN8DefaultsC1EPc PluginServer::open_plugin: /usr/local/lib/cinelerra/linearize.so: undefined symbol: _ZN8DefaultsC1EPc PluginServer::open_plugin: /usr/local/lib/cinelerra/seltempavg.so: undefined symbol: _ZN8DefaultsC1EPc *** glibc detected *** /usr/local/bin/cinelerra: free(): invalid pointer: 0x01d3a4d0 *** === Backtrace: = /lib64/libc.so.6[0x3ec146ea30] /lib64/libc.so.6(cfree+0x8c)[0x3ec147214c] /usr/local/bin/cinelerra(_ZN9IndexFile9read_infoEP5Asset+0xe2)[0x5a79b2] /usr/local/bin/cinelerra(_ZN9IndexFile9open_fileEv+0x9a)[0x5a83aa] /usr/local/bin/cinelerra(_ZN9IndexFile10open_indexEP5Asset+0x31)[0x5a8521] /usr/local/bin/cinelerra(_ZN11MainIndexes14add_next_assetEP4FileP5Asset+0x57)[0x5b6ba7] /usr/local/bin/cinelerra(_ZN7MWindow10paste_edlsEP9ArrayListIP3EDLEiP5Trackdiii+0x349)[0x5dca79] /usr/local/bin/cinelerra(_ZN7MWindow14load_filenamesEP9ArrayListIPcEiiS1_ii+0x9ca)[0x5d785a] /usr/local/bin/cinelerra(_ZN12LoadPrevious12handle_eventEv+0xac)[0x5b1b0c] /usr/local/lib/libguicast.so.1(_ZN11BC_MenuItem23dispatch_button_releaseERi+0xf4)[0x2b276ff4] /usr/local/lib/libguicast.so.1(_ZN12BC_MenuPopup23dispatch_button_releaseEv+0x59)[0x2b277f39] /usr/local/lib/libguicast.so.1(_ZN10BC_MenuBar20button_release_eventEv+0x4a)[0x2b2760ba] /usr/local/lib/libguicast.so.1(_ZN13BC_WindowBase23dispatch_button_releaseEv+0xab)[0x2b297a1b] /usr/local/lib/libguicast.so.1(_ZN13BC_WindowBase14dispatch_eventEv+0x496)[0x2b29c106] /usr/local/lib/libguicast.so.1(_ZN13BC_WindowBase10run_windowEv+0x68)[0x2b29c6c8] /usr/local/lib/libguicast.so.1(_ZN6Thread10entrypointEPv+0x36)[0x2b2ac306] /lib64/libpthread.so.0[0x3ec2406305] /lib64/libc.so.6(clone+0x6d)[0x3ec14cd50d] looks like you overinstalled a new build over a old installation which was done with a different compiler or different flags. Uninstall it, make sure you really remove anything and then do a fresh rebuild install. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] my cinelerra involvement
Andraž Tori wrote: Lately i had almost no time to hack on cinelerra and it doesn't seem that situation will improve in forseeable future. Therefore, I'd like to point out that cinelerra is in need of new manpower to keep it in good condition. Currently there are at least a few grave bugs that have to be fixed, but are quite hard to track down (freezing when moving edits when having multiple tracks being one of them) I'm back from vacation, working on my cinelerra branch now. Currently I rather care more for infrastructure enhancements and cleanup than outstanding bugfixes but I believe that this will pave the road to find/fix bugs much easier in future (at least for me). I believe we can be a bit more liberal with svn access, since we really have a big problem at hand... I think so far the git way worked well, looking at the repositories which are mirrored here, there are people actively working on cinelerra on their git branches. For me hosting git mirrors from pipapo.org turned out to be less problematic than I expected (bandwidth/traffic/support wise). Imo it would be nice to bless the git repos more official, maybe even phase out SVN and turn over to git entirely. This gives much more freedom in workflow since anyone can hack in his own branches. We could pick up Linux kernel like policies and add 'Signed-off' comments to reviewed commits etc. Some ideas/notes: - Would it be possible to run a git mirror service on cvs.cinelerra.org? - Anyone else having a server which can offer git mirroring? - There is repo.or.cz which offers free mirroring too. - a anonymous (untrusted) pushable git repo on pipapo.org (how about such on cinelerra.org?) - I would offer some help when setting up git things on cinelerra.org - How about a monthly developer meeting on IRC, 1 hour where we can discuss who works on what, where progress is made, who needs help with something and so on. Exact timedate acknowledged on the mailinglist, Someone makes a protocol about the outcome and puts it online and so on? - when will then entire cinelerra.org site be a wiki? :) Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Build System enhancements finished
The build system enhancements I proprosed some time ago is finished now. Here are some pragmatic (quite unrepresentative/inaccurate, due cpufreq and loaded machines) benchmarks: Setup: I disable ccache for all of this benchmarks, distcc is used as noted. The compiler commandlines still always use the 'ccache distcc' prefix. The tests are run on my laptop (slow encrypted disk) and all other hosts are connected via WLan. CC=ccache distcc g++-4.1 CXX=ccache distcc g++-4.1 CCACHE_DISABLE=true $ rm * -rf $ ../configure --program-suffix=_flatam --with-external-ffmpeg 1. old build system using SUBDIRS 1.1. using distcc over all machines here DISTCC_HOSTS=10.20.20.20/2,lzo 10.20.60.10/3,lzo 10.20.10.40/1,lzo \ 10.20.50.10/2,lzo Note: my laptop is already loaded with preprocessing and feeding the cluster, there is no compilation on localhost. 1.1.1 full rebuild $ time make -j 9 ... real6m12.913s user1m40.237s sys 0m32.071s 1.1.2. rebuild with few files in cinelerra touched $ touch ../cinelerra/cache.* $ time make -j 9 ... real1m11.398s user0m29.755s sys 0m6.763s 1.1.3. rebuild with a plugin touched $ touch ../plugins/blur/blur.* $ time make -j 9 ... real0m8.623s user0m5.966s sys 0m0.553s 1.2. build sequential no distcc hosts DISTCC_HOSTS=localhost/1 1.2.1 full rebuild $ time make real9m11.694s user7m33.710s sys 0m38.491s 1.2.2. rebuild with few files in cinelerra touched $ touch ../cinelerra/cache.* $ time make ... real3m7.865s user2m39.326s sys 0m9.649s 1.2.3. rebuild with a plugin touched $ touch ../plugins/blur/blur.* $ time make ... real0m9.239s user0m7.829s sys 0m0.587s 2. the new build system using included makefiles 2.1. using distcc over all machines here 2.1.1 full rebuild $ time make -j 9 real3m13.020s user1m38.214s sys 0m31.068s 2.1.2. rebuild with few files in cinelerra touched $ touch ../cinelerra/cache.* $ time make -j 9 ... real1m9.546s user0m30.031s sys 0m6.270s 2.1.3. rebuild with a plugin touched $ touch ../plugins/blur/blur.* $ time make -j 9 ... real0m8.748s user0m6.326s sys 0m0.317s 2.2. build sequential no distcc hosts DISTCC_HOSTS=localhost/1 2.2.1 full rebuild $ time make real9m3.112s user7m39.167s sys 0m37.714s 2.2.2. rebuild with few files in cinelerra touched $ touch ../cinelerra/cache.* $ time make ... real3m10.850s user2m44.649s sys 0m9.513s 2.2.3. rebuild with a plugin touched $ touch ../plugins/blur/blur.* $ time make ... real0m9.255s user0m8.629s sys 0m0.323s Conclusions: * parallel builds are double as fast (mostly because plugins build parallel now) * rebuilds are not that improved like I hoped (maybe I touched the wrong files) :( * building on single processor is not improved (that wasn't expected anyway) * distcc rocks, but doesn't scale that well maybe perhaps of my wlan or due the slow HD in my laptop. * enableing ccache would give another speed boost but isn't useful for this comparsions. * Not measured here, but configure is faster since far less Makefiles are generated. * So far this is just a minimal translation, there is still room for improvement. Whats next: Some of the issues I mentioned earlier are not yet fixed * I only did *works-for-me* efforts so far, that is: + buildinfo will be unconditionally recreated + works only --with-external-ffmpeg (I didnt decided yet if to keep SUBDIRS for ffmpeg or also to turn it into a include) + some (clean..:) targets are commented out All or some of this work could be merged back into the SVN. There are some fixes and changes to the sources too (garbled dependencies, path fixes, libaffine factored out, ...), please review it! I'll prepare a patch including what we want in SVN on request when we concluded what shall go in there. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] theme S.U.V. not found
Graham Evans wrote: Martin Ellison wrote: Maybe it's your path. It seems that it is looking in the wrong place. It seems all these problems have come up before but I can't find the solutions. Apparently the themes aren't building properly because of the static linking options I've used in my configure line. But I can't get a successful build without those options... Static and dynamic linking is beyond my knowledge at present so my remaining options are: sacrifice open gl and try out the http://giss.tv/~vale deb packages, perhaps try and compile with an old external ffmpeg (mid 2006 cvs is not early enough and earlier than that is likely to mess with my other sid programs), or open up my fedora core 4 64 partition which runs latest cinelerra CV no probs... Please tell why you can't do dynamic builds. Themes and plugins are loaded dynamically as modules, they really need dynamic builds. Changing this would be not trivial (using libltdl for the module loader for example). I suggest to fix dynamic builds rather than trying static builds. Once I had the same error, but it turned out that set GLOBAL_PLUGIN_DIR wrong (from a former test). Running cinelerra under strace control will reveal such cases (what files/paths it searches and which ones fail). Thanks for the suggestions anyway... if anyone thinks of anything else I'd be glad to hear from them. Graham E. On 25/04/07, *Graham Evans* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I run a fresh cinelerra install (had some problems building - see thread '[CinCVS] build failure svn 1008'). There is currently no ~/.bcast directory and I get a crash after a brief flash of life: MWindow::init_theme: theme S.U.V. not found. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] [Fwd: Cinelerra Wont Start]
Herman Robak wrote: This came to the wrong address... Hi, I just installed cinelerra on ubuntu 7.04 feisty. When I try and run cinelerra, a small window opens and then closes real quick. When I try and run it from the terminal I get this: Cinelerra 2.1CV (C) 2006 Heroine Virtual Ltd. Compiled on Sun Apr 15 00:09:28 UTC 2007 Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra. Illegal instruction (core dumped) How do I fix this? Please help. Some more people reported this problem, I suspect that the feisty package is accidentally build with the wrong processor optimization flags, pleases verify that or run cinelerra under gdb or valgrind (or perhaps strace) and provide details. Maybe get the source package verify the build instructions (flags/rules) and debuild it by yourself. Please state more details, which arch was the pakcage build for, which is your computers arch (intel? amd? 64bit?...) Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] General Cinelerra performance
Ichthyostega wrote: Dennis Schulmeister schrieb: Another problem is the hand-written GUI toolkit (libguicast), which just doesn't perform as smoothly and fast as -- say gtk or qt or even java/swing. I already wondered which toolkit is used. I don't like java/swing that much because it's absolutely not my taste. But I fell absolutely in love with GTK. libguicast originates from the time when other toolkits wheren't available/fast enough (around 1996). I profiled certain things and its true that in some respects things could be optimized and I'll working on that. But generally guicast is a layer above the xlibs which doesnt perform that bad. In far future (maybe 1-2 years) I might like to transist cinelerra to GTK+. This would be a *very* big task and I certainly won't do this alone. When it is time we can bring up this topic again and negotiate with HV about such a change. But for now there are IMO really more important things to do (stabilization, std libs, some design refactoring). There are some good reasons that the CV version follows HV closely and don't want to loose mergability with it. To loosen this requirement I started my branch where a I am already done some mildly intrusive changes and working on it without too much care for HV mergability (while I would like to keep it somewhat mergeable with the CV version). I would really like if people who are serioulsy interested in contributing new features to cinelerra join my efforts and help me on my branch. As far as possible i'll try to bring fixes and good things back into mainline CV (which won't always be possible). There is a Wiki Page where I describe the things which I am working on: http://www.pipapo.org/pipawiki/Cinelerra/Developers/ct/CinelerraEnhanced Christian (I'll be 4 days out of office until wednesday, don't expect responses) ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [Fwd: Re: [CinCVS] info cinelerra]
Herman Robak wrote: bérengère, would you mind posting to the mailing list, where there are probably more people who might know? I'm forwarding this to the list. Subject: Re: [CinCVS] info cinelerra From: beewoo [EMAIL PROTECTED] Date: Mon, 07 May 2007 15:24:56 -0400 To: Herman Robak [EMAIL PROTECTED] To: Herman Robak [EMAIL PROTECTED] On 7-May-07, at 3:00 PM, Herman Robak wrote: the support for GL-accelerated effects is not likely to work with an ATI card. Thanks for your answer! would it work with the NVIDIA 7300 GT graphics processor with 128MB of GDDR3 SDRAM? works even with a cheap 02:00.0 VGA compatible controller: nVidia Corporation GeForce 7300 GS (rev a1) here (maybe not too well). You need decent propietary nv drivers unfortunally :( The Key point is rather hardware supported Open GL 2.0 shaders rather than much memory or High Performance cards (which wont be bad anyways) ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] New theme ...and perhaps... new effects icons
Bodmer Stephan wrote:
[EMAIL PROTECTED] wrote
And remember that I want to make themes, but nees people to help me
compilig...
Hi, I'm interested to help you create a new themes... and perhaps
for your first submission you could try to create some normalised
effects icons... humm, the default one are not so profesional ;^)
I'm a profesionnal Java developper (...ah, if only Cinelerra was writen
in that Language... humm, just kiding ;^) ) but I started with C/C++ a
long time ago (I remember with nostalgie when I coded some effects for
the beloved Movieshop NLE System on Amiga computers...).
I think I could manage to integrate your design.
If someone could explain me quickly how to do it. I read someting
about a bin2cinelerra application to transfom .png to .c headers...
But I didn't found this tool on the site ?
cinelerra builds it while compiling itself,
the tool is called 'bootstrap', look into the Makefile.am's in plugin/*/data
example:
suv.data: $(libsuvdata_a_PNGS) bootstrap
$(top_builddir)/bootstrap $@ $^ || { rm -f $@; exit 1; }
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] [Bug 421] New: About Dialog?
[EMAIL PROTECTED] wrote: http://bugs.cinelerra.org/show_bug.cgi?id=421 Summary: About Dialog? Product: Cinelerra Version: 2.1 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: Medium Component: User Interface AssignedTo: cinelerra@skolelinux.no ReportedBy: [EMAIL PROTECTED] Could there be a traditional About menu/dialog, that displays basic information about the program? It's ridiculous that you can't even find the version info for reporting a bug. Reproducible: Always The Preferences Window has a about box (arguable location, but at least it is there) ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] cinlerra install
Douglas Pollard wrote: I have not been able to get cinelerra to install in ubuntu studios i386 with synaptic. click applications, sound video, shows an icon for it but it won't open. And it shows as installed in synaptic. In add/remove it does not show up as installed? Has anyone been able to install this way. doug The AMD package for feisty is known to be broken (aborts with Illegal Instruction), hopefully fixed soon. In the meantime you can install the generic (i686?) package or try to build cinelerra by yourself (needs a lot build dependencies) Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Upgrading wipe plugin
[EMAIL PROTECTED] wrote: I decided to enhance the wipe plugin to do vertical as well as horizonal wipes, and I've a few questions and issues about this code: - I really don't like the indenting style of the existing code. Do I have to follow it, or can I switch to something more readable for the parts I write? Favor use the existing style, when it comes to indenting, consistency is the most important thing imo, the cinelerra source indenting is already a mess but thats no reason to make it worse. (I would prefer another style too) - We have a class called BC_Radial for radio buttons. It's probably too late to change it, but that certainly doesn't help understandability of this code. Radio buttons are called that because they function like the station-selection buttons on some old radios; the word radial means extending in rays from a central point and has nothing to do with radio buttons. yes, too late - Is it safe to use memcpy? If not, is there a similar function I can use? safeness comes from the way how you use it (don't overrun buffers etc). Apart from that memcpy is ansi-C and pretty portable. Maybe you look at similar code within the plugins first and check how its done there, otherwise there is no much reason not to use memcpy (maybe we want to favor C++ std::copy?) Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] ANNOUNCE: anonymous pushable git repository for cinelerra
It happens sometimes that people send new patches/bufixes to this ML which eventually might get forgotten. To offer a chance that such things are picked easily up somewhere. I created a 'mob' repository on my server where anyone can push patches anonymously. Little HowTo: # first clone the repository # (use the --reference option when you already have any other # git clone of a cinelerra repo) git clone git://git.pipapo.org/cinelerra/mob my_cinelerra cd my_cinelerra # then create a branch for your work git checkout -b yourbranchname # work and commit ..hack..hack..hack git commit ... # send it to my server, maybe with some branch description, # see the git-push manpage git push --all IMPORTANT: Do not trust the code in this repository, anyone could add potentially dangerous code, review every foreign commit before run anything (autogen.sh, ./configure). I'd suggest to use gpg signed tags when you reviewd some state and trust it (man gpg-tag). Such tags then sign the state and all its history. Further I don't make any rules how this might be used, feel free to acknowledge with other people to make this repository useful. The only thing I will do is regulary or automatically rebasing the master branch on the ongoing SVN synced repository, I'll tag the tree before doing so, but any conflicts occuring during this rebase will be thrown out of the master branch (they are still reachable from the tag) but contributors would need to resolve conflicts and reapply them on the master branch again if they didn't worked in topic branches. If you have any questions about this, feel free to contact me via mail or on IRC. About mob software: http://www.dreamsongs.com/MobSoftware.html Have Fun Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] SVN Commit History
rafael2k wrote: hi all, I think the svn commit history stopped at r1005... bye! rafael diniz Alternative: http://www.pipapo.org/gitweb?p=cinelerra/svn;a=log ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] reference monitor
Kurt Georg Hooss wrote: o.k. i managed to configure the screen to be used as x terminal, following the instructions at http://en.wikibooks.org/wiki/NVidia/TV-OUT essentially, the tv can be used as a separate x terminal or as an extension of the desktop area (dual-head mode). in either case, the tv is then (part of) an x screen. (and btw. just greyscale, no colours.) the compositor window shows up there on the tv screen in resized resolution, smaller than the tv screen, so it would have all its borders and buttons, and the composition inside is actually shrinked to quite smaller than pal. there is a fullscreen mode .. press F in the compositor ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] reference monitor
Kurt Georg Hooss wrote: aha! thanks christian. today i could test only with another computer monitor in twinview mode (resolution set to 768x576) and that worked fine. so i guess it will probably do well with the tv also. next time i have the tv set here i'll try to find out whether two computer monitors *and* the tv set can be used all three together in a *three-screen mode*... I think cinelerra can only send the compositor to another screen, but you can link the other 2 screens as xinerama together .. or some people told me something even better: you can link framebuffers together and then feed one xserver with it as huge screen. I dont know details, i don't have 3 monitors. because, i have seen professionals working in a typical setup with two computer monitors for timeline, resources, clip viewer etc. plus reference tv monitor for viewing the composition output. cheers georg On Monday, 11. June 2007 13:15, Christian Thaeter wrote: Kurt Georg Hooss wrote: o.k. i managed to configure the screen to be used as x terminal, following the instructions at http://en.wikibooks.org/wiki/NVidia/TV-OUT essentially, the tv can be used as a separate x terminal or as an extension of the desktop area (dual-head mode). in either case, the tv is then (part of) an x screen. (and btw. just greyscale, no colours.) the compositor window shows up there on the tv screen in resized resolution, smaller than the tv screen, so it would have all its borders and buttons, and the composition inside is actually shrinked to quite smaller than pal. there is a fullscreen mode .. press F in the compositor ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] test
mailinglist broken? ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] testmail, ignore this
just set up greylisting and want to check if this mailinglist passes through ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] How to submit patch into CV
I just commited Vits patches into the mob repo, contrib branch. Unreviewed! j6t maybe you take a look in a bored moment and commit them to SVN then. Christian Vit Stradal wrote: Hi, I have made a few small patches, which seems to me useful. I want to share them and (get them into svn of course :) I didn't find some HOWTO-submit so I try it to send it here, but if there is some more official way please tell me. Patches can be found at: http://vitas.matfyz.cz/cin/ Short description: toggle-editmode.patch shorcut 'e' togles editmode (IBEAM, ARROW) ctr-wheel-horizontal-scroll.patch ctr-wheel scroll horizontal in timeline clipedit-select-title.patch when editing or creating clip, title is selected, so default title can be erased by single writing new title altN-windows.patch focus windows by shortcut: Alt-1 viewer, Alt-2 assets, Alt-3 clip window group.patch patchs can be grouped, ctr-click set edit|play|view... flag for all patchs in group (by one click) vitas @;; ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] software(s) to capture onscreen activity
[EMAIL PROTECTED] wrote: Hey folks, What software are people using to capture screen activity (ie, starting programs, opening windows, etc in Gnome)? I'm interested in integrating captures of web browser activity into a Cinelerra project and wondered what programs people found best to do this. My window environment is Gnome. scott ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra cinelerra can do that too ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Open Movie Editor
mark carter wrote: On Tue, 2007-08-07 at 20:02 -0500, Daniel Jircik wrote: I've been using cinelerra in a production environment for a few years now and really the only instability issues I've had were when doing something blatantly wrong or mis configured. Is there a format that the pros use that has good support. OGG files routinely create crashes, for example, and I made a recent submission to mob to alleviate at least some of the problems. I think cehteh preferred me to use a C++ solution, whereas I preferred a vanilla C way - so it's likely that the change may never see its way into Cinelerra :( I didn't meant that this way, for myself I am rather pro C (or using a real high level language). I'd rather meant fixes should be done in proper C++ way when the whole sourcefile is C++, for consistency and robustness. I really appreciate your contribution and I don't feel myself in a position to judge about inclusion or refusing such. I asked if you may rewrite it in C++ which was really a informal question, if you don't wan't to or can't do that then someone else might do that, maybe I take a look next week and do it, if not I think better apply your C way than leaving a bug unpatched. Kudos to you for your work! Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] #cinelerra irc channel usage
David McNab wrote: Hi all, At present, there's only one Cinelerra-related channel on IRC, which is serving multiple purposes as development discussion, help and general chat. As Cobra has expressed, there's a conflict between these purposes, with developers logging #cinelerra and using that to keep up to date with development issues, while others (including myself, guilty as charged) have also been using it for general interactions within the Cinelerra community. I apologise if I've been 'spamming' #cinelerra with subject matter which is not 100% specifically on-topic for Cinelerra. I can see two options for meeting all the needs: 1. have #cinelerra as the 'formal' channel for Cinelerra development and help, and a separate #cinelerra-chat channel, mentioned in the #cinelerra channel topic, or 2. allow general chat in #cinelerra, with a separate formal channel such as #cinelerra-dev for the more development-related discussions, and mention #cinelerra-dev in the #cinelerra chan topic Either way, it would meet the dual purposes - having a formal development-related channel, with relevant matter on the logs, not spammed by chat - and a separate place for cin users/devs to interact less formally in real time. Either option would work, as long as the #cinelerra topic mentions the other channel. Personally, I feel it's a healthy thing for the Cinelerra community to have an announced, active informal realtime discussion channel. Thoughts? The IRC communnity is not that big, I think one channels where users, developers and some private discussions coexist is fine. Splitting this small community is bad. Just be careful that you stop private discussions about knitting, cooking, politics, whatever, when a more proper (cinelerra) topic is discussed. I never felt comfortable with the public logging. IRC is meant to be a volatile place where humans meet and talk, this is also a social part of the community, you wouldn't like either if your pub-talks are logged, even if you meet with programmer buddies at the pub! IMO there is no much benefit of (public) logging an irc channel its rather even contraproductive for serveral reasons: * Things will be on google for eternity, one has to fear that things he saied could be misinterpreted out of context. * The signal to noise ratio is very high, you have to read pages of logs to gather little usable information. * in an chat are many errors, assumptions, half baked ideas, rumors. * People who know that this is logged are less motivated to write conclusions down to some formal/official document. My suggestion how to solve this: Don't log! Whenever we talked about something important and have some final conclusion (this could be howtos about doing things in cinelerra, or programming/design decisions) write a short transcript/conclusion down to a proper place (Documentation Wiki, FAQ, Design Drafts, ML Announce, ...). This makes sure that the text is reviewed and on topic. Further it directly addresses the intended audience, while keeping the IRC channel as place where the community can meet, no matter if developer or user. Btw I am fine if people log the channel privately and maybe exchange the logs, this ranting was only meant about public logging which ends up on some webserver. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
marquitux caballero wrote: in the comunity very cool people tried to explain me thos things, but they seems to be very focused in specific issues, and those BASIC things, are not important in this part of the coding process, and they told me those things are BUGs... really? bugs? or bad plannig, or even no global vision? Few people from IRC gathered together to plan a rewrite/redesign of what ought to become 'Cinelerra 3'. Please take a look at: http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess/Manifest http://www.pipapo.org/pipawiki/Cinelerra3 So far we have very cool ideas about a new design which allows a lot of things which are currently not possible, some coding has started but this is rather in a experimental, preparation phase. The downside is that we massively lack developers, unfortunally many previous contributors fallen away because they finished university, got new jobs or whatever. We aim to make cinelerra3 a open project where anyone can join and help as much as possible! If you are coder and interested, just join us. I've send a http://www.pipapo.org/pipawiki/Cinelerra3/Announcement about this 'cinelerra 3' project to all developers, so far the responses where very sparse but postive. A note to all 'users' reading this: Please refrain from sending feature request and ideas to us, its way to early and only costs our time to explain that we consider this things later. Ichthyo and me decided to design cin3 from ground up. Interested people should start by checking out the git repositories and review what is there. If you know how to do things better ask the responsive author of the current thing on IRC or via mail and do a discussion with the involved people about it. Speaking for me, I would like to see improvements and new ideas, but I don't want to become overthrown by people just dropping ideas and then disappear. Further note about HV's involvement: I informed him at first about this ideas, but his responses are sparse as usual. It is clear that this may only become Cinelerra 3 if he acknowledge on this project at some time and he is invited to join and contribute whenever and as much he wants to do (we aim to reuse code and ideas from cin2 anyways). Cinelerra is a heroinewarrior project, Cinelerra CV is a (friendly) fork of it, we don't want to take over the project, our goal is just to make the best free Linux Video editor in existence :). Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
David Kletzli wrote: I really have to learn how to use a wiki... On the site, I noticed you want to keep as much as you can to C coding. That said, has anyone considered using Qt for a GUI front-end (or at least the qmake mechanism)? First is was just up to reply following text to Fred Williams: Just before someone complains that I told we don't take user requests for cinelerra3 some explanation: * we currently work under the hood, how the render pipeline is constucted, how files are accessed and cached, how plugins are loaded into the core, how to interface different programming languages and so on. * A new GUI is far out of topic yet (and for long time comeing) and we don't want to be disturbed by Qt vs. Gtk flamewars. * When we start a new GUI (in 1-2 years?) first and foremost it should be functionally as identical as possible to the existing GUI. * After that we need to add some sane way to support the new features which will be there by then (more modifications on the render pipe etc) * Finally completely new features may be added, maybe users have ideas we don't know about, lets see. I opt for a 'add only, dont alter/remove' functionality (with *very* careful exceptions) * as ongoing effort we would consider how to improve existing usability in a convinient way, where user feedback and testing would be welcome. It might make it easier to build Cinelerra for multiple platforms and expand the user base. Multiplatform is far more than a build system and gui toolkit decision. Cinelerra is free software and we target Linux, at a lesser degree we might target other unix'ish platforms (thats not too complicated Edward Sutton already maintains a FreeBSD port). But considering our very low developer resources, the non-freeness of some other OSes, a broad competition of other products on mainstream desktop OSes, the uglyness of Win32 API's (and aqua likely too?) and many many other things. I'd just say no thanks I don't care for such portability. The price is just to high. That saied, if someone else wants to maintain ports to non free/nonunix OSes, go ahead, his contributions will be welcome. About build system: we currently trying to use some in parallel (namely scons and automake, someone wants to provide help with cmake?), as long we are testing and playing and the project is quite small this gives a good prooving ground for later decisions which we want to keep. Actually i am a bit pissed about any system and written http://www.pipapo.org/pipawiki/BuildingSoftware , even started to play a bit with the idea, but put that on ice, as long no one will help with such a project, its just to time consuming for me. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
Mark Carter wrote: One of my fears about cinelerra is that there are a lot of git code branches out there, each doing its own thang, and I wonder how much good effort will ultimately be effectively wasted. Looking at http://www.pipapo.org/pipawiki/Cinelerra/GitBranches is enough to make most people's head swim at what's available. Look at one of the descriptions: *ct* My branch/fork of cinelerra. Fixes, code cleanup and redesing *regardless of upstream mergability*. The SVN was declared to be following HV and staying mergeable, hence I started my 'ct' branch where developers can work without this brakeshoe. When your ficl integration is finished I would be happily to merge it there, if I don't have the time, just turn it, get my ct branch and merge your work, publish it. Read on ... My fear is that Cinelerra wont progress, but will just move around in circles, with users being left to decide which branch might best suit their needs. Users should not come at the point where to have to decide, this is where developers play with and finally agree about whats going into a official distribution. Having developers work public is just more transparent, note that many things in these git branches (ichthyos bezier patches, pmdumuids widgetgrid, the bluedot theme fixes and many more) predate the git repos. Just no one known/noticed that they where hidden privately on some developers harddisks or forgotten as patches once send to the ML. Having the code publically available with a convinient tool is a big improvement. I almost feel there should be a committee of developers, perhaps like the PEP proposals of Python, or soemthing. Its purpose it to access one fact - the intergrability of any change. We basically want to know if any change will conflict with the change of anyone else, and work out ways of mitigating the problem. I almost agree, using git gives us only the tool at hands to be able to publish, distribute and merge code. There is still some need to make decisions what goes into the distribution. I say this is a *big* problem when working in a centralized way like with SVN, every commit has global implications for anyone else so people better don't do decisions than being blamed for breaking anyone elses expections. This might work in a cooperate environment where is some big boss who decides whats to do and what not. But in a community project where no one wants to take this role this just does not work! People have to lobby their ideas endlessly and still might be unheared, commiters which advance with new ideas get blamed because the thing was not acknowledged, ... For cin3 we now work in distributed way and everyone happily merges everyone elses work, decisions are just done by the one which works one some part and sometimes simply acknowledged on irc/via email. If cin3 gets some drive and more developers we might need some PEP process, voting or some comittee. But so far it turned out that the current friction-less approach works quite well. I would like to see such in cinnelerra CV too but this would require some redefintion of the project goals. My ideal would be if free software could be done in a evolutionary process, where good ideas are exchanged and reviewed between developers and maybe seasoned/interested users (only a distributed revision control system makes this possible). Good things will persist and be merged while unimportant or bad things just get abadoned (but stay alive somewhere in a public repo to be fixed or reconsidered anytime later). Its true that distributed revision control encourages forking and branching which leads to many many diverged copies. For a closed/centralized project this is a horrific scenario. People need to rethink this when they use distributed revision control, they have the tool to merge such a diverged source back under their fingertips giving them ultimate control of whats going into their branch. That saied still means that git is just a tool to enable such a workflow, for certain (many) things there is still need to communicate and decide about a future project directions between the developers. imo it becomes easier with git since it gives the right tool at hand to branch, try and review ideas without global effect on other people and without dazzeling with patches send per mail, but it is still only a revision contol system not your boss or project manager which makes the right decisions for you. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone?
Mark Carter wrote: From: Christian Thaeter [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] The SVN was declared to be following HV and staying mergeable, hence I started my 'ct' branch where developers can work without this brakeshoe. If I understand correctly: * Cinelerra-CV is the ct branch, and the ct branch is considered stable no: cinelerra-CV is the SVN provided on cinelerra.org 'ct' is my private experiment to seed a version where people can actively do development work which may yield stable releases from time to time. * Ubuntu uses the ct branch to create Cinelerra I dont know what ubuntu uses. There are some fixes in 'ct' and people reported my branch working well (except some build system bug I can't track down, when it builds it should be stable at the current state) * cinelerra-svn is a track of the svn repository. What's the svn repository? cinelerra.org has a SVN repository, the git repository here at pipapo.org just tracks that for convinience. * you are now mostly working on Cinelerra 3, and not the ct branch currently true, the reason I started the cin3 thing was when I found some things which are hard to impossible to fix in cin2 (and thus in the 'ct' branch) which made me thinking that 'ct' may fail its goal being a refactoring/improvement. Dunno now if thats true but it definately needs much more work, prolly more than I want to invest alone. (Well, doing a cinelerra3 rewrite is even more work, but we will gain more than just bugfixes from that) So a good strategy for those hoping to see their stuff into Ubuntu would be to base their repo on the ct branch? I ever declared my 'ct' branch as private experiment, until others joins these efforts and it could be blessed some official 'cinelerra-improved'. This was only meant as seed for such a 'improved' version while I dont want to maintain it alone for an eternity. I had some talk with the ubuntu studio people some time ago with the conclusion that when they have issues (they had some about licensing) they should maintain their own branch and solve their issues in a way which is possible to feed back either into my branch or into SVN. I offered help when they approach me with this concept, so far no one came along so I don't really know whats going on there. When someone of the Ubuntu people reads this, please make a statement about this. I think, I write a separate mail about cinelerra2 maintenace.. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
This my maybe arguable view how to hive Cinelerra CV out of its develoment stall: 1) Change the focus of CinelerraCV Currently CVs goal is repackaging the HV version and fixing bugs. But a real community version should acknowledge progress and new features which are contributed by the community. 2) Stop using SVN Even if commit access is generously handled to people who ask, it's still a big blocker as I explained earlier. As long we have only one linear history everything has global impact and there is no easy way to add new features without running in troubles. There is no easy way that small groups of people try and review new features, no easy way to get good but intrusive new ideas back into CV. 3) Make releases Cinelerra CV has only this SVN there is no release schedule and no defined point when the source is called to be stable (well we can't define in a lack of testsuite and presense of many bugs anyways). This yields the result that anyone (including distributors and packagers) build on some (maybe recent?) svn revision. There are packages from many different versions out there which makes it not really easy to track reported bugs down. Users have doubts which is the best version for them already just because this linear revision history without release statements, which is imo more worse than a magnitude of git branches with defined releases (and maybe bugfix revisions on them) 4) Make tracking HV less important We want some branch which tracks heroines versions and refactors it into smaller commits as we are doing now, but this should be considered as tool and foundation of any work which is done on our releases. This means the CV version should be maintained in another branch and new features should be added on our development (or release) branches. Finally we may provide a backporting branch where imminent bugfixes are prepared to be mergeable with the hv-tracking version. So this becomes a way how we can contribute back to HV which is currently not a easy case. Maybe Adam once speaks about what he wants, so far he complained that the community didn't provide much useable feedback .. and admitably he was right, takeing HV less important will actually allow us to do more work and thus may provide more benefits for HV getting some contributions feed back. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
mark carter wrote: On Wed, 2007-08-15 at 19:36 +0200, Christian Thaeter wrote: 2) Stop using SVN I just saw a YouTube vid by Linus who is talking about git: http://uk.youtube.com/watch?v=4XpnKHJAok8 Even if commit access is generously handled to people who ask, it's still a big blocker as I explained earlier. As long we have only one linear history everything has global impact and there is no easy way to add new features without running in troubles. There is no easy way that small groups of people try and review new features, no easy way to get good but intrusive new ideas back into CV. I think the problem is that there's a lot of good code out there that isn't making it into the main tree, for want of a better word (and no, I'm not necessarily thinking of my code). Actually, I think the problem is only partly to do with it being in SVN and not in GIT. I think the main problem is lack of modularity. Without sufficient modularity, GIT can't help much. For example, I might even suggest (radically) that the plugins shouldn't even be in the git repository. People who want to write plugins should make their own repos consisting only of the plugin they want to submit. People developing the core of cinelerra wont even care about the plugins. Users can just download the plugins they're interested in, from whatever place they are available, and use those. Maybe packagers will come along and bolt the cinelerra core together with the plugins. It can go further. Take file loading. If file loaders were plugins, then that would be another that could be separated out. For cin3 we will do it this way, using the brand new git-submodule support which will become useable really soon. When it is time, detailed instructions will follow. For cin2, using git will just enable that someone sets up this infrastructure (I thought about doing this with the docs first, working together with raffa sometime next). You won't be able to propose / show such radical things on the SVN, git is just a enabler for this. The problem I see is that this has 2 parts 1. The modularization on the repository level, which is doable. 2. Tear the current sourcetree apart to modularize things, which has impacts on dependencies and build system setup. For the plugins that would be easy since they have already their own subdirectories, for filehandling and codecs this may involve quite much work and refactoring. What I'm saying is that in order for git to work, you have to have separate subsytems - with well-defined interfaces, of course. Thats one of the reasons which motivate cin3. I started to refactor cin2's sourcebase which seemed just to be a bottomless pit. I could be misunderstanding how git derives its strength, though.But I think the problem we're seeing is a lot of forks that don't stand much chance of being propagated to the main branch, which I think is a shame because it means that a lot of good effort has gone to waste. The question is who is responsible for deciding what goes into the main branch or moreover what defines a main branch. We need to change our goals first and define what has to constitute CinelerraCV releases and then think about some way how we work together to get the stuff in place, distributed revision control would be only a tool providing us the ability to reach this goals, but not make decisions about the project direction, thats clear. And thats exactly why I created this mob repository and my 'ct' branch, to free developers from the constraints that there is a stalled SVN branch with no much perspective to get things merged. Finally we have at least some discussion how to work this out, maybe really soon we can agree on some process how we assemble releases, maybe we just happily merge from each other and meet again in a few months and decide/vote what should go into a official release, or we nominate a Release Manager among us who is responsible to prepare the next release, or we use some shared git repo where anyone can push changes which will be blessed official and reviewed with the goal of a releaseable state. How we decide to do it lies in our hands, after all I try to push us into a Just-Do-It direction, we could talk endlessly about it, as long the current centralized branch is there, we will stuck to discussions with no progress. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
Kevin Brosius wrote: On 2007-08-15 17:36, Christian Thaeter wrote: This my maybe arguable view how to hive Cinelerra CV out of its develoment stall: 1) Change the focus of CinelerraCV 2) Stop using SVN 3) Make releases 4) Make tracking HV less important I've been pretty silent on these issues so far, not wanted to put a damper on new ideas and contributions, but looking at all the ideas makes me think you should really consider a true fork. I think declaring this a true fork would be contraproductive, my least intention is to divert the cinelerra community, I wan't to get some new drive where people are motivated to contribute. At some extent, this will only work if the Community supports this (if not, fine, stay where you are). Yet alone the discussion started now may hopefully yield some result which leads to little progress. You've proposed: for current CinelerraCV: * Changing the project goals * Changing the project tools As new project: * Redesigning the core of Cin * Rewriting the core of Cin Take this as 2 different things which don't depend on each other and could happen each one alone and in parallel. I think you won't get much feedback from the older core developers since these goals are so large and you haven't tackled a smaller piece of Cin first. I have done little work in my branches but get demotivated by this 'bottomless pit' discovery and that there is no much perspective to get new things merged into the SVN trunk because it breaks the current concept. I think thats exactly what many other potential contributors see. There are patches and contributions rotting somewhere. The other thing that comes to mind is that you shouldn't co-opt the Cinelerra name for a new project (Cinelerra 3) if Adam does not contribute a reasonable portion of the code. It is, after all, his video editor. As the Cinelerra 2 code base is GPL, you can certainly use portions of it for a new design with attribution to Adam. I agree that we could only name it Cinelerra 3 when Adam supports this decision. We will certainly reuse some of his code and I have the hope that he contributes/joins the efforts somehow/sometime, but thats really up to him and I don't want to make guesses unless he speaks out. So far we would like to name it cinelerra 3 because out intention is to create the next incarnation of cinelerra and not just another video editor. The amount of work proposed for the new project is not unlike the scope of a project we presently have running at work. It's probably a 10 year project until completion. I suspect the core contributors are not thinking about a full rewrite at this time. Well, then think about it. I know that this is a massive task for the next few years and we won't or even can't do it alone without support and help from the rest of the community. I'd like to hear their thoughts also, of course. Me too, well I can only stress that this might be started by a few people as now, giving it a seed and motivation, but it will require the experience and involvement of more people in future to become a success. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
Martin Ellison wrote: Could you explain this more? svn allows branching, so why not just create as many development branches as required and work there? I do not know git, so could you please explain what git has over svn? (Not intended as an attack). I am out of office today. In short: SVN allows branching but does not support (enough) merging and has many many more problems. Best let linus explain: http://uk.youtube.com/watch?v=4XpnKHJAok8 Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] ct branch: ar: ./cinelerra/data/theme.o: No such file or directory
mark carter wrote: Hi there cehteh. I had downloaded your ct branch a couple of weeks ago. I thought I'd give it another investigation. When I try to do a make from the top level dir, I get ar cru libcinelerradata.a ./cinelerra/data/theme.o ar: ./cinelerra/data/theme.o: No such file or directory this is some build system error which shows up on some distributions and some automake versions (but works for me). I tried to find the cause but i really don't know what happens there :( ... anyways you can go back in history by past the new build system things with: git checkout e46ddf6ed91e5cbd05af15a0df2e427570e3951d (or create a branch from that) another thing is seen, is that you written some logging, please consider to use my http://www.pipapo.org/pipawiki/NoBug instead, I am already did a lot work integrating it in cinelerra in some other branch (not ready yet). Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] build failure AMD64 debian sid
try ./configure --disable-mmx Christian Graham Evans wrote: No problem Graham. I would have said this is a different problem anyway. :) I am still getting build problems with a fresh checkout of cinelerra. I seem to have ruled out the most recent cinelerra change as the cause by reproducing the problem with svn 1017 (thus the new thread title). Svn 1017 was building for me less than a week ago but the build now terminates as below. I guess that leaves the other sid deb packages as likely culprits. I tried downgrading core-utils which changed versions a few days back but that didn't help. What else can I look for? Should I be trying to use some compiler flags (as opposed to none)? I am using cinelerra cv svn 1018 on AMD64 X2 running debian sid 2.6.21-2-amd64 with nvidia opengl driver. The build teminates with the output I've posted right at the end of the email but I think possibly more relevant is the build output a bit further up which has lots of these: ...predcomp_mmx.s:517: error: invalid operands in non-64-bit mode predcomp_mmx.s:518: error: invalid operands in non-64-bit mode predcomp_mmx.s:519: error: invalid operands in non-64-bit mode predcomp_mmx.s:520: error: invalid operands in non-64-bit mode ... and these... quant_mmx.s:429: error: invalid operands in non-64-bit mode quant_mmx.s:430: error: invalid operands in non-64-bit mode quant_mmx.s:431: error: invalid operands in non-64-bit mode quant_mmx.s:432: error: invalid operands in non-64-bit mode ... and possibly more usefully here is one of the gcc commands leading up to one of these sequences of errors: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../quicktime -I../libmpeg3 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -MT quantize_x86.lo -MD -MP -MF .deps/quantize_x86.Tpo -c quantize_x86.c -fPIC -DPIC -o .libs/quantize_x86.o /bin/sh ../libtool --tag=CC --mode=compile ../admin/nasm -g -O2 -c -o predict_mmx.lo predict_mmx.s ../admin/nasm -g -O2 -c predict_mmx.s -fPIC -DPIC -o .libs/predict_mmx.o \1 better written as $1 at ../admin/nasm line 12. Use of $# is deprecated at ../admin/nasm line 27. nasm -felf predict_mmx.s -o .libs/predict_mmx.o predict_mmx.s:45: error: invalid operands in non-64-bit mode predict_mmx.s:47: error: invalid operands in non-64-bit mode predict_mmx.s:49: error: invalid operands in non-64-bit mode ... Does this mean anything to anyone? This should be a pure 64 system but it seems some part of the build system is confused. Here is the termination output... predcomp_mmx.s:524: error: invalid operands in non-64-bit mode predcomp_mmx.s:526: error: invalid operands in non-64-bit mode predcomp_mmx.s:527: error: invalid operands in non-64-bit mode /bin/sh ../libtool --tag=CC --tag=CC --mode=link gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -o libmpeg2enc.la conform.lo mpeg2enc.lo putseq.lo putpic.lo puthdr.lo putmpg.lo putvlc.lo putbits.lo predict.lo readpic.lo writepic.lo transfrm.lo fdctref.lo idct.lo quantize.lo ratectl.lo stats.lo motion.lo cpu_accel.lo fdct_mmx.lo fdctdata.lo idct_mmx.lo idctdata.lo quant_mmx.lo quantize_x86.lo predict_mmx.lo predcomp_mmxe.lo predcomp_mmx.lo -lm -ldl -lpthread ar cru .libs/libmpeg2enc.a .libs/conform.o .libs/mpeg2enc.o .libs/putseq.o .libs/putpic.o .libs/puthdr.o .libs/putmpg.o .libs/putvlc.o .libs/putbits.o .libs/predict.o .libs/readpic.o .libs/writepic.o .libs/transfrm.o .libs/fdctref.o .libs/idct.o .libs/quantize.o .libs/ratectl.o .libs/stats.o .libs/motion.o .libs/cpu_accel.o .libs/fdct_mmx.o .libs/fdctdata.o .libs/idct_mmx.o .libs/idctdata.o .libs/quant_mmx.o .libs/quantize_x86.o .libs/predict_mmx.o .libs/predcomp_mmxe.o .libs/predcomp_mmx.o ar: .libs/fdct_mmx.o: No such file or directory make[2]: *** [libmpeg2enc.la] Error 1 make[2]: Leaving directory `/home/gray/install/hvirtual2/hvirtual/hvirtual/mpeg2enc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/gray/install/hvirtual2/hvirtual/hvirtual' make: *** [all] Error 2 grateful for any help... Graham E ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] libcinelerra3
Herman Robak wrote: On Fri, 24 Aug 2007 21:58:55 +0200, Derek McTavish Mounce [EMAIL PROTECTED] wrote: Forgot this. More of a question on what you mean exactly: An NLE that deals with TV material (not just cinematic stuff) ought to be able to preserve interlacing throughout the workflow, no matter how many effects or transformations you throw in. It is absolutely not possible to apply a transformation other than simple translation to interlaced video and maintain the interlacing. If you scale or rotate the image, you're scaling/rotating the fields which completely defeats the purpose of interlacing. You must deinterlace. There's not a program out there that can maintain proper interlacing once you scale, rotate, or apply fx. Perhaps though I'm misunderstanding, in which case please explain further. :) Maybe, maybe not. You do not have to deinterlace in the common meaning: Merging fields into frames, thus reducing 50i to 25p. To maintain the temporal resolution, one has to do the opposite: separate the fields, and process them separately. They are separate images, after all. Here is how I think it should go: 1) Split out the fields, putting them after one another on the timeline. 2 a) Line-double or interpolate them up to full vertical resolution or b) Make the rendering pipeline treat the fields as very wide non-square pixels. b) .. lets us safe memory since fields have only half the bandwidth (memory, cpu,..), but we need pixel aspect and the render pipe needs to be aware of this, it needs also be aware that bottom fields are shifted a halfline lower (important for temporal effects). 3) Transform, rotate, translate, filter, whatever the fields... 4) Merge back the fields to frames, if/when appropriate. Since field 1 and 2 are separated on the timeline, all the pixels in the final field 1 will come from the source field 1, no matter the deformations that have been applied. The pixels may need stretching or interpolation to fit into their new positions, but keeping the fields apart is just a matter of combing them out and putting them in their correct temporal position on the timeline. A capable NLE should do that. ack --Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Irritating freezing
Preferences - Alsa Settings - check Playback locks up Hello! I just compiled fresh Cinelerra on Ubuntu with dual core Opteron. And there is one problem. If I select clip from resources and go to viewer and start playback it goes well. But if I hit stop, pause or use the slider to search clip I lose control. Depending which videoplayback driver I get frozen image in viewer (X11-GL) or the viedo continues playback. Anyway the volume bars keep working and timecounter goes on. After a while I can't do anything with viewer. Main program- Window - Show viewer won't hide it. Same thing with moving from resources to track and using compositor. My material is RAW DV. I also tried with M2T HDV material. I've tried to tweak with display properties. I also tried with some oher clips. Some cellphone avi clips work perfectly while normal Wav file causes viewer freezing. Any help would be nice even how to write better bug report. With this info it's hard to start guessing what went wrong. So has anyone any ideas? Terminal has these last lines, which seems to be quite OK, or am I wrong. abf 00:00:00.00 2000-00-00 00:00:00 7b 87 04 16 36/36 abf 00:00:00.00 2000-00-00 00:00:00 7b 87 05 16 36/36 abf 00:00:00.00 2000-00-00 00:00:00 7b 87 06 16 36/36 # audio block/sample failure for 5 blocks, 180 samples of 1920 BRenderThread::start 1 map=6948 equivalent=6948 brender_start=6948 result=6948 end=6948 RenderFarmClientThread::run: Session finished. BRenderThread::start 1 map=6948 equivalent=6948 brender_start=6948 result=6948 end=6948 RenderFarmClientThread::run: Session finished. BRenderThread::start 1 map=6948 equivalent=6948 brender_start=6948 result=6948 end=6948 RenderFarmClientThread::run: Session finished. Hannu Vuolasaho Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it! http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] NVIDIA driver regressions, performance/stability problems
I've updates the nvidia display drivers yesterday on my wifes machine and found out that the recent driver has some hefty regressions/instability/performance problems. IIRC someone else reported problems with cinelerra some time ago, so I just want to notify anyone about this problem (it might not happen on your hardware, please send feedback). We have a cheap GeForce 7300 GS card here, on a 64bit Debian etch, Athlon64 Dualcore. I tried following versions: NVIDIA-Linux-x86_64-100.14.19-pkg2.run [stable stable] NVIDIA-Linux-x86_64-100.14.23-pkg2.run [beta version] where cinelerra was sometimes quite sluggish, using Xv in xine or mplayer crashed the machine sometimes. Generally the display freezed for few seconds sometimes just using gnome desktop (no gl/no xv). After some googleing I found out that that other people have similar problems and some hat succes by downgrading to: NVIDIA-Linux-x86_64-100.14.09-pkg2.run I tried that too, and ..tadaa.. it works! Again this does not mean that the driver is buggy for anyone and that you shall downgrade when it works for you, but when you have similar problems please try a downgrade and report if it improved the situation. Next, whenever nvidia releases a new driver, please notify the list when this bugs got fixed for you, thanks. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] What would motivate developers
Jonas Wulff wrote: * Help coding already planned and important things Is there a list somewhere of *concrete* things to do (besides the bugtracker) somewhere? And not just on the coding side of things... Maybe we should create a list (and have it online) like this: Exactly thats what I meant, it is already a valueable contribution that you just start with this list! Thanks. Other people may work out things about coding tasks, I can do that somtime next for the cin3 tree. Further, I can't say that enough. I would really really like if the website would be some wiki where people are actually able to work with content (not just the documentation wiki). I have something in my queue to make a web-editable (wiki) like git interface. Maybe you'll see it in december :) .. note that I am currently busy with other things (and Piksel next days), be back in december. Christian Documentation: == * Special effect tutorials (timewarp, motion, subtle color correction) * Tutorials on using cinelerra with blender, audacity etc... (It doesn't have to be a one-click solution as long as you know the workflow) * ... Coding: === * Fix bug Nr. * Implement feature Website: * Put the tutorials in a more prominent place! There are IMHO *far* more important than having every format for every translation listed explicitly. * ... I hope my point gets clear. I think a clear list of (more or less) small, well-defined items would be helpful and would attract more people to actually *do* something rather than talking (well.. as I do now. Sorry for that ;) Cheers, Jonas ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] What would motivate developers
mark carter wrote: Christian Thaeter wrote: some personal opinions... A list of things which I would make me happy: * More people contributing to the project. * Help coding already planned and important things * Send patches (git mob?) which fix existing issues. Looking at Cinelerra, I'm amazed at how Linus manages to get anything done with what must be a volley of patches that are flying all over the place. Git has the (big) advantage over svn in that if an ordinary Joe like me downloads a repo, I have immediate source control for my own work - whereas I'm given to understand that svn doesn't. I think the problem we're seeing is that there's good code going into mob that is not seeing its way upstream. And I don't think it ever will. Well you likely can't imagine how much kernel patches and repositories are all around and will never be merged :) .. same with git itself, when you look at the Mailinglist you see a lot of proprosals which are abadoned, thats the way free software works when it is under control of a benevolent dictator. For cinelerra things are little different: If you mean HV by upstream, thats sadly true, we can't say anything about what he might merge or not. For our own SVN, j6t merged mob contibutions quite often in the past. I think sending things to the mob and proprosing them on the mailinglist turned out quite well and even got some drive recently. Of course mob won't get automatically unreviewed merged into svn and no one wants to waste time, reviewing something unfinished. So you can push things to mob, whenever you are satisfied with the state, please post a merge proprosal to the ML. Further we might decide to use only git in future and setup some shared repository where some trusted people can push to for merges. This would make the workflow considerably simpler. I'm not sure that the svn commiters pay much attention to what's going into mob. Perhaps we need someone who will clear patches. This can be difficult work. For example, I decided to take a look at the latest commit. It was by Craig Lawson. Now, what I am about to say is in no way meant to be a disrespect to Craig. If I were to review that commit, then, as a raw developer in cine, I'd be trying to ask myself what the problem is, and how his solution solved the problem. If I were doing my job meticulously, I'd look up what roundf() does, and try to convince myself that it does the right thing compared to int( ... + 0.5). I'd also note what appears to be some dubious code quality ... there's a block that seems repeated twice, but with slightly different values. Again, I want to emphasise that I'm not criticising Craig! There'd be quite a lot of work to do, even for a simple patch. From what little I've seen of the Cinelerra code, it's a big victim of cut-and-paste programming. I'm sure it did what it was supposed to do for the original author at the time, but to an outsider, it's very very messy. Hey we use a distributed revision control system, this means we can merge code which is only coarsely reviewed to not contain backdoors and obliviously bad code into a 'very_experimental' branch which might be a starting point for all kinds of code to evolve until they eventually hit the mainline. I don't think code has to be reviewed and validated to every single aspect from the very start on. We can do some experimenting, git is *very* good in 'software archelogy' which lets you exactly track the history of each single function and line. Things are easy reverted and thrown away when they turn out be be bad. Code has to be written few times until it is satisfactionable in my experience anyways. On the other side, I have strong suspects that the code Craig pushed there is useful for him and quite likely for many others too. So I would vote for generous inclusion of mob code into a experimental branch, setting the barrier quite low. The question here is, Who decides and I have the feeling that we should just decide by doing it. So whenever one wants to go ahead and pick this up, just do it. I think it would be very useful to have someone act as a clearing house for bug fixes. It's /possible/ (no promises!) that I might have some free time in the new year, and could contribute in this way. * Caring for infrastructure, Well, one thing that disappointed me recently is that I submitted a patch that added some doc-building infrastructure. I created a Makefile.am, which I think is a start to getting docs built automagically. I incorporated the facility for generating info files, so that you could type info cinelerra and get info about cinelerra. Now, admittedly, what I had submitted was crude - from the release early, release often school - but it doesn't look like my patch is ever going to make it into svn. That being the case, I'm disinclined to polish my efforts further. Hey, i've rewritten the whole build system, cinelerra build in 3 minutes here now
Re: [CinCVS] What would motivate developers
mark carter wrote: Christian Thaeter wrote: mark carter wrote: For cinelerra things are little different: If you mean HV by upstream, Primarily I meant CV - I was assuming (very dodgy assumption, I know) that HV and CV perform a cross-merge, on the basis that it's all good stuff. thats sadly true, we can't say anything about what he might merge or not. For our own SVN, j6t merged mob contibutions quite often in the past. I think sending things to the mob and proprosing them on the mailinglist turned out quite well and even got some drive recently. Of course mob won't get automatically unreviewed merged into svn and no one wants to waste time, reviewing something unfinished. What I think would be nice for git would be a facility where one could describe a branch, and add status messages without necessarily commiting files. Maybe a bogus diary/ChangeLog might do the trick, or something. So you can push things to mob, whenever you are satisfied with the state, please post a merge proprosal to the ML. Thanks. Although I can't do it now - maybe at the end of this year - I'll have to see how my repo can be connected to mob and my branch on your machine. No doubt things have gotten hideously mangled and will need some surgery on my part. Merge often, try fake merges which you undo when there are no conflicts, or rebase your work on top of the svn-git. This ensures far less pain than a long delayed merge with many conflicts. Further we might decide to use only git in future and setup some shared repository where some trusted people can push to for merges. This would make the workflow considerably simpler. I'm thinking out loud here. What about the idea that we use mob in a slightly different way. If someone wants to fix a bug (bug 123, for example), they create a new branch bug123 off mob, and push their changes to that branch. When complete, they mail the list, it gets reviewed for backdoors, and a test compilation is done against svn backported changes +all the bugs integrated so far. I'm not sure what we'd do about experimental or other stuff - we'd need to chew that one over. What this means is that we have specific heads that identify specific bugs, we have some quality control with a low barrier, and we get code that compiles cleanly (or else the branch is rejected). So, in this way, we're really trying to maximise our chances of getting those bugfixes upstream. Sound useful? There are no restrictions on how to use the mob. Give it a try, but keep in mind that this branches have to be kept in sync, I may argue that long-living bugfix branches won't scale. But really its open for any try, we will see what works best. I would suggest to use a rather hieracic way where anyone first has his own branch, then maybe his own sub-branches for features or bugfixes and these are then merged against a 'bugfix-incoming' branch which is otherwise in sync with the mainline. Depending on the traffic on this bugfix-incoming it might temporary split up in more branches, some bugs certainly need more attention and longer testing and work, while others are done with a few lines. Hey we use a distributed revision control system, this means we can merge code which is only coarsely reviewed to not contain backdoors OK. I wasn't sure how much quality control was applied. Thats was my personal opinion, I am already quite sure some people disagree with it :). But well, don't misunderstand me that I would accept bad quality, my point is just that there has to be some start even an unacceptable contribution might lay a seed for a better fix and evolve into something good. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] What would motivate developers
mark carter wrote: Christian Thaeter wrote: Well you likely can't imagine how much kernel patches and repositories are all around and will never be merged :) .. same with git itself, when you look at the Mailinglist you see a lot of proprosals which are abadoned, thats the way free software works when it is under control of a benevolent dictator. I'm not sure if any of you have seen the Google video where Linus talks about Git: http://www.youtube.com/watch?v=4XpnKHJAok8 He expressed disappointment with all other forms of revision control systems that he reviewed after giving up on bitkeeper and starting git. He was asked what system he would use if he didn't have git (and bitkeeper), and he said that in that case he would probably just apply patches, like he did in his early days. I'm amazed! As you guys will no doubt be aware, I had created some patches for Ficl, and left cinelerra alone for some time. When I tried to apply the patches to a later version, there were quite a few conflicts. Backed up from my other (limited) experiences with revision control systems, I came to the conclusion that conflicts arise really fast. Mergability is a real problem. I guess Linus must be some kind of God. It happens that there are no much changes in cinelerra, lucky for you. Well, when I replaced the GC in cinelerra in my experimental branch, which was a intrusive 1+ Lines patch, syncing it with svn didn't conflict much eihter. Cinelerra has so much code even 10k lines of code barely scratch the surface. Otherwise, git can't magically resolve conflicts, you *WILL* get them too when things are edited concurently. The only any most important difference for git is, that you can and should merge often. If all involved people do that, then changes are propagated before they raise conflicts and when conflicts happen they are small. If you don't do that not even git would protect you from massive conflicts. Merge often! Thats really easy and convinient in git. Some people suggest test-merges, that is: Try a merge but undo it when there where no conflicts, this keeps the history clean. For your private (unpublished) branches you can use 'git rebase' too, which also gives a clean history and keeps your work in sync with the main repository, be careful that rebase 'rewrites' history. That means that you should never ever use rebase if any other branch depend on it. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] What would motivate developers
Richard Spindler wrote: 2007/11/12, Christian Thaeter [EMAIL PROTECTED]: Hey we use a distributed revision control system, this means we can merge code which is only coarsely reviewed to not contain backdoors OK. I wasn't sure how much quality control was applied. Thats was my personal opinion, I am already quite sure some people disagree with it :). But well, don't misunderstand me that I would accept bad quality, my point is just that there has to be some start even an unacceptable contribution might lay a seed for a better fix and evolve into something good. Guide to a nice distributed development model: - Major contributors get to control the central repository. How is that distributed? :) - Minor contributers send patches to Mailinglist. If patches are okay and plenty, minor contributor is given commit access and becomes major contributor. Imo too much work, someone has to pick the things up from the mailinglist and commit them somewhere, I like the mob repo thing more. Of course people may still send patches to the ML if they dont use git, thats better than nothing. Git can apply mailboxes too. - Independent code chunks are spinned of into seperate projects. API is fixed. If an API change is neccessary, he how proposed the change needs to provide patches to affected projects. - If someone is unhappy with the main repo, he may branch and create his own repo. Everyone already has his own branch in git, that makes everyone happy by default :) -etc... Add in some automated test runs and a build-bot to spot regressions, and that's it. ACK. Hope to see you at Piksel at the git presentation :) Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] What would motivate developers
Johannes Sixt wrote: On Monday 12 November 2007 17:48, Christian Thaeter wrote: There are no restrictions on how to use the mob. Give it a try, but keep in mind that this branches have to be kept in sync, I may argue that long-living bugfix branches won't scale. But really its open for any try, we will see what works best. The workflow *must* be that a contributor bases his code on the cinelerra/svn repository and pushes to mob for others/me to pull and commit back to svn. My favorite workflow actually is that we abandon svn altogether. But I don't know how our packagers can deal with such a situation. Opinions? Vale? Kevin? While speaking of mob: Christian, would you mind clearing the house? The mob repository has some test commits that turn up again and again. Well, after all valuable contributions have been salvaged... Thanks for your opinions. The mob repo is completely free without any restrictions, anyone can clean it up. I am busy this days but I can do that when I am back from piksel and find some time.. I won't mind when anyone else does it. Christan ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] What would motivate developers
Burkhard Plaum wrote: Hi, Christian Thaeter schrieb: Richard Spindler wrote: 2007/11/12, Christian Thaeter [EMAIL PROTECTED]: [...] - Minor contributers send patches to Mailinglist. If patches are okay and plenty, minor contributor is given commit access and becomes major contributor. Imo too much work, someone has to pick the things up from the mailinglist and commit them somewhere, Depends on how many patches you expect to get per day. People talk a lot about git and other tools, and I believe that for high-traffic projects there *is* a difference. But for low-traffic projects (which cinelerra is with respect to patches), the mailing-list model works perfectly as long as someone feels responsible for patches (and understands the code enough to review them). Cinelerra currently lacks this responsibility, so far I think no one would like to do this job. Further plain patches loose valuable information (Who was the original author, what where the intentions, when was the patch created, based on which source, ...) This are the things a revision control system provides. Git knows a email based workflow, in fact git itself is developed this way, which is rather high volume. Traffic makes no difference. I feel much more convinient with using git in a push/pull model, others might prefer the ML, that is ok as long we have some way to commit patches without loosing associated metadata which is somewhat important. - Independent code chunks are spinned of into seperate projects. API is fixed. If an API change is neccessary, he how proposed the change needs to provide patches to affected projects. Well, there are quicktime4linux and libmpeg3. Don't know how independent they are nowadays. What's IMO much more important to attract contributors is the code itself: When I look at the sourcecode of ffmpeg, it's quite easy to find where and how things are done. If I want e.g. to understand how cinelerras filters work, I see a poorly documented mixture of GUI-routines and functional routines. Maybe it's my allergy against C++, but I doubt, that many people will jump in and start writing/improving cinelerra filters... I can tell a bit about that, because 5 years ago we did the same thing as you: Fork code from heroinewarrior.com, libquicktime in our case. In the beginning it was actually just a patch, and we tried to be compatible to qt4l. But then the decision was: Either keep the code like it is (keeping compatibility), or clean it up, so others can work on it as well (but loosing compatibility). I (being the only member from the original team) decided for the latter, and still think it was right. This is no offence against any upstream developers: Many of my daily programming techniques are learned from qt4l. Burkhard This will be done better in cin3, using extern libs if possible, try to avoid to patch common libs, document code, write testsuites,... Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] What would motivate developers
Martin Ellison wrote: 1. Developers don't want to learn 100,000 lines of code before they contribute anything. 2. It depends what you mean by Cinelerra... Perhaps you would be better off starting a new video editor from scratch and reusing design elements from Cinelerra when useful; some of the suggestions seem to amount to this, except they want to call it Cinelerra. Actually the work on a new video editor like you say, this has already started some months ago. Yes we call it 'Cinelerra3' so far, since it will be done with cinelerra's spirit in mind. If anyone (especially Heroine Virtual) objects on this nameing we will change the name. Cinelerra is a bit different from other free/open-source projects in that the Original Founder (Jack) does not want to manage the community project (contrast Linus); neither is he prepared to hand everything over to someone else. This leads to a question that will always be with us -- what is authentically Cinelerra? It is Heroine Virtuals decision to run the project in any way he wants. Granting it to the community under the GPL license is probably the biggiest possible contribution. We have to respect his decision to keep himself out of the community management. On the other side we have it under GPL and we have all (gpl granted) rights to do with the project we wan't. This *is* a hand over to the community. He didn't object on any changes which where done on the community version and so far he didn't object on the plan to rewrite and name the new one Cinelerra3. I also think we can delay this decision until we can show a first useable version, which is very far ahead. The question What is authentically cinelerra is really unimportant, the real questions are: Where is the public developement done? Cinelerra community Who 'owns' cinelerra? Each programmer has the copyright of the source he contributed to What can we do with cinelerra? Everything the GPL permits Who decides about the future of cinelerra? Anyone who contributes to the project For me it is fair and important that we respect and credit Heroine Virtual, even if not required under the terms of the GPL. Respect means also to accept his decision not to nanny the community and that we can and should move forward on our own. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Pushing to cine3 mob
Johannes Sixt wrote: On Sunday 18 November 2007 12:54, mark carter wrote: I made a small doc change to cine 3. I was trying to push it to mob, but no joy :( If memory serves, I first did: cloned git://git.pipapo.org/cinelerra3/ct git checkout -b mcarter Hack hack hack git commit README git push git://git.pipapo.org/cinelerra3/ct mcarter:mob But I get: fatal: The remote end hung up unexpectedly error: failed to push to 'git://git.pipapo.org/cinelerra3/ct' please try following url git push git://git.pipapo.org/cinelerra3/mob master:heads/refs/mcarter You cannot push via git:// protocol (unless CT has specifically set it up that way). I don't have notes what the correct URL is to use, but maybe someone else has? CT? Yes I enabled it but mob repositories, not mob branches :) -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Pushing repos
Mark Carter wrote: Cehteh, you asked me to do: git push git://git.pipapo.org/cinelerra3/mob master:heads/refs/mcarter But it didn't work :( Uhm, master:refs/heads/mcarter .. sorry, my fault if that doesnt work, dont hesitate to aske me. I can push from my clone of the mob repo back to your copy of the mob repo, but I cannot push my clone of your ct branch to your copy of the mob repo. This makes sense, because they're two different repos. no should work and that is the intended way things should be done you might add git remote add mob git://git.pipapo.org/cinelerra3/mob to the clone you did from my branch then you have a shorter nickname for the mob branch git push mob master:refs/heads/mcarter is more friendly then .. finally after you 'created' the mcarter branch with that git push mob master:mcarter should work .. you can even register this push locations in the .git/config, (see manpage) to make that the default when pushing My solution was to add the README file from the ct repo to my mob branch, modify it, and push the changes to your mob branch. that also works Christian Hopefully, it should all come out in the wash when you pull from ct to mob. ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] introduction
august wrote: hey everyone, just wanted to write and introduce myself...and possibly ask a question or two. My name is August Black and I already met quite a few of you from the cinelerra working group in Bergen, Norway at the Piksel festival. So, hello again! I've been a broadcast2000/Cinelerra user ever since, well, it was called broadcast2000. I cut a few documentaries and such in 2000, 2002, and tend to make something, audio or video, with cinelerra about once or twice a year. So, I'm not really a noobie nor a guru. I still have the cut and paste editing style from the bcast2000 days...but am learning more about labels, clips, and the viewer window for two window editing. I think I got a good handle on it now. I've been a fan of this software for a while now, despite all the quirks and am amazed at how far it has come. so Bravo to all involved! I use it for all of my editing needs. And, I recently used it for a short film in Norway I made with my colleague, Federico Bonelli. http://www.cinemasolubile.net/?p=97 hey I want to show it my wife, where are the downloads? We only ran into a few problems...some of which I figured out how to do, others I am still looking for answers. First, what is the best way to export all to DVD? I try to render MP2, but it has NEVER worked for me. I find myself rendering to RGB and then encoding with ffmpeg(which also has some majore quirks) render to DV or some other high quality master format (mjpeg) and then reencode to the target format is sadly the suggested way for now. Second, how can you set the keyframe curves so that they are linear and not logarithmic. the logarithmic curves make sense for the audio, but not always for the camera and projector. For example, I'm trying to make a scrolling credits page, but need the motion to start and stop on a linear rather logarithmic curve. you can drag control points out of the curve points when pressing ctrl (or was it shift?) while dragging a point on a curve. Next ichthyo made a much better but experimental bezier inperpolation patch which gives better/more control, digg the mailinglist for infos about it. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: [piksel] Linux Video Editing Discussion
[EMAIL PROTECTED] wrote: On Fri, November 16, 2007 15:25, Richard Spindler wrote: Hi, The following document was created today, summarizing the discussion points that came up today, during an effort to create an overview about the problems where linux video editing is still without solution. Have fun, -Richard ---8- Linux Video Editing: Open Problems Problem #1: Detect Interlacing in Videofiles/streams, through Image Analysis Subproblems: * Detect 3x2 Pulldown, vs. Video. * Topfield first vs. Bottomfield first. Relevant Links: * http://silicontrip.net/~mark/lavtools/ Possible Problems: * Later Editing could introduce sudden changes in pulldown sequence Possible Approches: * Compare fields, to detect duplicates, which is common in pulleddown material. * Look at deinterlacers in MPlayer etc. Unsolvable: Put a 60i Overlay, (Titles) on a 3x2 Pulldown source. Problem #2: Develop Algorithms and Processing code, for not-upsampled YUV 4:2:0 or 4:1:1 Source Footage. Common Filters and Operations. Chroma-Keyers, etc. Problem #3: Interaction between Cinelerra/Linux Video Editing, and Scientific Community, Research on Image-Processing, Algorithms, etc. Have someone that reviews scientific Papers for their relevance for Video Editing. Problem #4: General Purpose Image Processing Library, accellerated using OpenGL Graphics Hardware. Ideas: Processing Graph, Automating Parameters, Different Colorspaces, Packed vs. Unpacked, Software Fallbacks for unavailable Hardware features, Scaling, Aspect-Ratios, Interlacing, take model of OpenGL Shaders into account. Problem #5: Simple Control Protocol, most likely OSC, because it is widely used in the Audio Community. Jack-Transport for Playback Syncronization. Subproblems: * Jog-Dial Support/Daemon over OSC? * Hardware-Support, Slider-Decks, Knobs, etc. * MIDI to OSC? Problem #6: Temporally compressed Video processing, MPEG, GOPs Subproblem 1#: „Give me Frame 10“! No matter whether B, P or I Frame. No consideration of Performance. * Consider Memory Mapping Compressed Files, reusing kernel file cache * Fast-Forward, Seeking, Scrubbing, Sustained, illusion of instant access * Sparse fetching of compressed GOPs. * Detect and reproduce bitrates and stream restrictions (think: export to devices) * „clever“ reencoding around cuts, collapse GOPs if necessary? * (Keyframe marker in UI) * Index Building (File index, endianess neutral) Problem #7: Detect scene changes in footage, with image processing Problem #8: Multiprocessing: Multicore, Distributed. Research? * Distributing footage (e.g. NFS) vs. homebrow protocol * Review Scientific Papers to multiprocessing * Is abstraction between Multicore vs. Distribution possible. * Compression on Render nodes, means Network capacitiy is no bottleneck. * One GOP per Node? * Lossless Codec? * Failure Tolerance? Crashing Nodes? Failover? * Adding Node? Network Autodetection Avahi, Zeroconf? * Endianess, Different Operating Systems, Distributions. Simple Tasks: * Make Youtube simple uploader program in C with libcurl Problems that still need Discussion: * Intermediate Formats * Plugin generation I'd like to add a couple of things: - shake elimination : to remove shaking of the caamera - using image analysis to line up one frame with the next Works fine in cinelerra. A improvement would be to generate motion vectors and use this vectors to reduces the motion blur. Generally Richard, Herman and me (et al) agreed that we wan't no bulky overloaded supereffects but that it is somewhat essential for free software to develop effects which do simple things and then can be used to combine new functionality. In this case this means we need: 1) an analyzing part which derrives motion vectors maybe even more smaller ones for perspective and rotational detection. (cins current one does all at once) 2) Transform tools which operate on the vectors from 1) again diffrent ones (xy, zoom, rotation, perspective) 3) (not there yet) directional deblurring also using the vectors from 1) Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: [piksel] Linux Video Editing Discussion
Jonas Wulff wrote: Generally Richard, Herman and me (et al) agreed that we wan't no bulky overloaded supereffects but that it is somewhat essential for free software to develop effects which do simple things and then can be used to combine new functionality. In this case this means we need: 1) an analyzing part which derrives motion vectors maybe even more smaller ones for perspective and rotational detection. (cins current one does all at once) 2) Transform tools which operate on the vectors from 1) again diffrent ones (xy, zoom, rotation, perspective) 3) (not there yet) directional deblurring also using the vectors from 1) Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra Sounds good -- but doesn't that imply the need for a much more sophisticated plugin API? Otherwise one would need to use very ugly workarounds to pass more info than just the picture itself... this is just general thinking not about an actual implementation, for cin3 we plan a backend which can cope with this. But we need to draw a line of things which are of general interest (algorithms and implementations) and things which are better left for the implementor of a video editing program, aka not produce yet-another-framework or plugin api. Sometimes the backend can cheat around plugin api deficiencies in other ways there is no way then this api cant be used, maybe improve it or switch to another one, time will show. Christan ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
Herman Robak wrote: To the new readers here: There is a wiki page with a collection of suggested usability enhancements for Cinelerra, here: http://lab.dyne.org/cinelerra/Usability Wow, i didnt know about it :) One of my pet peeves is that users shouldn't be expected to care about settings for which there is a 99% safe default. YUV, YUVA, RGB, RGBA or floating point presision color format? My guess is that 90% of the users ought to use YUVA, so let that be the default. Is the difference in memory footprint between YUV and YUVA so big that it warrants a setting? I'm not sure. should need 25% more memory and alpha is taken in account when mixing with all 3 other channels together. I am not sure but I won't wonder if there is a big performance hit sometimes. PAL, NTSC or anything else? Firstly, that should depend on what the user loads upon startup. If it's a PAL video, setting the project resolution to PAL is a fairly safe bet, in my opinion. If it's 1080i HDV, set the project to 1440x1080. I also think the default should be either PAL or NTSC, depending on the user's locale. If you're in Europe, you're most likely to deal with PAL, for example. I dont like too much automagic things. How about have a 'unconfigured' state where creating tracks/putting things to the timelime are greyed out (only add to resources when loading?) and one has to 'setup project' first (with a big reminder Setup Project First! in the statusbar). Thats common in a lot other applications. Ymmv since this disables some functionality at start, but gives the user a hint about the needed preparations. Then 'Setup Project' may default to the a format choosen by loaded resources, locale. As I see on irc, editiong just pal/ntsc is not the most common case anymore, many people rather decide computer screencasts, youtube, etc. formats. Interlacing... That's so involved that it belongs in an essay of its own! Cinelerra must know more about interlacing, so that the users can get by without know anything about it. Ack, but maybe hardly doable for Cin2. Aspect ratio. There is not really any setting in Cinelerra for that. There's a project setting labelled aspect ratio, but that's the _display_ aspect ratio. And it's _global_, which is just wrong! Because the aspect ratio can differ between sources, so if you mix sources (16:9 and 4:3, for example) Cinelerra will not try to Do The Right Thing. We may keep the global Aspect Ratio setting, but that would only be a _render_ setting, i.e. render to 16:9. A missing setting/property is the pixel ratio. If Cinelerra knew the pixel ratio for every resource, it could calculate and perform the appropriate stretching and cropping/padding, without user intervention. Pixel and aspect ratios are often not quite what we think they are, as explained here: http://www.bbc.co.uk/commissioning/tvbranding/picturesize.shtml ack2, as above Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Making Cinelerra smarter, so the user can focus more on making movies (usability, etc.)
Herman Robak wrote: On Mon, 10 Dec 2007 06:33:07 +0100, Christian Thaeter [EMAIL PROTECTED] wrote: Herman Robak wrote: ... I also think the default should be either PAL or NTSC, depending on the user's locale. If you're in Europe, you're most likely to deal with PAL, for example. I dont like too much automagic things. How about have a 'unconfigured' state where creating tracks/putting things to the timelime are greyed out (only add to resources when loading?) and one has to 'setup project' first (with a big reminder Setup Project First! in the statusbar). Thats common in a lot other applications. In my opinion, that's annoying. I want to do stuff, and I strongly resent apps that tells me to answer their questionnaire first! But then again, why does Cinelerra have to have a project resolution? How about having a canvas that is simply fit to largest? Of course, the user should have the _option_ to set the canvas to some standard size. Well for cin2 we have this project resolution thing, its probably not easy to plug out of the sourcecode. Thinking about cin3 we have this 'everything is a node in a graph' where nodes inputs and outputs will have very specific properties like size, color depth, aspect ratio and so on. Nodes which are incompatible can not be connected together, point! But cin3 can choose 'conversion-nodes' (scaling, letter|pillar boxing, framerate, YUV/RGB conversions, etc) and insert them automatically (or only on demand in HQ/PRO mode). A alpha channel is something special here since alpha is created by the application (unless we have some video codec which supports alpha) and more importantly, alpha is consumed by the aplication too since the renderpipe runs bottom up, we can pass a 'need for alpha' property up and only when alpha is needed AND present it will be passed around. Finally encoding will be done in graph nodes too, that is where you define framerate, resolution etc. for the output video, there is no global project setting. One could even have serveral encoder nodes at the end of a renderpipe (or even in the middle) for example encoding for DV, DVD, SVCD and Youtube in one rush. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] hardware question
Scott C. Frase wrote: On Thu, 2007-12-27 at 11:45 -0600, Timothy Baldridge wrote: Your disk performance may be holding you back as well. On the oil effect, you are CPU bound, on a faster effect (e.g. grayscale) you will be primarily IO bound. Here's an example. Only recently (in the past 3 years) has Discreet moved to x86. Before that they were selling their highest end product (for editing 4K film) on a quad CPU 1Ghz. But they smoked the competition when it came to performance. Why? Most of the time these systems had a 10-30 fibre channel RAID behind them. This allowed the Tezro and Onyx3 systems to edit 5 streams of real-time 4k video on a system that had basically no number crunching power. 9 times out of 10 you will be limited by your disk performance, not the CPU. I would suggest running a bonnie++ benchmark on your disks, from there you can calculate an approximate max fps processing rate for the disks. Timothy Hi Timothy, Thanks for the thought. I have been monitoring wait i/o via mpstat and it doesn't seem to be the issue. Here's recent output of mpstat using a bunch of effects on a HDV video render, including oil painting. The sixth column is iowait: 01:15:45 PM CPU %user %nice%sys %iowait%irq %soft %steal %idleintr/s 01:15:55 PM0 87.300.000.600.000.000.300.00 11.80150.20 01:15:55 PM1 87.400.000.700.000.000.000.00 11.90127.90 01:15:55 PM2 86.700.000.400.200.000.300.00 12.40150.20 01:15:55 PM3 87.710.000.300.000.000.000.00 11.99128.00 01:15:55 PM4 87.400.000.400.000.000.000.00 12.20134.30 01:15:55 PM5 87.100.000.600.000.000.000.00 12.30128.00 01:15:55 PM6 86.700.000.100.000.000.000.00 13.20134.10 01:15:55 PM7 86.800.000.200.000.000.000.00 13.00128.50 Notice that iowait is zero. I do have a couple of RAID 0 filesystems, one based on software RAID and the other hardware. scott Cinelerra has some race problems between threads which let them wait on each other doing nothing, this is hard to fix unfortunally. But generally I think adding more CPU's will add some performance improvement. While in doubt, you may better opt for more ram (4 or more GB of ram). For long time future I we will fix this (with what is called cinelerra 3 now) to have no races and utilize multi cpu systems much bettter, but don't hold your breath yet for that. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] hardware question
Scott C. Frase wrote: On Sat, 2007-12-29 at 20:27 +0100, Christian Thaeter wrote: Cinelerra has some race problems between threads which let them wait on each other doing nothing, this is hard to fix unfortunally. But generally I think adding more CPU's will add some performance improvement. While in doubt, you may better opt for more ram (4 or more GB of ram). For long time future I we will fix this (with what is called cinelerra 3 now) to have no races and utilize multi cpu systems much bettter, but don't hold your breath yet for that. Christian Hi Christian, Yes, I continue to notice race conditions here and there. For example, after doing some basic editing on a HDV project with two stereo audio tracks and one video track, I wanted to move one audio track down in the timeline. When I did this, I triggered a race condition that hung a CPU at 100% for 30 minutes. Bummer. Hannes gave me some instruction last year on how to track these issues down using kdbg: http://crazedmuleproductions.blogspot.com/search/label/kdbg I will try to capture some debug information the next time it happens. Imo waste of time, I know some of the code and (see condition.C) it might be evolved due workaround problems in early linuxthread implementations but it is horribly ugly and broken by design. In a experimental branch I started to add my 'NoBug' library with a resource/deadlock checker to cinelerra which shown a few too. But finding this races is really the simplest thing. Fixing them is a really hard design issue, I won't say it is impossible but it is certainly not simple and very intrusive. I started to write more bullet proof locking classes for cin2 just to find out that going over the code and refactoring/adding that was more complicated than I imagined. Actually the locking problems in cinelerra are one of the main issues I proprosed cin3 as new rewrite. If you have the patience and want to make some efforts to fix it, that would be a major contribution to cinelerras stability and performance, but for myself I dont wan't to touch that code anymore currently. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] hardware question
E Chalaron wrote: Hi all, Just to carry on with my initial post regarding hardware. Considering that I just need power to render, not for editing (which seems to trigger the problem with multi cpus), I always thought that getting a rendering farm of PS3 could be smart ? I am most probably not aware of potential issues. So consider it as a naive question. cheers Cinelerra is in no way optimized for Power PC or the SPE's in a Cell processor, at best you could get it working on the (main) PPC processor of a Cell CPU with moderate performance. Probably even that would give some serious headache (maybe easier, sony supports linux on cell). Adding support for the Cell SPE processors which give the magic performance boost would introduce a new code path for rendering, thats something which is somewhere between much much work and impossible in current cinelerra, I doubt anyone would waste massive developers resources to for such a very specific hardware. Even for cin3 we won't support that, it is just to much work for now. The design of cin3 should be open enough to add such things but the work for implementing such extra code paths would be massive and likely not be done anytime soon. I recognize that the advantages would be enormous but if we want some (far) future support for special hardware we should at least choose something which has an open API and will be available/compatible for the years coming. I suggest to delay this decision for the time being and then see whats there (GPU cards for general purpose computing become available now, maybe Cell blades / expansion cards, future will tell). Supporting a game console might be nice because of the low price tag, but product cycles are likely faster than we can write software for it :P Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Video quality in DV/LP mode
Terje J. Hanssen wrote: Not directly Cinelerra related, but yet: I plan to refresh or backup my Analog S-video footages after DV conversion to hard disk and from there record back to camcorder DV tapes. Especially as I have footages on several 90 minutes Hi8 tapes, I wonder if I can use 60 minutes Premium DV tapes and record in LP mode to fit the same content? I expect it is no idea to go up to a higher quality DV tape in LP mode in comparison with the price for dual Premium DV tapes in SP mode. May DV in LP mode decrease the video/audio quality of the converted DV, possibly more drop outs etc? Yes, the recorded video quality in LP mode is exactly the same as in SP but: LP mode is archived by moving the tape slower, resulting in more tight tracks on the tape. At playback time there may be more errors which player may or may not compensate by ECC. I wont suggest LP for long time/high quality storage and/or low quality tapes. Better make some evaluation how your camcorder works with certain brands of tapes .. or just forget about that idea if you want long time storage. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: [piksel] Fwd: [estudiolivre] I believe in cinelerra
Fabianne Balvedi wrote: -- Forwarded message -- From: Leo germani [EMAIL PROTECTED] Date: Jan 18, 2008 7:53 PM Subject: [estudiolivre] I believe in cinelerra To: estudiolivre [EMAIL PROTECTED], Felipe Fonseca [EMAIL PROTECTED] What Develop cinelerra as a professional free/libre video editing tool. Why Cinelerra is the most powerfull free software for video editting we have nowadays. Although it has many resources and that it is far more advanced than any other Open Source video software, its development is very slow and has no sponsor. Its main developer, Heroine Warrior, do not mantain a SVN or a mailing list. The last official release was last july and there is no sign of a upcoming version of cinelerra. They usually publish a new release every six month or so but do it only for their own needs and do not talk with the community much. Few developers mantain a fork called Community Version. All out of volunteer work they mantain a SV a mailing list and an online wiki. They also fix some bugs and add some features to the code. This desorganized development results in a mess. There is no official stable release and package for the distributions, and cinelerra is now known as very hard to install and unstable software (although it got really better last year). Also, first contact with cinelerra is usually disappointing because of a not well resolved interface and also because of big flaws it has on some funcionalities. With all that said, it happens that we have a software that is, at the same time, powerfull enough to do any kind of editing, but weak enough to have very basic issues of usability. And the feeling all advanced users have is: We are pretty close to have high standard software! To learn more about the mess, take a look at this page: http://cv.cinelerra.org/about.php Many of the actions described on this plan are already been done by many people, but in a rather heroic way. If this people got motivated, organized and _paid_, cinelerra would increase its quality dramatically in a short period of time. The Plan 1. Get the community together The community of developers today is very small and spread, and cinelerra has no road map. We started already to work on a 'cinelerra3' (me, ichthyo, other people from IRC). We have a vision, a plan, design documents and already some code. Some docs on my wiki you may read: http://www.pipapo.org/pipawiki/Cinelerra3/Announcement http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess/Manifest This wiki is almost phased out now, we document inside the code repository, but comments/edits there will be acknowledged. First thing to do is gather this people to discuss about the future of cinelerra, identify the main flaws and its solution, make a plan to organize the place and set up for new features. I dont want to go into the details, just an introduction: * We rewrite it from scratch, but reuse code and ideas where possible * We work bottom up, first a core render engine, the GUI at last * Being language agnostic, plugin-interfaces will be plain old C then it is possible to write things in different programming languages * Using a free distributed devlopment model, that is: * for the developers, there is no (mandatory) central point, anyone can work on it, everyone is equal * Discussion is done on irc or in private mails * final decisions are published inside the repository docs * lowering entry barriers as much as possible Cinelerra needs a project leader, an interface designer, and more people with defined roles that should be choosen on this meeting. This designated roles are secondary, first and foremost Cinelerra needs people who actually *DO* things, then then the one who maintains the communication about merges or the one who works on the GUI or whatever gets this role de-facto. Developers of other softwares are also welcome. Cinelerra is, so far, the only video free editing video editing software with professional approach, but it could share a lot of things with other software, such as effects, for example, that shoul be usable in any video software, just like we have LADSPA for audio. There is already a video effect standar called Frei0r that cinelerra does not support. Frei0r is quite limited, for cinelerra we would like more professinal plugins. I don't want to blame it, actually this simplicity is also a big advantage for frei0r, easy, fast, pragmatic. We will certainly use it too and there are many other requests by users (gstreamer, commercial plugins, ...) this will be addressed. 2. Diagnostics Cinelerra code is not very well documented, so few people have the idea of how tuff is to deal with it. Second step is to see what must be done so we can invite more people to colaborate with the code. Documentation, refactoring, etc. It also has to work on the API so other people can write plugins and effects.
Re: [CinCVS] cin3
Burkhard Plaum wrote: Hi, 1) Compete fiercely to get as many coders as possible to join either camp (Cin2 or Cin3) I would be interested in Cin3, and I downloaded the git source. But one thing in the source immediately scared me off: This is meant to be a community project, not anyone writes perfect code at the first try (except Linus ... but certainly not me), When you see something which you know better, proprose that, if is really better chances are extremely good that it will be included. cinelerra3/src/lib/time.h: typedef struct timeval cinelerra_time; followed by some inline (for performance reasons :) functions to handle times. Why don't you just do: #define CINELERRA_TIMESCALE 100 // Microseconds typedef int64_t cinelerra_time; int64_t is a C99 type, not even available in C++ i've choosen a portable (POSIX) time representation and a plain C interface there to make it available for other programming languages too. Next I am thinking it will be nice to use the standard time representation which is used by system timers and other posix functions too since thats where we will use it. and leave the arithmetic stuff to gcc? Before this gets off-topic: Is there a better place (not IRC) to discuss about cine3? email, or use my wiki at http://www.pipapo.org/pipawiki/Cinelerra3 Burkhard ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Standards for render components
Martin Ellison wrote: Where should Cinelerra go next? Several comments: * the first components to focus on should be o the renderer -- renders from the Edit Decision List and the assets to a codec, taking however long it requires o the previwer -- renders to a screen window, taking at most 17ms so it can do 60f/s only one renderer which maybe has diffrent code paths (software, gpu, ...) controled by quality/resolution/profiling parameters. Have a scheduler where we can assert frame pulls I need frame 2 at quality level N in 17ms, and btw i am playing forward, if possible prepare me frame 2 and following as well. This Scheduler can the report immediately Yes sounds doable or No way, I wont even try, drop this. As well as some extra hints like give me the nearest frame to frame 40 within X ms or adaptive quality/resolution while scrubbing one sees low res/low quality preview and when stopping scrubbing the exact frame where it stopped is rendered in (maybe incremental) better quality/res. This needs also a sophisticated caching system which maximize and monitor memory usage and ensures that frames which are expensive to render and/or often reused (mpeg keyframes for scrubbing) are readily availabe and dont need to be re-rendered. Perhaps with some profiles to determine the cost benefit of caching or rendering for a given thing. * the renderer needs to be made up of components that might o apply an effect frame-by-frame (each frame independently eg chromakey) o change the number of frames (eg pulldown) o combine several clips (transitions, compositing) * the edit decision list would then be a graph of component nodes * free/open source projects work by dividing the code base into modules that can be worked on independently, replaced by better alternatives, and reused on other projects. * therefore the important thing is to define the interface between components. For cin3 everything will be entered in a big graph including decoders and encoders, mixers, effects, ... what you see in a compositor is basically only a tap on one of this nodes (yes it would be possible to have multiple compositor windows and attach them at diffrent points in the graph). We define a module/plugin system based on C interfaces so that anyone can write plugins in different languages. take a look at the cin3 design docs. Also, look at Blender. This contains a video editor with similar functionality to Cinelerra but a less-usable user interface. However, it would be good if both projects could address the same interface to allow reuse of components. Blender is only one of many which defines its interfaces in its own way. We plan to define our own interfaces which exacltly meet our goals and then use wraper plugins which can adapt to foreign interfaces/plugins (blender, frei0r, gstreamer, effectv, ) Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra3
Raffaella Traniello wrote: On Mon, 2008-01-28 at 19:19 +0100, Simeon Völkel wrote: But: PLEASE, write only SERIUOS and SUSTAINABLE suggestions to not fill up the wiki with spam. I disagree. Sometimes even stupid names can feed your brain's creativity and help to get *the* idea for the perfect name. I'm going to add a rubbish bin at the bottom for names not seriously and sustainably moulded. I agree with the disagreement ;) ... feel free to make suggestions within the next days, after thats settled we scratch out the ones which are really improper (taken by or similar to other projects, bad language etc) With whats left we then discuss and decide more seriously. I suggest that the final decision will not be a vote and decided by the people who are actually involved in the project (this could be you, we need helpers!). Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cin-3
Burkhard Plaum wrote: Hi, Christian Thaeter schrieb: Moreover when plugins want to provide gui's on themself (dialog window for configuration, timeline rendering, mask overlays, patchbay widgets,...) these should/must use the toolkit a upcoming gui uses. So we have the choice of either decide on a tookit or we wrap an tookit abstraction and some custom widgets we need into a glue layer. The later would be a major task with much work to do for something which likely never happens (porting the gui to another tookit). My suggestion is the following: - Define a set of abstracted widgets, which are already sufficient for 95% of all plugins. The advantages are: * Those plugins never have to mess around with a GUI. * Those plugins can more easily be used by other apps. * If config widgets for those plugins are built by the core, we already have a consistant look and feel - Define a parameter type complex, in which case the plugin has to provide * a config widget for that parameter * Methods for reading/writing values of this type from/to project files * A method for automating the parameter along the timeline (if that makes sense). - If it turns out, that a such a complex parameter type is not so special (i.e. it's used by more than one plugin), it can be moved to the core easily. I'd rather separate plugin rendering functionality, parameter passing and the gui. For rendering we already concluded to use gavl to pass data arround, I didn't yet checked if gavl has some provisions for passing metadata/parameters along, if not, this might be a nice feature someday. Distributed plugins which just do the work on a renderfarm will just work, the GUI is only needed for the front node where the user sits. Next the GUI should be written application specific, this is a part of the plugin you have either to port; Or we agree on a common widget interface as you sketched above. One just has to define and implement this interface (Hands up please). Making it application specific is currently the low hanging fruit, time will show, when a common interface becomes available new plugins could use that and old ones could be ported over. Anyways this will ensure that the approach is sufficent for 100% of all plugins. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cin-3
Herman Robak wrote: On Tue, 29 Jan 2008 09:39:11 +0100, Hannu Vuolasaho [EMAIL PROTECTED] wrote: Date: Tue, 29 Jan 2008 07:44:28 +0100, [EMAIL PROTECTED] wrote: Theoretically a nice Idea, but remember that a NLE can have very complex, custom Widgets, like the Timeline and Previews, these should ideally be written only once, putting together some buttons and basic widgets in different Toolkits is never a Problem. Moreover when plugins want to provide gui's on themself (dialog window for configuration, timeline rendering, mask overlays, patchbay widgets,...) these should/must use the toolkit a upcoming gui uses. So we have the choice of either decide on a tookit or we wrap an tookit abstraction and some custom widgets we need into a glue layer. The later would be a major task with much work to do for something which likely never happens (porting the gui to another tookit). We just don't have the developer resources to do so. Just one stupid question. What is wrong with current GUI? For you an me? Very little. But please realise how irrelevant that is. Potential users and developers think Cinelerra is stuck in the 90s because of its GUI. Users believe the whole application must suck at least as much as its GUI. Developers don't think it's worthwhile to learn about a GUI toolkit that is only used for _one_ application. Bottom line: To many users and coders, Cinelerra doesn't LOOK worthy of their time and effort. The current tookit was written by HV when there was no other free alternative which was suitable for the task. This was really great work but cinelerra2 design is quite tightly coupled with this tookit. It has some problems/workarounds which where prolly necessary that time (multithreading on linux was pita) but which are now a major problem for stabilizing and extending the cin2 codebase. For me it is not the LOOK .. I somewhat like it, many people disagree. The most important thing is, when we use a common toolkit we don't need to care for maintaining our own, its easier to find programmers who are familar with it, it will save *a lot* of work. To explain why this is so, and why it is futile to try and tell the rest of the world that it ain't necessarily so, I will refer to Joel Spolsky's article The Iceberg Secret (Joel on Software, February 2002): 'Important Corollary One. If you show a nonprogrammer a screen which has a user interface that is 90% worse, they will think that the program is 90% worse. ... What happened during the demo? The clients spent the entire meeting griping about the graphical appearance of the screen. They weren't even talking about the UI. Just the graphical appearance. It just doesn't look slick, complained their project manager. That's all they could think about. We couldn't get them to think about the actual functionality. Obviously fixing the graphic design took about one day. It was almost as if they thought they had hired painters.' LOOK and USABILITY are different things, the look has influence on the usability, as in contrast, memorizeable icons, layout which is logical and minimizes mouse movements,.. but usability defines much more than what you just see, and this is an area where cinelerra2 could need some improvements. We have many ideas and will brainstorm about this when it is time (not yet!) Christian http://www.joelonsoftware.com/articles/fog000356.html --Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: User interface toolkits and Cin-3
Burkhard Plaum wrote: Hi, Richard Spindler schrieb: 2008/1/30, Gour [EMAIL PROTECTED]: Martin (For Qt), Is it possible for the community (ie anyone outside Martin TrollTech) to write user interface widgets? Cin3 will need to Martin write some specialist widgets -- how will this fit in with the Martin toolkit and the toolkit's development process? No idea. Let me just say that GTK+ toolkit is getting native on Mac OS X, works on Win and it's not property of Nokia ;) Writing Custom Widgets is possible in every Toolkit, and Qt has been native OSX for a long time. But indeed, GTK seems to catch up. Discussing Toolkits is pointless btw. without someone actually writing the Code for said toolkit. Actually I didn't want to participate in toolkit discussions, but if we agree, that 1. All plugin interfaces are C because this is the smallest common base to make it bindable to other languages. The idea is to make the plugin interface easy bindable to other languages. 2. Plugins should be allowed to make their own configuration widgets we are already restricted to a C-toolkit or not? C binding would be sufficent, and it should not do too much, just being an UI toolkit and not expect we will use its object system/types for anything else than the GUI. Burkhard ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] User Interface CONCEPTS mockup.
ok, I've made a wiki page to collect ideas: http://www.pipapo.org/pipawiki/Cinelerra3/GuiBrainstorming Please add your proposals/ideas there, don't go too much into implementation details, refrain from altering others ideas (except for typo and gramatic fixes). This shall serve just to collect the ideas, discussions and working them out should be done on the mailinglist. Final decisions are not scheduled yet and will be done by the people who actually care for working on the GUI (much, much later). When it is time this things will be passed on a per-item base to the DesignProcess and then added to the repo Tiddlywiki's. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: Quick Start Guide
Sami Kallinen wrote: great post, thanks. been poking around the website(s) and asking questions on the irc, trying to get an overview of the project. needed something like this. should there be a quick start page containing this info in the wiki home? Good idea, make one, its a wiki hint, hint ;) cheers, sami kallinen (aka sakalli) On Feb 12, 2008, at 21:21, [EMAIL PROTECTED] wrote: Am Dienstag, den 12.02.2008, 21:45 +0200 schrieb Dirk Uys: I am interested in getting involved with the development of the new version of cinelerra! I am a C++ developer, but I know a fair amount of C. Hello Dirk, you are welcome! What I would really like to know, is there some web page or document that contains all knowledge/ideas/guidelines about cin3 to this date? We have quite some infos scattered on various levels -- I mean from rather abstract to practical and low-level. The project home is currently on Christian Thaeter's pipawiki http://pipapo.org/pipawiki/Cinelerra3 Besides this wiki, the Core of our project is contained in the GIT repositories. Within this tree, you'll find a directory with some TiddlyWikis containing the design- and technical documentation. You can browse the GIT trees at: http://pipapo.org/gitweb Currently, my GIT is the most up-to date http://pipapo.org/gitweb?p=cinelerra3/ichthyo;a=summary I put together some snapshots (of the mentioned design TiddlyWikis and a Doxygen run) on my webpage at http://ichthyostega.de/cin3/ You may want to have a look at our project meetings on IRC http://ichthyostega.de/cin3/wiki/index.html#IRC-Transcripts If you are interested how things started out, you'll find a polemic I wrote about the old source base, some conclusions and a first preliminary project plan at http://pipapo.org/pipawiki/Cinelerra/Developers/ichthyo/Cinelerra3 NOTE: this pages are from last summer. At this time, we thought to rather do a partial rework the old source base. But by now we are a complete rewrite and will soon have a new Name different from Cinelerra3 The project is in a early stage and things are much in flux. Please feel free to ask more questions. We don't have a complete Architecture overview or Roadmap yet, but it is clear that the new app. will have three Layers: - Backend (written in C, ask Christian Thaeter for details [EMAIL PROTECTED]) - Proc-Layer (written in C++, ask myself for more details [EMAIL PROTECTED]) - GUI. (no maintainer yet, only some brainstorming) Cheers, Hermann Vosseler (aka. Ichthyo) ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Lumierra com and org
Yama Ploskonka wrote: I just picked up the domain names lumierra.org and lumierra.com, to avoid them being taken over by someone not related to the project. Will be happy to transfer them to the formal project once this is decided as our name, or if that doesn't gel they are neat names for video/image stuff Well, thanks, I like that name too, but we didn't yet agreed on it (how about doing that now?) We decide about a webserver next week (sharing one between some people/free pojects). Meanwhile i could park the domain on my DNS (pipapo.org) but its not really urgend when we decide next time anyways. Christian Yama ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] why not...
[EMAIL PROTECTED] wrote: About a new name of cin3, we can use on-line vote with the best/all name on http://pipapo.org/pipawiki/Cinelerra3/Names We can start 10 day vote for new name and we can finally stop this thread! ;P There are some options how we can decide on a name. Whats important to me is that people which are involved can veto which names they don't like (nobody wants to work on a prokect which name he doesn't like). Voting would then be ok after this veto'ed names got removed from the list, otherwise I set the nameing on the agenda for the next OpenVideoDeveloper meeting on 6.th march where we will decide when nothing happend earlier (so just go on!). We will talk about the nameing next days on the LAC in colonge too (who else besides hermanr, oracle and me is there). Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cin3 naming
Raffaella Traniello wrote: Ciao! I want you to know how the naming is going. I talked with cehteh and ichthyo, the core-devs of the project. They agree that the naming is based on community contribution. The community has done a great job during the collecting names phase. All the names proposed (seriously or not, on ML, IRC, private mail to the core devs or directly on the wiki) are written on the pipawiki page http://pipapo.org/pipawiki/Cinelerra3/Names At the moment 73 of them are in the main part, (nearly) all of them commented and tested for domains, google search and trademarks. 188 are the names or the inspiring words just listed in the Rubbish Bin. Total 261. Yes, you read correctly: they are 261. That wiki page collects also all the criteria for a good naming stated or discussed on IRC and ML. The community is so big and the names are sooo many that a selection process has been organised: The number of names will be narrowed down. The criteria will be applied to the reduced group of names. The names with the highest marks will enter a popularity contest at the beginning of March. That contest will be announced on the Mailing list but will be held on a wiki page. The name will be decided at the next developer meeting on IRC (6.3) For details about the selection process see the wiki page. Now, if you really want to help for the naming: - always refer to the wiki page linked above. - write (and sign!) your comments about a specific name directly on the wiki page. - check the rubbish bin for seriously good candidates left behind. Move them to the main part of the page. Comment and test them for domains, google search and trademarks. Perfect, I just replied to akir4d without reading this mail, so I want to make it clear that I second this plan even if my other response left this unclear! Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] More logos for Lumiera
Ichthyostega wrote: Leandro Ribeiro schrieb: 1) The small L in the font type used motivated this logo, because it looks so much like a piece of film. I've tried with different colors, but I only liked it with the red one. The idea is to create a classic (both in font type and logo) feel, using a more old fashioned, yet elegant, approach. Wow! especially liked this one Has a touch of old cinema projector, or like a moviola. It also reminds me of a musical score... really inspiring! yes, I like that too, the best one so far, great work. Some suggestions (dunno how it looks, just ideas): * make the 'l' in the logo little bit smaller (or the box biggier) so that the red color flows around it. * experiment with different sizes of the dot in the logo (biggier) * correct the kerning between the m and the i, move them little closer together. * is the font designed by you? make it little less strong, the holes in the 'a' are quite small and it looks blurred together, also the serifs on the l,m,r,a. the rolling dot might be more distinct like in the logo. (well this are already suggestions about fine tuning if we decide on this logo, we are not that far yet, aren't we?) * in a huge (poster version) the logo 'l' might contain transport/ perforation marks, like a film. maybe not just interested how that would look like. * generally tryout diffrent sizes, screenful, splashscreen size, a size 2-4 times biggier than the screen font (logo on help screens etc), screenfont size (10 point), just the 'l' logo from poster to 16x16 favicon sizes. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cin 3: my 3 cents
Marcin Kostur wrote: Dear developers (...developers,developers,developers)! Although I do not contribute to the cin3 source (so far ;-), I have few thoughts: 1) Blender has great GUI and works with windows. If cin3 is working on windows community is 100x bigger! Blenders also are programming, AFAIK, NLE as a module... ;-) Compatibility with windows has other issues in videoediting, remember we have to chew on many many gigabytes of video data in nearly realtime. This requires a low level data management which is tied to the underlying OS (Posix for this). Next no one of the developers uses Windows and we don't want to support non-free OS'es. We won't reject patches if someone works on a windows port, but really, We don't care for it. Next, hermanr is absolutely right, we want a pro interface, but it should be familar and useable by novice users and people who know Cinelerra. 2) Since few month i use audio editor ardour2 - it has really nice and quite stable multi-track interface. Maybe there is a chance of reusing? The GUI decision is left out for now, we concentrate on the backend. You might contribute to the Brainstorming on the wiki: http://www.pipapo.org/pipawiki/Lumiera/GuiBrainstorming But don't expect any concrete decision made anytime soon. 3) Cin3 must be fast and resposive with HDV. For example avidemux can really fast play and scrub 1080i - many times faster than cin2. Proxy on cin2 do the job but it is hassle to setup etc. Should be one button intermediate format mode. Agreed, this will be addressed 4) cin2HDV - what would you think about mixture of proxy and bgrender: each source track is bgrendered to images instead of result. Then with OpenGL composer most of ops could go smooth? My experience is that [EMAIL PROTECTED] decode is a bottleneck. Read the design documentation, basically this will be handled slightly different to what cinelerra currently does. There is always something like a background render which prepares frames which will be needed. The previewer will adapt on the current hardware capabilities and users choice (render for FX, resolution, framerate, quality, ...) Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Can I Get Involved?
Joel Holdsworth wrote: On Fri, 2008-03-28 at 18:36 +0100, Herman Robak wrote: On Fri, 28 Mar 2008 14:16:58 +0100, Joel Holdsworth [EMAIL PROTECTED] wrote: Hi All, I'm thinking of getting involved with development on cinelerra/luminerra, so I thought I'd say hello on this mailing list. For the last year or so, I've been working with the inkscape guys, honing some UI issues. At the moment though, given that they now have 100 developers on team, it looks to me like they have enough people, and things seem to be going along nicely. My bread and butter is really GUI work, and so I'd be really interested in getting involved with the Gtkmm or Qt migration - if that's still happening. In GUIs I always try and work toward intuitive, tidy, rule-abiding, quality; and so it seems to me that maybe I'd have something to contribute Cinelerra. For myself, I've mostly worked in Win32 and Gnome. I've used gtkmm a fair bit, and I would say that it is excellent. So is it possible to get involved with the UI work? and if so how can I do that? I would consider a partial replacement of the current GUI in Cinelerra 2.x, starting with one of the dialogs. Anything else will likely be a complex instability hell for a developer who has not delved deeply into the innards of Cinelerra yet. The one dialog I think is in most dire need of refactoring is the Record dialog. But that can be daunting, as it interfaces with hardware like DV cameras and video grabbers. Maybe the Format and Render dialogs? That sounds like a good strategy. Replace all the dialogs, one by one until they're all migrated. Then maybe some kind of branch could happen to convert over the main UI. But I suppose the first question is what GUI toolkit should be chosen?. My vote would be for gtk(mm) - but obviously this is a decision for the established development team to decide. i agree with richard, the one who does it, decides (while acknowledge, propose that first) gtk is nice, did you had a look at lua-gtk, seems to be sexy to make the gui in a small scripting language. what do you think? About how to get involved? .. just clone the git, look at the design/docs/wikis, communicate and propose your ideas and start hacking. Christian (little short now, more tomorrow) ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] [Announce] Third Open Video Developer meeting, aka First Lumiera Developers meeting
Hi folks, our next Developer meeting is scheduled on Tuesday the 3. April 2008 at 21:00 GMT We know that this time is uncomfortable for people downunder and far east, please speak up urgendly with other time proposals if you want to attend! This time we will held the meeting on irc.freenode.net in #lumiera which is our new project channel. The agenda for this meeting is at (down the page) http://www.pipapo.org/pipawiki/Lumiera/MonthlyMeetings There isnt really much yet, maybe we could make it this time 'in time' but anyways, please contribute Topics when you have ideas. Sidenote: our server at http://lumiera.org is up, no shiny page yet. I just copied the docs and other useful information up. The git repositories are working too (sans anonymous uploadable mob repos, I will set them up on demand). Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] LGM !
Roland wrote: Hi all, Why not Lumiera at LGM? Libre Graphics Meeting will take place at Wroclaw (Poland) on 8-11 th May 2008. 8th May is our developer meeting :P What about a participation of the Lumiera team? Application as project there is likely a little to short in time prolly for the organizers there, certainly for us. Going there as visitor might be doable, but I have to check out what it would cost, likely too expensive for me. Anyways the idea to show presence at such meetings is good. This would require we have: - a logo not *really* needed. There where great logos, just pick some, gather together and decide on one. - a site web ready to present to poeple we have a website which reflects the state of the project (as in heavy work in progress). Want to improve it? help then. - a first clear schedule or plan Working on it, a schedule is currently not done and will not be done (hey we are volunteers, we don't want to get any schedule pressure or make promises i cant hold) My plan is to bring up a Videoplayer next, which is a single app which can play many videos in parallel. And then scrub through this videos while the others are playing. This is still some far goal but something I aim for first. That will help in improving the backend code and act as proof of concept whats doable. That mockup will certainly NOT available in may. Quite much to do for that. Christian purpose of the participation : looking for other developpers. site web == http://www.libregraphicsmeeting.org/2008/index.php?lang=enaction=home Roland (wildhostile) ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cinelerra doesn't understand Xinerama well, or at all.
Herman Robak wrote: Recently I tried out Xinerama on my Opteron workhorse. Moving windows between screens was fun, but Cinelerra had focus issues and other annoyances. In particular, if I had placed the Compositor in the second screen, the pressed f to maximise it to fullscreen mode, it would always go fullscreen in the first screen. Not only that, but the fullscreen overlay would have the resolution of the second screen. Cinelerra seems blissfully unaware of Xinerama, and fails completely to Do The Right Things in Xinerama. Any brilliant ideas? Cinelerra works fine with 'normal' dual head setup and not xinerama. That is, one Xserver driving 2 (or more) independent displays. Advantages disadvantages: + Displays can have very diffrent resolutions/color depths + Almost all window managers handle it right - You cant move windows between the screens - Windows can't span screens Configured is it somewhat like following (xorg.conf): Section ServerLayout Identifier Default Layout Screen 0 Screen0 0 0 Screen 1 Screen1 RightOf Screen0 InputDeviceGeneric Keyboard InputDeviceConfigured Mouse EndSection Section ServerFlags Option Xinerama 0 EndSection Section Monitor Identifier Monitor0 VendorName Unknown ModelName Iiyama PLB2403WS HorizSync 30.0 - 83.0 VertRefresh 56.0 - 76.0 EndSection Section Monitor Identifier Monitor1 VendorName Unknown ModelName IQT L19T HorizSync 31.0 - 79.0 VertRefresh 56.0 - 75.0 EndSection Section Device Identifier Videocard0 Driver nvidia VendorName NVIDIA Corporation BoardName GeForce 7300 GS BusID PCI:2:0:0 Screen 0 EndSection Section Device Identifier Videocard1 Driver nvidia VendorName NVIDIA Corporation BoardName GeForce 7300 GS BusID PCI:2:0:0 Screen 1 EndSection Section Screen Identifier Screen0 Device Videocard0 MonitorMonitor0 DefaultDepth24 Option TwinView 0 Option metamodes DFP: 1920x1200 +0+0 EndSection Section Screen Identifier Screen1 Device Videocard1 MonitorMonitor1 DefaultDepth24 Option TwinView 0 Option metamodes CRT: nvidia-auto-select +0+0 EndSection Note that I used the the nvidia tool to set this up, but should be doable manually with other cards as well. After that you go to cinelerras preferences and change Display for Compositor to :0.1 .. that is server 0, screen 1, restart cin and it should work. Alternatively it might be possible to start 2 xservers, but likely a waste of resources and not much easier to setup. Then you enter Display for Compositor to :1 in cinelerras preferences. Btw anyone have a modeline to drive a 2nd screen in PAL mode? that would be interesting for Fullscreen editing ... or even make a 3rd screen which is then the 'S-Video' output of the graphic card driven in PAL. That should give exact video preview \o/. Christian --Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Cinelerra doesn't understand Xinerama well, or at all.
Kurt Georg Hooss wrote: thanks for replying, though i am not sure wether i understand... what you write would mean i use xinerama (one big virtual screen)... but the device configuration options offered by nvidia-settings are: 1. Disabled, 2. Separate X screen (requires X restart), thats dualhead in nvidia-speak 3. Twinscreen (this is what I choose for working in cinelerra). thats xinerama in nvidia-speak any dualhead option does not seem available, maybe you have an ati card? with different terminology? or how else do you configure your setup? directly in xorg.conf? I used the x11/xfree/xorg terminology Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: Lumiera Engine
Burkhard Plaum wrote: Hi, Ichthyostega schrieb: But, /assumed you do have theses capabilities/, the goal is to write code able to deal with organizing all those video frames efficiently -- and this is what the video player test app is aiming at. Roland schrieb: What do you mean by efficiently? getting the right frame out to the right output, without stepping on your own feet ;-) detecting when you can take shortcuts and save cpu cycles whithout messing anyting up... A zero-order chortcut is to get frames mostly sequentially out of the decoder. When scrubbing, this means to cache at frames at GOP-level. No matter what future codecs will be like (with more weird possible inter-frame dependencies than H.264) they will all be optimized for sequential decoding, since that's the normal case :) Quite sure, but the question is when caching frames is cheaper than re-decoding them. My guess (which has to be profiled) is that in many cases the first frame (keyframe) of a GOP is the most easy to decode frame anyways. Things would become more interesting when it is possible to cache the state of the decoder for each GOP, incrementally. For common codecs that would quite likely bring some performance benefit, but is also the thing which is most intrusive to the codec and cant applied easily (if even). Another thing with the frame-accurate-seek API you introduced in avdecoder, I didn't looked closely on the code yet, but you write indices on disk. Would it be possible to add hooks for the index access (like in_memory) instead, so that an application can manage the indices on its own? Christian Burkhard ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] dual head gama correction
E Chalaron wrote: Hi all Hope I am not off topic here but Does anybody know if there is a mode with Nvidia that allows to have different gama correction for each screen. With dual view it seems you can do a lot, but not sure about independant tuning for each screen. That of course from the same graphic card. Works for me from the nvidia-settings program, xgamma should be able to do that too. But beware, we have very diffrent monitors here (diffrent TFT technologies, manufacturer). It is almost impossible to adjust them manually (don't even call it callibrate) to display vaguely similar colors, have fun trying when you have a similar setup. Chrisitan Cheers E ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] [Announce] Lumiera Developers meeting
Hi folks, our next Developer meeting is scheduled on Thursday the 8. May 2008 at 21:00 UTC The meeting will be held on irc.freenode.net in #lumiera The agenda for this meeting is at http://www.pipapo.org/pipawiki/Lumiera/MonthlyMeetings No much Topics so far, please add some. Anyways if not, we might to complete the meeting in time (less than 2 hrs). Some points: * Joel made an initial gui mockup * I would like if someone outside of the core devs picks up the website infrastructure (programming, design, content) * There are some drafts on http://www.pipapo.org/pipawiki/Lumiera/DesignProcess When anyone has more ideas to be talked about, please add them to the Wiki. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Introduction of myself
Serge GIELKENS wrote: Hi everyone, I have been following the Cinelerra3/Lumiera project for a few months now to get an idea of where it would go. It all seems very serious and help is appreciated, also from beginners. I am an absolute beginner. Never have I participated in an open source project. Neither have I real experience in video editing. I just play a bit with Cinelerra. One might wonder what I am doing here ;-) Although I have been working as a programmer by profession, it won't be of any use: I made Cobol applications for the IBM mainframe. I have no experience in C, C++, etc. Once in a while I do compile Linux programs myself though, so my experience in testing might be useful. I could also help in documentation, something which I find essential and which, IMHO, can make or break a project. I understand this is not of importance right now because Lumiera is in a very early stage of development. I just thought it would be nice to make clear to the project team what help can be expected. In the mean time I will keep a close eye on the development of Lumiera. Thanks for your interest! We currently need some helpers for infrastructure things, bash/website scripting and thereof. This doesn't need someone who is deeply involved with C/C++ system programming and help in this area is really needed and greatly welcome since it frees the resources of the core developers to work on Lumiera itself. The idea for Lumiera development is that anyone can contribute a tiny bit what he knows best about. If you or anyone else is interested in contributing please take a look at http://git.pipapo.org/uWiki.html for the proposed system, and contact me or anyone else in #lumiera at irc.freenode.org. Greetings Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] thumbnail based renderless editor
I've added following to our GuiBrainstorming page: -- Sparse Timeline Make the timeline view 'sparse', that means the time on top is not continious anymore but 'boring' sequences get ommited and 'interesting' sequences get displayed, probably even stretched to cover at least a single thumbnail. This needs an ui (menu or whatever) to turn this feature on and some selection which events the user is interested in (scene cuts, transistions begin/end/mids, keyframes (begin/mid), labels, ...) --- is that somewhere in the area what you mean? Making something 'renderless' in Lumiera is quite pointless, Lumiera will render previews on demand. If there is no demand then nothing gets rendered, preview redners are also proxy/quality crippled to try to preserve fast response. When you close any viewer then you have no render (well in background it might prepare a few frames, but you dont have to care) Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Some ideas for Lumiera... (was) PiTiVi Has some ideas
I also think that video processing tasks should be run in a separate process from the gui so that they can't cause it to crash if they crash themselves. No, No, No! That would be completely misguided, IMHO. We should never bend the architecture in order to isolate against possible crashes. The application must not crash, period. We should never tolerate possible crashes. That's the broken window theory, you know. Besides that, there may be arguments in favour of running the GUI in a separate process, e.g. to have the core and backend running on a dedicated video processing machine somewhere in the network. But there is also a massive drawback with this approach: having multiple processes means you need Inter Process Communication, which is costly both in terms of execution and development resources. When a program or just a part of it crashes, then it doesn't fulfil the job which was requested, for the user experience both are equally bad. Isolating things into subprocesses won't fix this and costs a lot more work and performance. The real problem with a crash is that the user might loose unsaved work. Lumiera *might* crash sometimes because of programming bugs (we are not perfect, but we aim to be) or by problems out of our reach, buggy codecs, power failures and so on. We have to ensure that the user *never ever* looses any work by a unintended programm termination, point. The plan is to make it bullet proof against data loss by saving project data in a database like dump+log like fashion. This gurantees recoverability even better than the current 'Load Backup' feature of cinelerra which is already a cool thing. As side effect the user gets almost unlimited selective undo too. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Lumiera Donations Questions
Some Months ago when someone offered to donate some RAM, I answered that I have sufficient hardware for myself. Now it it struck me and my laptop got broken a few weeks ago, this is quite depressing for me since I relied on working on the laptop alot and have problems to finance a new one soon. It is somewhat frustrating that working on free software like Lumiera doesn't generate a little revenue to compensate some simple (*cough*) needs. My intention now is to check out if this is really true or if some people are out there who are willing to donate money or hardware to the project. Even when Lumiera has nothing end-user useable yet, we already worked countless hours on managing the project, solid design groundwork, setting up the server, supporting people in tools we use, coding base libraries, a gui mockup, system interfaces and so on (ohloh.net lists Lumiera Project Cost already as $457,818, which admittedly is a gross overestimate, but still...). This let me come to the Idea to Just Ask!, maybe some Institutions, Companies or private Persons have faith in the Project and would like to help. So the Questions are: 1. Would it be viable when developers (or otherwise involved people) just speak up when they have some struggle to get some hardware (or even more essential needs!) financed? 2. Is there anyone out there who would give donations? There are some important shortcomings: * It is very important that the other involved people should agree on this. Everyone should have a good feeling that the reciever deserves the donation. * This results in that it should be transparent (I would set up an website for this, donors might be pseudonymized on prefer). * We are a loose crowd of people, not some kind of Organization, donations have to be arranged on a personal base, either by some kind of contract or as private gifts. A donor won't get any tax benefit. Comments? Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
