Re: [CinCVS] Cinelerra documentation

[Christian Thaeter]

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=AttachFile&do=get&target=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

[Christian Thaeter]

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

Re: [CinCVS] Cinelerra documentation

[Christian Thaeter]

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=AttachFile&do=get&target=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

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

[CinCVS] AUTHORS file in svn

[Christian Thaeter]

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

[Christian Thaeter]

Johannes Sixt wrote:
> On Wednesday 27 December 2006 16:38, Christian Thaeter wrote:
>> 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.
> 
> I'm not sure that this is the best thing to do. The authors file that you 
> need 
> can only list the authors with svn access and must conform to a very strict 
> syntax, but OTOH there is at least also HV to be mentioned in AUTHORS plus 
> possibly a lot of other people who have contributed patches.
> 
Yes, the Syntax needs to be conform what git wants, while the GNU coding
standards mandate another syntax. Currently the AUTHORS file is empty
which has no use for either git nor gnu coding standards. So far I dont
know any other tool which parses the AUTHORS file which is in moderate
frequent use (correct me if I am wrong). So having a readable but
slightly unexpected syntax is not problematic.

The authors file I need has to contain at least all svn committers, but
there is in no way a restriction to to add more than that. I would
strongly opt for honor anyone ever worked on cinelerra there, also from
the HV/upstream list.

I think this would be far better than the current no-solution, maybe not
perfect but I see absolutely no harm with it.

Finally, this thing isn't really worth much discusion. I can keep the
'authors' file and fix it whenever someone new appears as committer.

Christian


___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] AUTHORS file in svn

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

[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

[Christian Thaeter]

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.

[Christian Thaeter]

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_ptr these should be fixed on expanse of
some performance.

Manage Assets in std::vector /
std::list.

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.

[Christian Thaeter]

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

[Christian Thaeter]

> 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_ptr these should be fixed on expanse of
> some performance.
> 
> Manage Assets in std::vector /
> std::list.

First things done:
 http://www.pipapo.org/gitweb?p=cinelerra/ct;a=shortlog;h=ct
you might pull it with git
 git clone git://git.pipapo.org/git/cinelerra/ct
or
 git clone git://repo.or.cz/cinelerra_cv/ct.git

Valgrind so far was quite pleased with it, but I didn't do a in-depth
check yet, some things still use the original Garbage collector and I
want to remove them too.

Note that I didn't yet hacked the configure.ac to check for boost.

I also plan to add my debugging library
 http://www.pipapo.org/pipawiki/NoBug
to make things a little more safe.

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]

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]

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.

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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] printf

[Christian Thaeter]

Leigh Wanstead wrote:
> Hello everyone,
> 
> I read the source code and see lots of printf statement. I build cinelerra
> normal. While I run it. I can't see these printf statement output in
> console. May I ask how can I see these printf statement?

Many of them are commented out or only present in some special code
paths, they where added by the developers to aid debugging. Double check
them.

Christian


PS: I am slowly transisting cinelerra to use my debugging library
(http://www.pipapo.org/pipawiki/NoBug) instead of printf's in my branch.
If you are interested, ask me, maybe visit us on irc.freenode.net.

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] where's the manual?

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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 time&date 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

[Christian Thaeter]

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

[Christian Thaeter]

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]
>> > 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]

[Christian Thaeter]

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

[Christian Thaeter]

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]

[Christian Thaeter]

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

[Christian Thaeter]

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 419] New: Stop/pause button do not stop sliders and time counter, impossible to do a pause

[Christian Thaeter]

[EMAIL PROTECTED] wrote:
> http://bugs.cinelerra.org/show_bug.cgi?id=419
> 
>Summary: Stop/pause button do not stop sliders and time counter,
> impossible to do a pause
>Product: Cinelerra
>Version: 2.1
>   Platform: PC
> OS/Version: Linux
> Status: NEW
>   Severity: major
>   Priority: Medium
>  Component: User Interface
> AssignedTo: cinelerra@skolelinux.no
> ReportedBy: [EMAIL PROTECTED]
> 
> 
> Hello,
> when I try to pause a video/stop a video the clock coninue to run and it is
> impossible to continue to use preview or compositor window.
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. Create Project
> 2. Add video as new resouce
> 3. drag it to preview windows
> 4. Press play
> 5. Press play button or stop button.
> 
> 
> Actual Results:  
> video stops but silder/time are run imposible to controle it

