Re: [CinCVS] Req: Cinelerra plugin architecture
It would be nice to have a common plugin interface that could work across Cinelerra, Blender, Kino etc etc, so that the work of writing plugins could be decoupled. On 08/08/07, mark carter <[EMAIL PROTECTED]> wrote: > > On Tue, 2007-08-07 at 18:26 +0200, Jonas Wulff wrote: > > > Unfourtunately every major change of the codebase makes it harder to > > re-merge with the 'official' cinelerra version. That of course leads to > > the questions how important that *really* is, considering that cinCV > > seems to be the version more commonly used... > > Look at it this way ... if you're not prepared for the code to divide, > then what's the point of having a fork? Forks are bad, m'kay. > > I would argue that everyone's interest would be best served if one were > to be subordinate to the other. Is HV happy to incorporate all of CVs > patches into his code? Or, would HV be happy to submit patches to CV, > and use CV? If he thought the quality of development of CV sufficiently > high, then he would in effect be doing himself a favour - because he can > submit patches, and let everyone else take care of the problem of > integration. This business of forking is creating a lot of unnecessary > work for everyone. > > > ___ > Cinelerra mailing list > Cinelerra@skolelinux.no > https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra > -- Regards, Martin ([EMAIL PROTECTED]) IT: http://methodsupport.com Personal: http://thereisnoend.org
Re: [CinCVS] Open Movie Editor
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. Evan then "Load From Backup" has saved me every single time. Open Movie has come a long way in a short period of time. Daniel On 8/7/07, David McNab <[EMAIL PROTECTED]> wrote: > > On Tue, 2007-08-07 at 19:42 +0100, mark carter wrote: > > I'm new to Cinelerra - and yeah, it is difficult to learn. What doesn't > > help it is its instability. > > Ahhh, but you forget cin's Major Saving Grace: 'Load From Backup' :) > > Cheers > David > > > > > ___ > Cinelerra mailing list > Cinelerra@skolelinux.no > https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra >
[CinCVS] motion interpolation software
Hi, Can anyone recommend any software for linux which can do reasonable detection/interpolation of motion to help bring low framerate video up to speed? Cheers David ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] [Bug 442] New: title plugin: keyframe automation doesn't work with color settings
http://bugs.cinelerra.org/show_bug.cgi?id=442 Summary: title plugin: keyframe automation doesn't work with color settings Product: Cinelerra Version: 2.1 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: Effects/Transitions AssignedTo: cinelerra@skolelinux.no ReportedBy: [EMAIL PROTECTED] I have a title sequence where I wanted the colours to shimmer over time. With auto-keyframes on, I adjusted the title colours at different points along the span of the effect. Upon render, the title text dropped out in several places, and returned in the original colour. Reproducible: Always Steps to Reproduce: 1. Create a title effect, and set a starting color 2. Turn on auto-keyframes 3. At different points along the effect's span on the timeline, change the title's text color 4. Render the video 5. Observe Actual Results: Title text flickers on and off, never changing color Expected Results: RGB color settings for title text should have shifted incrementally and automatically between keyframes -- Configure bugmail: http://bugs.cinelerra.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Some development work I'd like to do
I'd like to do some development work on Cinelerra. But I'd kind of like to know that my work wont just lie around unpatched if I do it. So cehteh's comments are particularly apropos here. What I propose to start off with are the check_sig() functions in each file loader. Nice and easy to begin with! I noticed that each one takes in class Asset, whereas what it could really do with is an open file handle. I'd also like to strip it out of its class, and turn it into a function. Why? Well, because it would made the function vectorisable. That will simplify the calling code to a loop. My "grand vision" is that eventually all these classes will be stripped of their classhood, making the whole thing vectorisable. The eventual payoff for this is that one can obtain an index for a matching signature. No more masses of switches, just an index lookup. That goal would be some way away, though. check_sig() is my immediate goal. Now, what you'll get out of it at this stage is no new functionality. But you will get cleaner code. And less of it. Just my little contribution to the development process. Is there an interest in me doing it? ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra productions: reply to Raffaella
Op dinsdag 07-08-2007 om 13:31 uur [tijdzone -0400], schreef Roland: > Hi all, > > There are a lot of blogs and sites web on video under GNU/Linux station > and some on Cinelerra on the web. A blog on Cinelerra with a link on the > "official unofficial version site web" would distinguish it from > others. As I said, I was thinking about a place to make people know > there are other users of the software (by their blogs, their > productions, their howtos, their patches on the code, or their coding of > the code). > To make something like that we have 3 solutions: > 1: A place on the server where cvs.cinelerra.org is hosted (solution I > prefer). But I don't know if it's possible. Maybe there are not enough > place. > 2: The Jeroen van de Nieuwenhof's solution (solution I like): "I can > offer hosting of a wordpress/drupal system on my webserver, no > problem". (Thanks for your offer). This solution could permit us to have > our own blog solution (adding plugin, own style of interface, own choice > of blog software, own design). This solution is a better one too if you > need to change the web host, to save and keep all contents in archives, > upgrade or changing the system easily. Jeroen can you tell us how this > would be possible? how much place could you give us? Is this a sure and > trusted option? Can you give us more details on the hosting. What is a > dedicated server in a datacenter? I rent a complete server that is located in a datacenter and i am the only one using this server. It has a fast connection (up and down) and i can decide how much room can be used for the Cinelerra blog. I think it's best to put the video on youtube like systems, so the room needed on my server is limited. When you use a content management system like Wordpress, it is pretty easy to move the complete website because the only thing you have to do is copy the files and the database. Don't worry about the space available, at the moment i have several gb's available. > 3: A free blog, (blogger.com or on other free plateform blog). I like > this solution less because of all the reasons listed in the #2. However > I agree, it is a quick and good solution to begin. > 4 (yes I know): Another solution proposed by goibhniu is to aggregates > all feeds coming from selected cinelerra's blogs. This will be a good > solution when the community become as active as the others listed on > planetplanet.com. Your other proposal to have a cinelerra's productions > channel on miro software is cool (imo), we can investigate on this. > > Hosting is just a part of the weblog creation. We need contributors (as > Valentina says) to write articles, id est some sentences (not a lot just > one or two just to present the work of another user). This is how I see > this blog. By now we could post an announce on the cvs.cinelerra.org : > "Publishers WANTED!". > > With regards, > > Roland C. > > > ___ > 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
On Tue, 2007-08-07 at 19:42 +0100, mark carter wrote: > I'm new to Cinelerra - and yeah, it is difficult to learn. What doesn't > help it is its instability. Ahhh, but you forget cin's Major Saving Grace: 'Load From Backup' :) Cheers David ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Req: Cinelerra plugin architecture
On Tue, 2007-08-07 at 18:26 +0200, Jonas Wulff wrote: > Unfourtunately every major change of the codebase makes it harder to > re-merge with the 'official' cinelerra version. That of course leads to > the questions how important that *really* is, considering that cinCV > seems to be the version more commonly used... Look at it this way ... if you're not prepared for the code to divide, then what's the point of having a fork? Forks are bad, m'kay. I would argue that everyone's interest would be best served if one were to be subordinate to the other. Is HV happy to incorporate all of CVs patches into his code? Or, would HV be happy to submit patches to CV, and use CV? If he thought the quality of development of CV sufficiently high, then he would in effect be doing himself a favour - because he can submit patches, and let everyone else take care of the problem of integration. This business of forking is creating a lot of unnecessary work for everyone. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Req: Cinelerra plugin architecture
On Tue, 2007-08-07 at 11:35 +1200, David McNab wrote: > Thoughts? Well, I've been thinking about the whole business of file loading. Although I'm completely new to Cinelerra and its development, I've had a scratch around the file loading. My basic thinking is that I think a lot of things are "too mixed in together", and a better layers of abstraction are required. It seems that the donkey-work for loading is in a function called get_frame(). get_frame() does some monkey-business with the classes VFrame and Asset. I have yet to determine what gets used in these classes. Plus, threads get in on the act, and there seems to be a special class for PNGs. Heaven alone knows why. What I would like to see is developer documentation, and a really clean interface. Separate the layer between interpreting the file and all the other bits that go on. Some of these classes have threads, which just complicates everything. It's a mess. Given a thin clean API, it would allow developers to separate out their code from the rest of Cinelerra. This would enable them to test sections separately. The whole approach holds the promise cleaner, more reliable, more compact, more reliable, and easier to program code. Debugging would be so much easier. I'm not trying to sell magic pixie dust here. I think it'd really work. A file loader, for example, shouldn't have to worry about threads. That's somebody else's problem. Also, I haven't looked at the effects plugins that you were referring to. But again, I suspect that the plugins have to know a lot about the plugin architecture. This suggests that there ought to be a layer of abstraction between them and the effects coding. That way, one could write an effect, slap on a plugin archtitecture as an afterthought, or even "not bother" (just compile it straight in with the code). A guy could test his code without worrying about what PluginServer did or didn't do. ... of course, I'm saying all this without having read any code on the plugins. I'm suggesting that cinelerra 3 is cinelerra 2 with proper layers of abstraction. On the subject of scripting, and so on ... I'm not a Forth fanboy, but I've been thinking about a Public Domain forth called atlast. It's quite famous on account of its connections with AutoCad. With forth, you have a user/developer scripting language, configuration language, and even dynamic glue. Pretty good really. Another thought that springs to mind is if there could be some co-operation between the non-linear video editors. You know, Kino is writing its own effects, and file loaders, Open Movie editor is writing its own effect, file loaders, and so on, Cinelerra is writing is own ... you get the idea. Seems like an awful lot of similar things going on, all that duplication of effort. Those are my thoughts, anyway. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Open Movie Editor
On Tue, 2007-08-07 at 11:15 +1200, David McNab wrote: > On the positive side, the developer's use of FLTK for the GUI is wise, > he has a very fast responsive interface. Also, having everything on one > window is nice. His window layout is very good. I have yet to test it out, but from what I've seen, it seems quite impressive that one guy could come what appears to be quite a long way in a short space of time. Cinelerra appears to have been around for donkeys years, and is still damn unstable. > On the negative side, it's not a patch on Cinelerra feature-wise. > Sure, it's easier to learn, but one would get frustrated pretty fast. I'm new to Cinelerra - and yeah, it is difficult to learn. What doesn't help it is its instability. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Cinelerra productions: reply to Raffaella
Hi all, There are a lot of blogs and sites web on video under GNU/Linux station and some on Cinelerra on the web. A blog on Cinelerra with a link on the "official unofficial version site web" would distinguish it from others. As I said, I was thinking about a place to make people know there are other users of the software (by their blogs, their productions, their howtos, their patches on the code, or their coding of the code). To make something like that we have 3 solutions: 1: A place on the server where cvs.cinelerra.org is hosted (solution I prefer). But I don't know if it's possible. Maybe there are not enough place. 2: The Jeroen van de Nieuwenhof's solution (solution I like): "I can offer hosting of a wordpress/drupal system on my webserver, no problem". (Thanks for your offer). This solution could permit us to have our own blog solution (adding plugin, own style of interface, own choice of blog software, own design). This solution is a better one too if you need to change the web host, to save and keep all contents in archives, upgrade or changing the system easily. Jeroen can you tell us how this would be possible? how much place could you give us? Is this a sure and trusted option? Can you give us more details on the hosting. What is a dedicated server in a datacenter? 3: A free blog, (blogger.com or on other free plateform blog). I like this solution less because of all the reasons listed in the #2. However I agree, it is a quick and good solution to begin. 4 (yes I know): Another solution proposed by goibhniu is to aggregates all feeds coming from selected cinelerra's blogs. This will be a good solution when the community become as active as the others listed on planetplanet.com. Your other proposal to have a cinelerra's productions channel on miro software is cool (imo), we can investigate on this. Hosting is just a part of the weblog creation. We need contributors (as Valentina says) to write articles, id est some sentences (not a lot just one or two just to present the work of another user). This is how I see this blog. By now we could post an announce on the cvs.cinelerra.org : "Publishers WANTED!". With regards, Roland C. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Req: Cinelerra plugin architecture
Yes, it is a good idea and it would be a good thing to have... If you take a look at the archives, you'll also see that extending the plugin capabilities has been requested several times before. But from what I've understood, that would require major changes in cinelerra itself, so nobody's willing to work on that.. Maybe you are? ;) Unfourtunately every major change of the codebase makes it harder to re-merge with the 'official' cinelerra version. That of course leads to the questions how important that *really* is, considering that cinCV seems to be the version more commonly used... And I get the impression that e.g. opengl wasn't that much of a 'killer feature' (not wanting to step on anyone's toes, though...). Just some thoughts... Jonas On Tue, 7 Aug 2007 11:41:54 -0400 "Aaron Newcomb" <[EMAIL PROTECTED]> wrote: > I agree that this is a great idea. Well thought out, too. I only wish > I was a code monkey. > > On 8/6/07, David McNab <[EMAIL PROTECTED]> wrote: > > Hi, > > > > My mind has often turned to the subject of plugins for Cinelerra, > > and how to make this a true killer feature. > > > > I'd like to suggest a change to the plugin architecture - allow > > dynamically loaded plugins, compiled separately from Cinelerra. > > > > I notice that part of Cin's installation is a directory > > $PREFIX/lib/cinelerra, which contains shared libs for the plugins. > > > > What would be great is if Cin could also look in > > ~/.cinelerra/plugins, where this directory has a bunch of > > subdirectories, one per plugin. Each subdirectory would contain the > > shared libs, plus any data files and other stuff needed by the > > plugin. > > > > Also, to have a Cinelerra SDK, which contains: > > - a template video plugin and a temporary audio plugin; each of > > these would be a directory containing autocrap files and > > heavily-commented source code; each of these plugin directories > > could also contain: > > - a README file which explains how to tweak the autocraps to > > add any required dependencies etc > > - the generated Makefile could have targets 'install' (which > >requires root, and installs to $PREFIX/lib/cinelerra), and > >'install-user', which installs to ~/.cinelerra/plugins > > - full documentation on the plugin API - all classes, methods, > >attributes etc - maybe Doxygen-generated > > - the ability for plugins to be compiled separately from the main > >Cinelerra source tree, and linked against a Cinelerra shared lib; > > > > IMHO, this would strongly support and encourage more Cinelerra > > plugin development. > > > > What would also be great is a way to have a plugin architecture > > which allows the ability to operate on Cinelerra as a whole, rather > > than within specific audio/video tracks. > > > > Such an architecture would allow plugins to be written to provide > > scripting interfaces, remote control interfaces via sockets etc. > > Within such an environment, a 'super-plugin' could see an API which > > allows access to every aspect of Cinelerra through a set of > > objects, including: > > > > - querying the timeline - finding out what tracks there are, what > >effects/automations are applied to these tracks etc > > - importing clips > > - operating on tracks > > - doing renders > > - etc > > > > Thoughts? > > > > Cheers > > David > > > > > > > > > > ___ > > 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] Req: Cinelerra plugin architecture
I agree that this is a great idea. Well thought out, too. I only wish I was a code monkey. On 8/6/07, David McNab <[EMAIL PROTECTED]> wrote: > Hi, > > My mind has often turned to the subject of plugins for Cinelerra, and > how to make this a true killer feature. > > I'd like to suggest a change to the plugin architecture - allow > dynamically loaded plugins, compiled separately from Cinelerra. > > I notice that part of Cin's installation is a directory > $PREFIX/lib/cinelerra, which contains shared libs for the plugins. > > What would be great is if Cin could also look in ~/.cinelerra/plugins, > where this directory has a bunch of subdirectories, one per plugin. Each > subdirectory would contain the shared libs, plus any data files and > other stuff needed by the plugin. > > Also, to have a Cinelerra SDK, which contains: > - a template video plugin and a temporary audio plugin; each of these >would be a directory containing autocrap files and heavily-commented >source code; each of these plugin directories could also contain: > - a README file which explains how to tweak the autocraps to add >any required dependencies etc > - the generated Makefile could have targets 'install' (which >requires root, and installs to $PREFIX/lib/cinelerra), and >'install-user', which installs to ~/.cinelerra/plugins > - full documentation on the plugin API - all classes, methods, >attributes etc - maybe Doxygen-generated > - the ability for plugins to be compiled separately from the main >Cinelerra source tree, and linked against a Cinelerra shared lib; > > IMHO, this would strongly support and encourage more Cinelerra plugin > development. > > What would also be great is a way to have a plugin architecture which > allows the ability to operate on Cinelerra as a whole, rather than > within specific audio/video tracks. > > Such an architecture would allow plugins to be written to provide > scripting interfaces, remote control interfaces via sockets etc. Within > such an environment, a 'super-plugin' could see an API which allows > access to every aspect of Cinelerra through a set of objects, including: > > - querying the timeline - finding out what tracks there are, what >effects/automations are applied to these tracks etc > - importing clips > - operating on tracks > - doing renders > - etc > > Thoughts? > > Cheers > David > > > > > ___ > Cinelerra mailing list > Cinelerra@skolelinux.no > https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra > -- Thanks, Aaron Newcomb http://www.thesourceshow.org http://www.opennewsshow.org ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] [Bug 441] Req: Display a throbber when thrashing the CPU
http://bugs.cinelerra.org/show_bug.cgi?id=441 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Display throbber when |Req: Display a throbber when |thrashing the CPU |thrashing the CPU -- Configure bugmail: http://bugs.cinelerra.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] [Bug 441] New: Display throbber when thrashing the CPU
http://bugs.cinelerra.org/show_bug.cgi?id=441 Summary: Display throbber when thrashing the CPU Product: Cinelerra Version: 2.1 Platform: PC OS/Version: Linux Status: NEW Severity: trivial Priority: Medium Component: User Interface AssignedTo: cinelerra@skolelinux.no ReportedBy: [EMAIL PROTECTED] Often, the Cin UI becomes unresponsive when I do things like change project parameters, add/move clips and tracks etc. I gather this is because quite often these operations demand a lot of calculation. But IMHO it would be good if Cin had a small 'throbber' widget at the top right of the button bar, to indicate Cin is currently doing stuff. Reproducible: Always Steps to Reproduce: N/A -- Configure bugmail: http://bugs.cinelerra.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
