Re: [CinCVS] Playback DV from Linux over firewire to VCR
On Sat, 2008-01-19 at 01:27 +0100, Stefan de Konink wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Terje J. Hanssen schreef: I wish to playback DV files from Linux to my firewire connected Sony FX7 HDV camcorder set to VCR DV/AUTO i.LINK IN mode. What is the easiest way and which steps to follow do this operation on Linux? Possibly url to a guide specifying these steps. dvconnect -s ? test-dv from the iec61883 tools [EMAIL PROTECTED] ~]# test-dv --help usage: test-dv [[-r | -t] node-id] [- | file] Use - to transmit raw DV from stdin, or supply a filename to to transmit from a raw DV file. Otherwise, capture raw DV to stdout. ala, test-dv -t 0 scott ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Playback DV from Linux over firewire to VCR
On Sat, 19 Jan 2008 01:27:41 +0100 Stefan de Konink wrote: Terje J. Hanssen schreef: I wish to playback DV files from Linux to my firewire connected Sony FX7 HDV camcorder set to VCR DV/AUTO i.LINK IN mode. What is the easiest way and which steps to follow do this operation on Linux? Possibly url to a guide specifying these steps. dvconnect -s ? I didn't find any dvconnet tool available for openSUSE 10.3 However, i fired up Kino and its Record and Export buttons worked quick and easy. That is, Kino found my firewire connected camcorder automatically, and I could - preview and record DV in Kino from my camcorder - use my camcorder as an AV/C device (play) - export DV from Kino and record it on the camcorder (the latter also with DV files on the firewire mounted HDD recorder) Kino also found my firewire connected HDD recorder automatically, but - Kino didn't get any DV (preview nor record) signal when playing DV on the HDD recorder My conclusion is that there is something wrong (bug) with the DV export over firewire from the HDD recorder. I don't think there is something wrong with its DV decoding, as a previously test showed med that the DV could be viewed using analog output. - Terje J. Hanssen ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] [Bug 305] utf-8 support
On Tue, 2008-01-15 at 21:44 +0100, [EMAIL PROTECTED] wrote: If your distribution have only UTF-8 support (like ubuntu), before you mast create language carset On italian translation work great! I'm on Ubuntu with locale en_NZ.UTF-8. On Feisty I was able to run Cin in Italian with: $ LANG=it_IT.utf8 LANGUAGE=it_IT:it cinelerra Now, on Gutsy I can't any more. Not even with: $ localedef -c -i it_IT -f ISO-8859-15 it_IT.ISO-8859-15 $ env LANG=$(echo $LANG | sed -e s/UTF-8/ISO-8859-15/g) cinelerra What am I doing wrong? Grazie Ciao Raffaella ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] SUSE packages updated (svn r1004)
the same here. on my amd64 / suse 10.3 i never got cinelerra working. i tweaked around with xorg 7.3 and in the end messed up the entire system to the degree that not even console login worked anymore. i have now formatted the suse 10.3 partition and installed ubuntu 7.10 instead (although i don't like those administration privileges by user password... otherwise it's good). thanks for the ubuntu package. it works just fine. georg Am Saturday, 19. January 2008 01:59:07 schrieb Terje J. Hanssen: Kevin Brosius wrote on Fri, 02 Mar 2007 18:07:16 -0800 New SUSE packages are available: --- SUSE 10.2 yast source: http://cin.kevb.net/cobra/suse/10.2 In testing the 10.2 package, I noticed a problem with the current packman libdv. I recommend downgrading your libdv from the 1.0.0-0.pm.1 package (at least on x86_64 where I tested) back to the openSUSE 10.2 libdv 0.104-47. This fixes a transition rendering crash. While Cinelerra from Packman did ok on my previous openSUSE 10.2, the version for openSUSE 10.3 i386 has never worked on my system. The latest cinelerra-2.1.cv1046-0.pm.1 from Packman doesn't longer freeze my desktop at startup, but it is still unuseable. The menus don't work nor respond, only the program windows can be focused. And the program cannot be quitted without a working File menu, only when started in a terminal window. An possibly upgrade to xorg-x11 v.7.3 as someone mentioned on this list, isn't actual to do before it possibly becomes available as an official update to openSUSE 10.3, which currently is based on xorg-x11-7.2-135.4. Because of this problem, I'm curious to know if you possibly have made another rpm build for openSUSE 10.3? -- Terje J. Hanssen ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra -- dr. kurt georg hooss schoepfung wandel wissenschaftliche medienberatung breite strasse 6-8, d-23617 luebeck www.schoepfung-und-wandel.de ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] [Bug 305] utf-8 support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Raffaella Traniello schreef: On Tue, 2008-01-15 at 21:44 +0100, [EMAIL PROTECTED] wrote: If your distribution have only UTF-8 support (like ubuntu), before you mast create language carset On italian translation work great! I'm on Ubuntu with locale en_NZ.UTF-8. On Feisty I was able to run Cin in Italian with: $ LANG=it_IT.utf8 LANGUAGE=it_IT:it cinelerra Now, on Gutsy I can't any more. Not even with: $ localedef -c -i it_IT -f ISO-8859-15 it_IT.ISO-8859-15 $ env LANG=$(echo $LANG | sed -e s/UTF-8/ISO-8859-15/g) cinelerra What am I doing wrong? Aren't you missing LC_ALL? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHkgvRYH1+F2Rqwn0RCrJhAJ9Xp4HezCngAvDP/8SDp/SUa/TT8gCdH0q6 kCDTn6Z1ayGoMWvKpGBE/Kg= =QL6E -END PGP SIGNATURE- ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] [Bug 305] utf-8 support
Raffaella Traniello ha scritto: On Tue, 2008-01-15 at 21:44 +0100, [EMAIL PROTECTED] wrote: If your distribution have only UTF-8 support (like ubuntu), before you mast create language carset On italian translation work great! I'm on Ubuntu with locale en_NZ.UTF-8. On Feisty I was able to run Cin in Italian with: $ LANG=it_IT.utf8 LANGUAGE=it_IT:it cinelerra Now, on Gutsy I can't any more. Not even with: $ localedef -c -i it_IT -f ISO-8859-15 it_IT.ISO-8859-15 $ env LANG=$(echo $LANG | sed -e s/UTF-8/ISO-8859-15/g) cinelerra What am I doing wrong? Grazie Ciao Raffaella Very strange, can you send me the output of env? ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] [Bug 305] utf-8 support
Raffaella Traniello ha scritto: On Tue, 2008-01-15 at 21:44 +0100, [EMAIL PROTECTED] wrote: If your distribution have only UTF-8 support (like ubuntu), before you mast create language carset On italian translation work great! I'm on Ubuntu with locale en_NZ.UTF-8. On Feisty I was able to run Cin in Italian with: $ LANG=it_IT.utf8 LANGUAGE=it_IT:it cinelerra Now, on Gutsy I can't any more. Not even with: $ localedef -c -i it_IT -f ISO-8859-15 it_IT.ISO-8859-15 $ env LANG=$(echo $LANG | sed -e s/UTF-8/ISO-8859-15/g) cinelerra What am I doing wrong? Grazie Ciao Raffaella Ops, I'm broken :) ( this is the bug fix of previuos email ) after localedef ( you need to use localedef only one time ) you can use env LANG=it_IT.ISO-8859-15 cinelerra it's all Ma figurati ;p Ciao Akirad ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Fwd: Re: I believe in cinelerra
-- Forwarded message -- From: Richard Spindler [EMAIL PROTECTED] From: Leo germani [EMAIL PROTECTED]: What Develop cinelerra as a professional free/libre video editing tool. Hi, I've read your proposal, and I do largely agree, even if I do have a different Vision about how to turn certain ideas into reality. However, I am very interested in getting together and forming some kind of Task-Force to make a Linux an even _better_ Video Editing Platform than it is today, I have a lot of ideas, and I am willing to do my share of the work. :-) Just for who I am: I am the Developer of the Open Movie Editor, which somehow puts me into a position where I compete with Cinelerra, but since this is Open Source, competition doesn't really matter. ;-) Especially because some important components in Open Movie Editor, actually originated from Cinelerra. Additionally, I am currently the maintainer of the frei0r video plugins collection, Frei0r being the video plugin specification that you mention later in your proposal.I wasn't involved in the creation of the specification and I only wrote a very small number of the available plugins. Anyways, what I believe is the following: Cinelerra is a to BIG problem to be solved by a single team. There are however a number of interesting technologies in cinelerra and in video editing in general that might be useful for communities outside of the core interest group. Therefore I think a viable way would be to break the big cinelerra problem down into a number of smaller problems, that can then be tackled by smaller teams, which can then work more efficiently. While this breaking up of the problem is vital, it is also vital IMHO that there remains a group or individual that keeps an overview about the splinter groups and keeps the big picture in mind, because there certainly is a lot of stuff happening in the linux and floss video development space, which is not very accessible and reusable for apps and devs outside of a core group. The Plan 1. Get the community together The community of developers today is very small and spread, and cinelerra has no road map. It would be nice to have an overview about WHO actually does write code for cinelerra, and who is interested in the Big Picture of cinelerra. I am for sure interested, but I mostly work outside of cinelerra, because I simple have no idea about how to get into cinelerra? 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've actually started working on a Linux Video Editing Task-List: https://init.linpro.no/pipermail/skolelinux.no/cinelerra/2007-November/012331.html Cinelerra needs a project leader, an interface designer, and more people with defined roles that should be choosen on this meeting. People who have a clue and who write code are needed. 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 very limited in its focus, BUT this makes it so easy to work with. :-) So, Anyways, I am VERY interested in making all this happen, and in being part of a core team to get things done. Everyone else who is interested is invited to get into contact with me. :-) Cheers -Richard -- Are you teaching the What and the How but without the Why and the When? ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Fwd: I believe in cinelerra
-- 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. 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. Cinelerra needs a project leader, an interface designer, and more people with defined roles that should be choosen on this meeting. 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. 2. Diagnostics Cinelerra code is not very well documented, so few people have the idea of how tuff is to deal with it. Second step is to see what must be done so we can invite more people to colaborate with the code. Documentation, refactoring, etc. It also has to work on the API so other people can write plugins and effects. In other words, lots of work that are a pain in the ass but has to be done in order to advance properly. And passion has a limit. There must be people getting money to work on that. 3. Make a plan Based on the diagnostics and on researches with users and other video editing tools, define how cinelerra will look and act in a not so distant future. With that goal in mind, make a reasonable plan to make it happen. 3. Set up a core development team No secret here. Few people dedicated to make it happen, including an interface designer. 4. Bounties The core team can offer bounties for parts of the job they choose. This will attracat more developers to the community. 5. Attract contributors Mantain a nice looking website, a wiki, tools for easy translation of the interface and of the online documentation, etc. are goos strategies to attract people to contribute. Its also important to find people to package the software for different distributions. -- leogermani.pirex.com.br leogermani.estudiolivre.org ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Fwd: I believe in cinelerra
On Sat, 2008-01-19 at 19:34 +0100, Richard Spindler wrote: -- Forwarded message -- The Plan 1. Get the community together The community of developers today is very small and spread, and cinelerra has no road map. 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. Cinelerra needs a project leader, an interface designer, and more people with defined roles that should be choosen on this meeting. 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. 2. Diagnostics Cinelerra code is not very well documented, so few people have the idea of how tuff is to deal with it. Second step is to see what must be done so we can invite more people to colaborate with the code. Documentation, refactoring, etc. It also has to work on the API so other people can write plugins and effects. In other words, lots of work that are a pain in the ass but has to be done in order to advance properly. And passion has a limit. There must be people getting money to work on that. I was with you up to that point. Money is the root of all evil. It will totally corrupt the process. If you want money go to Micro$oft and develop for them. If you don't, (and I do realise that yopu may not have been referring to yourself), then why would you assume something like this? If this is to be a true cooperative effort, then let it be a volunteer effort. 3. Make a plan Based on the diagnostics and on researches with users and other video editing tools, define how cinelerra will look and act in a not so distant future. With that goal in mind, make a reasonable plan to make it happen. To do it right people should decide what it will include and what is needed to be a serious editor 2 or 3 years down the road. (We've had plenty of suggestions, as we all know,... maybe there'll be others). Then a team must figure out how to make that happen. With that secure plan in place then implementation can start. 3. Set up a core development team No secret here. Few people dedicated to make it happen, including an interface designer. 4. Bounties The core team can offer bounties for parts of the job they choose. This will attracat more developers to the community. I disagree. 5. Attract contributors Mantain a nice looking website, a wiki, tools for easy translation of the interface and of the online documentation, etc. are goos strategies to attract people to contribute. Its also important to find people to package the software for different distributions. Fine a wiki for the developers and a web site are good ideas. Developers may come and go and getting them up to speed on the project requires documentation and possibly training. Internal communications is vital and every developer should be in almost constant contact with the group to make sure everybody's on the same project and knows what is going on. This synergistic culture is vital to such a team. It's in everybody's interest that all the other team members understand the project perfectly. Time spent bringing a new member up to speed is not wasted. A developer's bulletin board is essential. Well defined standard interfaces for code is also essential and design changes must be tracked and approved by the core development team. Things like that ensure a solid program. I could get behind a project like that. -- Regards, Fred Williams ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] SUSE packages updated (svn r1004)
On 2008-01-19 00:59, Terje J. Hanssen wrote: Kevin Brosius wrote on Fri, 02 Mar 2007 18:07:16 -0800 New SUSE packages are available: --- SUSE 10.2 yast source: http://cin.kevb.net/cobra/suse/10.2 In testing the 10.2 package, I noticed a problem with the current packman libdv. I recommend downgrading your libdv from the 1.0.0-0.pm.1 package (at least on x86_64 where I tested) back to the openSUSE 10.2 libdv 0.104-47. This fixes a transition rendering crash. While Cinelerra from Packman did ok on my previous openSUSE 10.2, the version for openSUSE 10.3 i386 has never worked on my system. The latest cinelerra-2.1.cv1046-0.pm.1 from Packman doesn't longer freeze my desktop at startup, but it is still unuseable. The menus don't work nor respond, only the program windows can be focused. And the program cannot be quitted without a working File menu, only when started in a terminal window. An possibly upgrade to xorg-x11 v.7.3 as someone mentioned on this list, isn't actual to do before it possibly becomes available as an official update to openSUSE 10.3, which currently is based on xorg-x11-7.2-135.4. Because of this problem, I'm curious to know if you possibly have made another rpm build for openSUSE 10.3? Hi Terje, I don't have a 10.3 system or build system setup yet. From these reports, it sounds like we would need both to build it and then figure out why it has problems (with newer xorg?) I'll certainly post here if I get to it. :) Sorry, -- Kevin ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Fwd: I believe in cinelerra
2008/1/19, Fred Williams [EMAIL PROTECTED]: Fine a wiki for the developers and a web site are good ideas. Developers may come and go and getting them up to speed on the project requires documentation and possibly training. Internal communications is vital and every developer should be in almost constant contact with the group to make sure everybody's on the same project and knows what is going on. This synergistic culture is vital to such a team. It's in everybody's interest that all the other team members understand the project perfectly. Time spent bringing a new member up to speed is not wasted. A developer's bulletin board is essential. Well defined standard interfaces for code is also essential and design changes must be tracked and approved by the core development team. Things like that ensure a solid program. I could get behind a project like that. Ok, so what needs to be done to get such a project rolling? The following is my opinion, and of course everyone is free to argue otherwise. ;-) When planning a project, I prefer to make an Assessment of the resources that I have available first, because I somehow like to be realistic about what really can be done instead of building castles out of air and then being disappointed that it did not work out. So, this Project seems to be about Code, programming code and such. So, while there is certainly a lot of code already out there that can be reused, someone has to fit it together and someone has to fill in the missing parts. So this project will involve coding. So we need Coders. This is how open source projects work, they need coders. There are many people with ideas, but someone has to code it and generally, those people are a scarce resource. So, in planning this stuff the first thing to find out is who are the coders, and what are they willing to do. Making big plans and then expecting outsiders to jump in and start coding is an approach that has proven not to work, at least as far as my experience goes. Maybe at one point outsiders will come and start contributing, but for that to happen, a solid core is needed, something that is of value to contributors. And btw. I also believe that making plans that reach too far into the future are very, very risky, especially if one relies on volunteers. Better make a small proposal for a well defined problem, for which a solution is immediatly useful. Then try to get it solved as fast as possible, before people loose interest, and then try to infect as many peer groups as possible with the solution to create an eco-system where the solution can sustain itself. Then fit that part into the big picture, and move on to the next little puzzle part. So, I am volunteering to do stuff, who else is? Cheers -Richard PS.: the discussion is distributed among the following mailinglist, so check the archives: https://www.bek.no/mailman/listinfo/piksel http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra -- Are you teaching the What and the How but without the Why and the When? ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Fwd: I believe in cinelerra
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Richard Spindler schreef: 2008/1/19, Fred Williams [EMAIL PROTECTED]: Fine a wiki for the developers and a web site are good ideas. Developers may come and go and getting them up to speed on the project requires documentation and possibly training. Internal communications is vital and every developer should be in almost constant contact with the group to make sure everybody's on the same project and knows what is going on. This synergistic culture is vital to such a team. It's in everybody's interest that all the other team members understand the project perfectly. Time spent bringing a new member up to speed is not wasted. A developer's bulletin board is essential. Well defined standard interfaces for code is also essential and design changes must be tracked and approved by the core development team. Things like that ensure a solid program. I could get behind a project like that. Ok, so what needs to be done to get such a project rolling? Something like 'planning for Cine3' worked out in detail. Chunks everyone can implement with guidelines for it. - From my personal perspective I'm very interested in an efficient MLT.sf.net/Gstreamer like implementation. As I'm making live broadcast solutions, make it so that transcoding is only required when needed, maybe even on part of the actual image. I know this also involves codecs stuff, but making a video suite without codecs in mind is a suicide attempt anyway ;) Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHkm3rYH1+F2Rqwn0RCnqAAJsH+8XKpAKP2Nuh4bZYP1m7AeqhYwCdHdks eUGLI6dy7/ZGaotBf1OBir8= =NQ+y -END PGP SIGNATURE- ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Fwd: I believe in cinelerra
Fred Williams write: In other words, lots of work that are a pain in the ass but has to be done in order to advance properly. And passion has a limit. There must be people getting money to work on that. I was with you up to that point. Money is the root of all evil. It will totally corrupt the process. If you want money go to Micro$oft and develop for them. If you don't, (and I do realise that yopu may not have been referring to yourself), then why would you assume something like this? If this is to be a true cooperative effort, then let it be a volunteer effort. Is money a root of all evil??? In my opinion many money may be a root of evil, if users want to pay the work of the developers.. where is the evil? Paolo Rampino ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Fwd: I believe in cinelerra
2008/1/19, Stefan de Konink [EMAIL PROTECTED]: Ok, so what needs to be done to get such a project rolling? Something like 'planning for Cine3' worked out in detail. Chunks everyone can implement with guidelines for it. I am working on that one: https://init.linpro.no/pipermail/skolelinux.no/cinelerra/2007-November/012331.html Everyone is invited to comment and extend the list. If someone volunteered to tackle one of those tasks, I'd be happy to provide detailed feedback about how I think a _reusable_ solution could look like. Cheers -Richard ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Fwd: I believe in cinelerra
On Sun, 2008-01-20 at 00:36 +0100, [EMAIL PROTECTED] wrote: Fred Williams write: In other words, lots of work that are a pain in the ass but has to be done in order to advance properly. And passion has a limit. There must be people getting money to work on that. I was with you up to that point. Money is the root of all evil. It will totally corrupt the process. If you want money go to Micro$oft and develop for them. If you don't, (and I do realise that yopu may not have been referring to yourself), then why would you assume something like this? If this is to be a true cooperative effort, then let it be a volunteer effort. Is money a root of all evil??? In my opinion many money may be a root of evil, if users want to pay the work of the developers.. where is the evil? Paolo Rampino It would take some time to go into that and it's very off topic. The short answer is, Look at Micro$oft. If you're really want to get into it, see my paper, The Secret of Money: Beyond Socialism at: http://www.fredwilliams.ca/thesecretofmoney.html ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Fwd: I believe in cinelerra
On Sat, 19 Jan 2008 22:01:17 +0100, Richard Spindler [EMAIL PROTECTED] wrote: So, in planning this stuff the first thing to find out is who are the coders, and what are they willing to do. Making big plans and then expecting outsiders to jump in and start coding is an approach that has proven not to work, at least as far as my experience goes. I second that. However, I think it is useful to debate what needs doing along with what are you willing to do. You have already provided us with some points that need attention: https://init.linpro.no/pipermail/skolelinux.no/cinelerra/2007-November/012331.html Please read it. It contains both hard and simple problems, both complex and mundane tasks. Are there any takers for any of those items? Those who are making research and prototypes may also apply. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Rendering problem
I upgraded from Fedora Core 7 to Fedora 8, reloaded Cinelerra and the packages needed using yum and now I cannot get Cinelerra to render using YUV4MPEG Stream whether I use mpeg2enc or ffmpeg. I overwrote my .bcast directory by mistake and lost my configuration strings, but I am not sure that is the problem. The mpeg2enc pipe I am using is: mpeg2enc -f 8 -o % I have also used: mpeg2enc -b 0 -f 8 -o % I get the following output: trying popen(mpeg2enc -f 8 -o /video/DVDs/family/vacation/florida2007.m2v) INFO: [mpeg2enc] SETTING EXTENDED MMX for MOTION! INFO: [mpeg2enc] SETTING SSE and MMX for TRANSFORM! INFO: [mpeg2enc] SETTING EXTENDED MMX for PREDICTION! INFO: [mpeg2enc] Selecting DVD with dummy navigation packets output profile INFO: [mpeg2enc] Assuming norm NTSC INFO: [mpeg2enc] Progressive input - selecting progressive encoding. INFO: [mpeg2enc] Encoding MPEG-2 video to /video/DVDs/family/vacation/florida2007.m2v INFO: [mpeg2enc] Horizontal size: 720 pel INFO: [mpeg2enc] Vertical size: 480 pel INFO: [mpeg2enc] Aspect ratio code: 1 = 1:1 pixels INFO: [mpeg2enc] Frame rate code: 4 = 3.0/1001.0 (NTSC VIDEO) INFO: [mpeg2enc] Bitrate: 7500 KBit/s INFO: [mpeg2enc] Quality factor: 8 (Quantisation = 9) (1=best, 31=worst) INFO: [mpeg2enc] Field order for input: none/progressive INFO: [mpeg2enc] Sequence unlimited length INFO: [mpeg2enc] Search radius: 16 INFO: [mpeg2enc] DualPrime: no INFO: [mpeg2enc] Using one-pass rate controller INFO: [mpeg2enc] GOP SIZE RANGE 7 TO 15 INFO: [mpeg2enc] Setting colour/gamma parameters to NTSC INFO: [mpeg2enc] Progressive format frames = 1 INFO: [mpeg2enc] Using default unmodified quantization matrices INFO: [mpeg2enc] SETTING MMX and MMX for QUANTIZER! INFO: [mpeg2enc] PAR = 0 INFO: [mpeg2enc] NEW GOP INIT length 15 [svq3 @ 0x5f8f0c0]unsupported slice header (1F) FFMPEG::decode error decoding frame INFO: [mpeg2enc] Signaling last frame = -1 INFO: [mpeg2enc] Guesstimated final muxed size = 0 Render::run: Session finished. When I use ffmpeg, I used the command: ffmpeg -f yuv4mpegpipe -i - -y -target dvd -f mpeg2video % and got the output: trying popen( ffmpeg -f yuv4mpegpipe -i - -y -target dvd -f mpeg2video /video/DVDs/family/vacation/florida2007.m2v) [svq3 @ 0x5f8f0c0]unsupported slice header (1F) FFMPEG::decode error decoding frame FFmpeg version SVN-rUNKNOWN, Copyright (c) 2000-2007 Fabrice Bellard, et al. configuration: --prefix=/usr --libdir=/usr/lib --mandir=/usr/share/man --incdir=/usr/include/ffmpeg --enable-libmp3lame --enable-libogg --enable-libvorbis --enable-libogg --enable-libtheora --enable-libfaad --enable-libfaac --enable-libgsm --enable-xvid --enable-x264 --enable-liba52 --enable-liba52bin --enable-pp --enable-shared --enable-pthreads --enable-gpl --disable-strip libavutil version: 49.4.0 libavcodec version: 51.40.4 libavformat version: 51.12.1 built on May 30 2007 15:17:57, gcc: 4.1.2 20070502 (Red Hat 4.1.2-12) Input #0, yuv4mpegpipe, from 'pipe:': Duration: N/A, bitrate: N/A Stream #0.0: Video: rawvideo, yuv420p, 720x480, 29.97 fps(r) Assuming NTSC for target. Output #0, mpeg2video, to '/video/DVDs/family/vacation/florida2007.m2v': Stream #0.0: Video: mpeg2video, yuv420p, 720x480, q=2-31, 6000 kb/s, 29.97 fps(c) Stream mapping: Stream #0.0 - #0.0 frame=0 fps= 0 q=0.0 Lsize= 0kB time=100.0 bitrate= 0.0kbits/s video:0kB audio:0kB global headers:0kB muxing overhead nan% Render::run: Session finished. In both cases, a dialog opens with the message Error rendering data. I am using: cinelerra-2.1-0.13.20070108.fc8 mjpegtools-1.9.0-0.5.rc2.fc8 ffmpeg-0.4.9-0.8.20070530.fc7 I hope someone will be kind enough to put me back in the right direction. Regards, John ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: [piksel] Fwd: [estudiolivre] I believe in cinelerra
Fabianne Balvedi wrote: -- Forwarded message -- From: Leo germani [EMAIL PROTECTED] Date: Jan 18, 2008 7:53 PM Subject: [estudiolivre] I believe in cinelerra To: estudiolivre [EMAIL PROTECTED], Felipe Fonseca [EMAIL PROTECTED] What Develop cinelerra as a professional free/libre video editing tool. Why Cinelerra is the most powerfull free software for video editting we have nowadays. Although it has many resources and that it is far more advanced than any other Open Source video software, its development is very slow and has no sponsor. Its main developer, Heroine Warrior, do not mantain a SVN or a mailing list. The last official release was last july and there is no sign of a upcoming version of cinelerra. They usually publish a new release every six month or so but do it only for their own needs and do not talk with the community much. Few developers mantain a fork called Community Version. All out of volunteer work they mantain a SV a mailing list and an online wiki. They also fix some bugs and add some features to the code. This desorganized development results in a mess. There is no official stable release and package for the distributions, and cinelerra is now known as very hard to install and unstable software (although it got really better last year). Also, first contact with cinelerra is usually disappointing because of a not well resolved interface and also because of big flaws it has on some funcionalities. With all that said, it happens that we have a software that is, at the same time, powerfull enough to do any kind of editing, but weak enough to have very basic issues of usability. And the feeling all advanced users have is: We are pretty close to have high standard software! To learn more about the mess, take a look at this page: http://cv.cinelerra.org/about.php Many of the actions described on this plan are already been done by many people, but in a rather heroic way. If this people got motivated, organized and _paid_, cinelerra would increase its quality dramatically in a short period of time. The Plan 1. Get the community together The community of developers today is very small and spread, and cinelerra has no road map. We started already to work on a 'cinelerra3' (me, ichthyo, other people from IRC). We have a vision, a plan, design documents and already some code. Some docs on my wiki you may read: http://www.pipapo.org/pipawiki/Cinelerra3/Announcement http://www.pipapo.org/pipawiki/Cinelerra3/DesignProcess/Manifest This wiki is almost phased out now, we document inside the code repository, but comments/edits there will be acknowledged. First thing to do is gather this people to discuss about the future of cinelerra, identify the main flaws and its solution, make a plan to organize the place and set up for new features. I dont want to go into the details, just an introduction: * We rewrite it from scratch, but reuse code and ideas where possible * We work bottom up, first a core render engine, the GUI at last * Being language agnostic, plugin-interfaces will be plain old C then it is possible to write things in different programming languages * Using a free distributed devlopment model, that is: * for the developers, there is no (mandatory) central point, anyone can work on it, everyone is equal * Discussion is done on irc or in private mails * final decisions are published inside the repository docs * lowering entry barriers as much as possible Cinelerra needs a project leader, an interface designer, and more people with defined roles that should be choosen on this meeting. This designated roles are secondary, first and foremost Cinelerra needs people who actually *DO* things, then then the one who maintains the communication about merges or the one who works on the GUI or whatever gets this role de-facto. Developers of other softwares are also welcome. Cinelerra is, so far, the only video free editing video editing software with professional approach, but it could share a lot of things with other software, such as effects, for example, that shoul be usable in any video software, just like we have LADSPA for audio. There is already a video effect standar called Frei0r that cinelerra does not support. Frei0r is quite limited, for cinelerra we would like more professinal plugins. I don't want to blame it, actually this simplicity is also a big advantage for frei0r, easy, fast, pragmatic. We will certainly use it too and there are many other requests by users (gstreamer, commercial plugins, ...) this will be addressed. 2. Diagnostics Cinelerra code is not very well documented, so few people have the idea of how tuff is to deal with it. Second step is to see what must be done so we can invite more people to colaborate with the code. Documentation, refactoring, etc. It also has to work on the API so other people can write plugins and effects.