You use alsa audio?
tick the '[x] Playback locks up' checkmark in the preferences window

> 
> 
> System: Debian Etch 4.0 64bit.
> Tested on prepackages versions of Cinelerra from
>   http://cv.cinelerra.org/getting_cinelerra.php#apt-AMD64
> Same result to latest svn r1009
> 
> 


___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] [Bug 421] New: "About" Dialog?

[Christian Thaeter]

[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

[Christian Thaeter]

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

[Christian Thaeter]

[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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

Kurt Georg Hooss wrote:
> for reference colors and interlacing, i wonder if it is possible
> to have the composition shown on an additional external tv monitor?
> e.g. connected to the graphics card's s-video output?
In preferences, you can enter another X display for the compositor
so basically you configure dualscreen in your xserver somehow (not
xinerama) where the 2nd screen has PAL properties and then address it
with :0.1 or whatever it is configured.

> 
> i have played around a little with nvidia's x server settings
> and could manage to configure the tv to twin-view,
> however it shows only greyscale.
> 
> the resolution could not be set to 720x576,
> and a large portion of the virtual desktop
> "below" the tv screen cannot be displayed at all...
> 
> so i wonder if it's possible to connect/configure the tv another way?
> like, to the 1394 output? anyone experienced?
> georg
> 
> 
> 
> 
> 
> 


___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] reference monitor

[Christian Thaeter]

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  in the compositor

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] reference monitor

[Christian Thaeter]

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

[Christian Thaeter]

mailinglist broken?

___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

[CinCVS] testmail, ignore this

[Christian Thaeter]

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

[Christian Thaeter]

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.
This mailinglist is a good place to announce them.
Some time ago I made a public pushable git repository for exactly such
things.

see:
 http://e.kevb.net/lurker/message/20070605.071123.56713cc5.en.html.

If you like the idea, you can just push them there, this would assure
that they don't get lost. When you don't want to use git, send me a
note, then I'll push them there.

Christian

> 
> 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] How to submit patch into CV

[Christian Thaeter]

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

[Christian Thaeter]

[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] Cant find motion filter!

[Christian Thaeter]

tiziano monti wrote:
> Hi, I'm italian boy, I'm excuse myself for the english.
> I'm using debian lenny (64bit) on AMD athlon 64 bit machine. I try to
> install cinelerra from repository, but I can't find the "motion" effect
> for the motion tracking.
> 
> I try to install form source but I obtain:
> 
> make[2]: Entering directory `/home/tiziano/hvirtual/mpeg2enc'
> /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/tiziano/hvirtual/mpeg2enc'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/tiziano/hvirtual'
> make: *** [all] Error 2
> 
> I want test motion tracking, but I can't! 
> Anyone help me? Thanks.

try to ./configure --disable-mmx


> 
> 
> 
> ___
> 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] Open Movie Editor

[Christian Thaeter]

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

[Christian Thaeter]

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?

[Christian Thaeter]

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?

[Christian Thaeter]

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?

[Christian Thaeter]

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?

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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] A vision of Cinelerra v3 (hopefully)

[Christian Thaeter]

FYI: a very big overview:

* something like a 'libcinelerra' will be done
* we (me, ichthyo, IRC people) decided to do cinelerra3 language
agnostic, which means the interfaces between modules will be in C style
and thus useable from other languages too, the essential components will
be developed in C/C++. Keep in mind that essential components have to be
maintainable by a broad number of people, but when someone want's to
hack a haskell or whatever esoteric language plugin, have fun with it.
* Coarse design overview:
** so far we planning 3 main components:
 1) A library which provides common functionality
 2) A Backend which provides dumb but efficent file caching and
scheduling of tasks (and some more)
 3) A Processing layer which builds the renderpipe from EDLs.
** The renderpipe is rather an arbitary graph, everything becomes a node
in this graph, even encoders/decoders, tracks are just containers which
manage such nodes.
** Compositor windows can be attached to any point in this graph
** The whole thing is 'pull-based', which means when something like a
compositor or a file render job requires a frame, this request is passed
to the system and initiates all necessary actions to provide this frame.

Many things which are currently separate entities will become unified
under this all-is-a-node hood. This will have some impacts on a high
level interface like David suggested (we don't want to loose
possibilities, just to make the interface simple, don't we?).

What I wanted to say: In general such a interface will be done (we will
already need it for our testsuites), but it might need to look diffrent
from this proposal.

After all we decided *not* to use this Mailinglist for design
discussions but private mails and git repositories (there is a
tiddlywiki inside the git), not because we want to work in secret, but
because the ML is too time intensive, people just make suggestions
without knowing whats already there.

Take this mail as invitation to look at the git repositories and design
documents and partipicate where you would like to do.

Christian


David McNab wrote:
> Hi,
> 
> Just following up on some discussion on IRC about CinV3 options, here's
> a hypothetical example based on the concept of 'libcinelerra', the main
> video editing engine, on top of which any gui is very thin and very
> cleanly separated.
> 
> Cheers
> David
> 
> 
> 
>  $ gcc -c myprog.c
>  $ gcc -o myprog myprog.c -lcinelerra
>  $ cat myprog.c
> 
>  /*
>   * myprog.c - sample Cinelerra client app for converting an arbitrary
>   * video to .mov format, and de-noising the video along the way
>   */
> 
>  #include 
>  #include 
>  #include 
>  #include 
> 
>  int main(int argc, char *argv[])
>  {
>  CinProject *cin;
>  CinTimeline *timeline;
>  CinVideoTrack *vidTrk;
>  CinStereoAudioTrack *audTrk;
>  CinClip *videoIn;
>  CinPlugin *denoiser;
>  CinRenderConfig *render;
>  int err;
> 
>  // get a cin project
>  if ((cin = cinProjectCreate()) == NULL) {
>  fprintf(stderr, "Failed to create cinelerra project\n");
>  exit(1);
>  }
> 
>  // set it up for standard PAL
>  cinProjectSetProperty(CIN_FORMAT, CIN_FMT_PAL);
> 
>  // create tracks which inherit properties from project
>  vidTrk = cinProjectAppendVideoTrack(cin, "myvideo");
>  audTrk = cinProjectAppendAudioTrack(cin, "myaudio", 2);
> 
>  // load video to convert
>  if ((videoIn = cinProjectLoadResource(cin, argv[1])) == NULL) {
>  fprintf(stderr, "Failed to load video %s\n", argv[1]);
>  exit(1);
>  }
> 
>  // place video on timeline, 1.0 seconds from start
>  cinTimelineAddClip(cin->timeline, videoIn, vidTrk, audTrk, 1.0);
> 
>  // add video denoiser effect
>  if ((denoiser = cinTrackAppendPlugin(vidTrk,"vdenoise")) == NULL) {
>  fprintf(stderr, "Failed to load video denoiser\n");   
>  exit(1);
>  }
> 
>  // and set it so it spans the entire video clip
>  cinPluginSetProperty(denoiser, CIN_PLUGIN_START, vidTrk->begin);
>  cinPluginSetProperyt(denoiser, CIN_PLUGIN_END, vidTrk->end);
> 
>  // set up render command structure
>  render.file = "out.mov";
>  render.container = CIN_CONTAINER_MOV;
>  render.vcodec = CIN_VCODEC_MPEG4;
>  render.fps = 25;
>  render.vbw = 2000; // kbits/sec
>  render.acodec = CIN_ACODEC_MP3;
>  render.arate = 44100;
>  render.abw = 256; // 256kbits/sec
> 
>  // now do the render
>  if ((err = cinProjectRender(cin, &render)) != 0) {
>  fprintf(stderr, "Failed to render\n");
>  exit(1);
>  }
> 
>  // success
>  return 0;
>  }
> 
> 
> 
> 
> ___
> Cinelerra mailing list
> Cinelerra@skolelinux.no
> https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra


___
Cinelerra mailing list
Cinelerra@skolelinux.no
https:/

Re: [CinCVS] build failure AMD64 debian sid

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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!
> 


___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

[CinCVS] NVIDIA driver regressions, performance/stability problems

[Christian Thaeter]

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

[Christian Thaeter]

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.

 * Contribute to the Documentation.

 * Doing code or documentation review and constructive critics
   showing up better alternatives.

 * Caring for infrastructure, figure out what are the tasks to
   be done (Website maintenance, coding and documentation tasks,
   classify bug reports, PR, ...).

 * Working out plans how things will actually be done (concrete!).

 * Last but not least, if someone could invest some money for bounties,
   this would really raise the motivation and priority of cinelerra
   coding.


Things which don't turn me on and are a time sink:

 * Pointing out things which are bad without a clue how to make them
   better.

 * Adding more requests to the pile of things which have to be done.

 * Endless talks without productive outcome.

 * Working on things which are not really important or don't improve
   anything.


After all I am willing to help and invest considerable time for anyone
who has problems with something, like git or automake or whatever. The
point is that this time should be paid back by the one who learned by
that will actually contribute to the project. If only just writing a doc
on "How to build a theme" or improve/maintain some other Howto's (uhm I
really want our website to be a wiki).

You don't have to be a coder to help the project. Just look out what can
be done by you, every simple thing done will help. Don't say the reason
that you don't want to steal the developers time is why you don't do
anything, thats a lie, try to learn things and when you are really stuck
don't hesitate to ask, for the developers (at least for me) it is more
motivating when I don't feel alone and see that others are also working
on figuring things out (guess how developers work? they don't magically
know anything and then just wave their magic wand!).

Your contribution doesn't need to be big or fast. Just some steady and
reliable contributions even small ones are greatly welcome.


Christian



___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] What would motivate developers

[Christian Thaeter]

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

[Christian Thaeter]

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

Re: [CinCVS] What would motivate developers

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

[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

[Christian Thaeter]

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] Cinelerra tutorial consolidation project

[Christian Thaeter]

Dale Jovan Thomas wrote:
> Hey Scott and Cinelerra community,
> 
> Thanks for getting that information from Alex. I would like to ask the
> community a broader question.
> 
> I would like to spearhead a Cinelerra tutorial collection and
> restoration project. Let give you a simple outline:
> 
> 1. Collect tutorials that were lost in translation (as was the case with
> Alex's Masks Tutorial)
> 
> 2. Collect other tutorials
> 
> 3. Publish all these tutorials on one central website or place them in a
> wiki format (I do not how to do wiki's, I would need a little help)
> 
> I will pay for the site hosting and domain name of the website. I guess
> it could be something like www.cinetutorials.org
>  or something of that effect.

would be nicer and cheaper to collect them under cinelerra.org, we
already do that and hopefully soon with a better cms/wiki so that the
community can easily maintain the website. see below..

> 
> The only things I would need from the community are:
> 
> 1. Emails and contact information to tutorial creators and or
> maintaners. So that I could make document requests from them.
> 
> 2. Review and critiques of the site, for web usability and etc.
> 
> 3. Discussion and ideas.
> 
> Hopefully this repository can serve as a one stop place, to get all
> Cinelerra tutorials, it can also be set it up for folks to submit to new
> ones. I guess that is where the wiki format comes into play.
> 
> I think a site like this will be critical for the upcoming release of
> Cinelerra 3 :-).

"upcoming" is little bit overenthusiastic. But let me explain what I
plan for cinelerra3:

Cinelerra3 will be completely self-contained, we use git as distributed
revision control system, but this doesn't mean that users have to chase
different sites to gather all parts together. Actually the opposite is
true! We include the *whole* project in a repository with all needed
things, that is the sourcecode, deverlopers documentation, users
documentation, bugtracker etc. this might use the 'submodules' feature
of git later. But this still implies that a full clone of the repository
is the complete project, nothing less. I think it is very important to
work this way. This ensures that the project wont get diverted over
serveral places while still everyone can work on his own private branch
and all information is available freely to the community.

Further and before I continue on cin3 coding I am working on a wiki-like
repository browser for git (extending cgit), this will be finished soon.
You can take a (example) look at
http://www.pipapo.org/cgit?url=git://git.pipapo.org/cinelerra/mob/edit/README.BUILD

Note this is work in progress and not functional yet.

In future this might replace the cinelerra.org website altogether where
the web content is just maintained in a git as well, everything
(website, documentation, code) is wikilike editable (as mob repository;
we dont trust anyonymous commits; there will be some vandalism protection).

Why this way? First anyone can easily contribute to the project, biggier
things as usual, by checking the project out and going the common way
(proprosing changes, pushing them to mob) or just small changes like
website or documentation typo fixes or simple code fixes directly on the
web without bothering about having a local clone, learning git and all
about.

This web editable git unifies wiki and project repository approaches we
will not have syncronization problems with documentation which is kept
on some wiki and documentation which is maintained in the repository,
this is just the same. We can still use wiki markup for some things, or
go the opposite arround and use LaTeX or TeXinfo to generate the webpage
documentation, since it is all part of the project/repository people can
just do it in any desired way, no technical limits which will block anyone.


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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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, e

Re: [CinCVS] cin3

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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"

[Christian Thaeter]

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"

[Christian Thaeter]

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"

[Christian Thaeter]

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.

[Christian Thaeter]

Richard Spindler wrote:
> Hi,
> 
> I've made a little Picture about how I think the User Interface of a
> yet to be named Video Editor could be presented. There is no central
> notion of the camera/projector Model, which I think could be added
> anywhere in the Graphs as a Node with an unlimited Number of inputs.
> 
> http://propirate.net/oracle/zipfiles/UI-concepts-CineTris.png
> 
> Please tell me what you think. Automations are not yet part of the
> Mockup, but could be added. Cross Bus connections would likely not be
> represented by Arrows in a real UI, but rather the Bus would be
> adressed by Name.
> 
> The dotted Lines mean that one element expands to a different View,
> for example in a new Window.
> 
> The same goes for the rectangles with the slashed outline, they
> represent another View, and the connection from the timeline to the
> compositing nodes will be by Name, and not by arrows. Default Names
> would be "Video Track #1", etc.
> 
> cehteh, ichthyo, do you think that the backend could be used with such
> a frontend?

The tracks in a timeline represent a tree, to make it a full graph one
just needs to 'wire' signals between this tracks.

AkhiL mase some drawing some time ago:
 http://img81.imageshack.us/img81/6916/cin3proposaldrawingbn3.png

This is almost like I imagined it (see the yellow arrows) while it
certainly needs to be worked out in more details. I would like when it
is possible to wire arbitary channels (and channels are here all kinds
of framed data in the backend) to other inputs, maybe with a
conversation/effect node inbetween. (imagine a sound analyzer which can
control zoom or brightness of a video track,...)

This ui is imo far more intuitive and nearer to the current approach
then a node editor and uses screen estate much better.

Christian


___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCVS] User Interface CONCEPTS mockup.

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

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

[Christian Thaeter]

[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

[Christian Thaeter]

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

[CinCVS] Re: [Libopenvideo] Second Open Video Developer Meeting ... protocol

[Christian Thaeter]

Below follows the protocol of the Meeting. Thanks to all partipicants
and the people who organized the nameing contest!

Christian

Richard Spindler wrote:
> Hi,
> 
> The Second Open Video Developers Meeting will take place on the 6th of
> March on the #openvideo IRC channel at the freenode IRC network, the
> time is: 21:00GMT
> 
> The Open Video Developers Meeting aims to shape the future of Linux
> and Open Source Video Editing, as well as discussing the development
> of a Next Generation Linux Video Editing Software.
> 
> A basic List of Discussion Points was already drafted at the wiki,
> everyone is encouraged to contribute further topics:
> 
> http://pipapo.org/pipawiki/Cinelerra3/MonthlyMeetings
> 
> Cheers,
> and have fun,
> -Richard
> ___
> Libopenvideo mailing list
> [EMAIL PROTECTED]
> http://propirate.net/cgi-bin/mailman/listinfo/libopenvideo



Participants:

* hermanr
* cehteh
* ichthyo
* Plouj
* SimAV
* akirad
* _MMA_
* rgareus
* ddennedy
* edrz
* anewcomb
* gmerlin
* oracle2025
* gisle

Boilerplate

Organization of this meeting

* cehteh writes the protocol
* hermanr does chairman

Leftovers from last meeting

We concluded there are no leftovers

Go through Ideas and Drafts in design process

Idea: time_handling

http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess/time_handling

Point 1 is superseded by using gavl.

Points 2 and 3 are still valid.

Ichthyo asked gmerlin if there are any problems according gavl for the
points 2 (position of frames) and 3 (position for keyframes and
automation). Gmerlin acknowledges that he doesnt see any problems.

Oracle2025 brings interlacing on topic "are you aware that automations
and keyframes could/should also apply to fields?". We agree that this
must be handled "in interlacing, a frame is a pair of 2 subsequent fields".

Conclusion:

* Refactor the proposal according to the discussion and work it out,
make it draft then. Discuss about it on the next meeting

Idea: Unit tests in Python

http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess/UnitTests_Python

We have a testsuite based on cehtehs 'test.sh' which superseedes this
proposal.

Conclusion:

* Drop it.

Idea: Todo Lists

http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess/TodoLists

This Idea is in a very early state an not yet mature. Cehteh explains:
"I want something which doesn't need much human care and i want one big
'milestones' thing and a small 'mini-task' thing". Ichthyo refines this
as "Roadmap" and "Near time task list". We agree that this shall not be
too strict. There are some ideas floating, like adding this things to
the testsuite or use the wiki. Ichthyo shows how he uses the
tiddlywiki's task macro
(http://ichthyostega.de/cin3/wiki/renderengine.html#PlanningNodeCreatorTool).
He likes it but doubts its usefulness when it is used without guessing
the hours/days of work.

Conclusion:

* We use the Tiddlywiki task macro thing for now.

Draft: CCodingStyleGuide

http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess/CCodingStyleGuide

Ichthyo tells that the discussion on the wiki page made this clear now.
Cehteh explains that he uses this style with success for diffrent
projects. We make clear that this is meant for C, in C++ we use
namespaces. Overall we agree that code shall be self-documenting.

Conclusion:

* Make it final.

Draft: DevelopmentFramework

http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess/DevelopmentFramework

Cehteh explains that he will transfer this propoal to a tiddlywiki
covering compatibility guides and dependencies. We conclude that this
wiki must reflect the actual practice (NoBug, Doxygen, test.sh) despite
the proposal is not concrete yet.

A short discussion about build systems came up, we still use autotools
and scons in parallel, delaying the decision later. oracle2025 mentioned
that scons could be used for development and autotools for release. No
decision about that everyone has different opinions. But we agree that
it works as is.

Conclusion:

* Cehteh will make the proposed wiki which shall be maintained to
reflect the state and this topic will be finalized by that.

Draft: Skills Collection

http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess/SkillsCollection

This might be only useful if there are more developers working on the
project.

Conclusion:

* Leave in draft state for now.

Draft: Architecture Overview

http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess/ArchitectureOverview

Ichthyo drawn a diagram showing the planned architecture. Cehteh raises
concerns about codecs/plugins/effects in backend. After that there was
some discussion about details. Cehteh suggests to place plugins in a
extra box, gmerlin suggests that 'plugins' don't fit into the diagram,
there should be "filters", "sources",..; Followed by some more
discussion, showing that we basically agree and understand 

Re: [CinCV] Idea for logo

[Christian Thaeter]

[EMAIL PROTECTED] wrote:
> I have draw a draft logo for new lumiera a film and camera mix
> 
> to see draft go to http://project.akirad.net/lumiera/lumiera_logo.png
> 
> Do you like?
I like the general theme, film/lens, but...

Some suggestions for a logo:
 * Should be recognizeable
 * Easy to print (on posters, t-shirts, ..)
 * (thus..) use only a few full colors, no gradients, mixed colors
 * high contrast
 * make it look good on diffrent background colors
 * Don't require/expect white background
 * only vector graphic as authorative source would be acceptable
 * should scale from microscopic size (favicon) up to big posters,
   maybe handcrafted for special purpose (leave details/frames out
   for small ones)

anyways there is so much more to do before we shall care for a logo, I
am currently setting up the project server. We need people helping with
the website, coders etc...

Christian


___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Re: [CinCV] More logos for Lumiera

[Christian Thaeter]

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