Re: [CinCVS] RE: Cinelerra digest, Vol 1 #1879 - 10 msgs
Herman Robak wrote: Seems like a fair summary. Do you think it's an unreasonable position? --Herman Robak I should clarify the last point. Any professional editing suite is going to have to maintain compatibility with tape based editing techniques - there are too many people out there trained to think that way. I would go as far a to call that compatibility a minimum functionality for something calling itself a video editor. There are other ways of doing things though. The design of Cinellera is probably appropriate for it's time. When Cinelerra was designed you could hardly call anything other than tape "well established". Unfortunately time and expectations have moved on, and that is what you are seeing in these comments. Brad Hare ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] RE: Cinelerra digest, Vol 1 #1879 - 10 msgs
[EMAIL PROTECTED] wrote:
This paradigm of editing the tracks and the timeline, not the clips
themselves, feels natural to people who are accustomed to editing with
tape, because tape works the same way (you edit the tape, not the things
on the tape).
Linear editing is going fast, if it's not already gone.
I also
don't think it'll change even *with* a complete rewrite, because changing
it would require drastic redesign, and would not provide any benefits that
developers consider important.
If you are developing for yourself fine - otherwise what's important is
what the
customer ("user" in newspeak) wants. At least that's the way it used to be.
I 've no idea what the sales are for Adobe and Apple, but I would guess
that 10^6 to 1E^7 is a good range for the order of magnitude. Now why
do you suppose they spent all that time and money putting those features in
there ???
Brad Hare
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] libcinelerra3
Jason van Gumster wrote: I regularly use Cinelerra on one of three machines: an eight-year-old box with an Athlon XP 2500+, a laptop with a hyperthreaded 3GHz P4, and another laptop with a dual core Turion64. Interesting thanks - I would have bet on heavier hardware. Can't imagine that Althon gives you much of a frame rate though ? Graham's post is right on target. I like to think of Cinelerra as more idiosyncratic than outright buggy. There are a number of things that it does very well... and there are some things that require you to do a bit of dancing to get it to work right. But once you muscle your way through that, there are quite a few possibilities open to you. For my own work, I agree. I can always bulldoze through and make it work, that is why I'm still attracted to this thing. I'm just not sure that I can, or should, expect that from others. Just read this, and totally agree - could not have said it better: http://www.pipapo.org/pipawiki/Cinelerra/Developers/ichthyo/Cinelerra_woes Regards, Brad Hare ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] libcinelerra3
Jason van Gumster wrote: I can't be the only one who's done successful complex editing in Cinelerra. I do fair amount of of work, professionally and independently, and while I'll admit Cinelerra isn't perfect, it certainly does the job for me on the projects I choose to use it on. Could you describe these in a little more detail, e.g. source formats project size, hardware config etc. ?? Some people seem to have better luck than others with Cinelerra, knowing why would probably be helpful for everyone - regardless of their current opinion. Regards, Brad Hare ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] libcinelerra3
Mark Carter wrote: I've taken to hacking away a bit at the code - and alas I broke my version. One thing that leaps out is all those case statements, esp. wrt colour models. I may be being too niaive, but I'd really like to see some kind of method of getting a grip on that. I looked at the flip plugin, and again, we see loads of switching based on the colour model. I wondered if there was a way of unifying the models. And I know we've been down this road before, and my views have been dismissed, but things like OpenGL don't help. They just pile complexity on top of complexity. The plugins even get in on the act. It's just too complicated. I really do wonder if the code base is 4 times larger than it really needs to be. Color space is a problem, but it should go with the format, e.g. if the timeline is HDV 720P30 then you're in ITU-R 709 land (I think). Ideally a good OO design would take out the internal switch statements. One way or the other you will always have to deal with passing around some knowledge of the underlying data format. Also, a unified format might force unnecessary de-compression - edit - re-compress cycles. Highly compressed formats like mpeg2 suffer badly when subjected to re-compression (the artifacts are bad enough to begin with). I would not discount OpenGl too much, but I agree that there are problems with it . The Blender people made good use of it to achieve cross platform portability (the gui is all OpenGL). My beef with it is the wide variation in compatibility between various video cards. Blender is a great video driver tester. The alternatives, in X, are also less than satisfactory right now. And what people really want is a predictable and robust workflow, even if it is (a little) round the houses: use ffmpeg to convert to DV, work your magic with Cinelerra, and then convert back to another format ready to upload to YouTube or whatever. The old unix model - simple tools that do one thing really well. Always a good way to design, whether the tools are separate, or under the umbrella of a larger application. Regards, Brad Hare ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] libcinelerra3
Valentina Messeri wrote: YOU..you're simply talking about your experience, do'you really think, talking about "educational purposes" that propietary tools worth the while? I could understand "profesional purpose", cause people got so used to their propietary tools and they, obviously, think work has to be done, first of all.. I am interested in video editing software of (or approaching) professional quality that can be used for high school classes in media and the arts. Current political trends have greatly limited funding for these activities in the United States. This is a good example of an "unmet need" waiting for an open source solution. Regards, Brad Hare ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] libcinelerra3
Mark Carter wrote: HV is undoubtedly a better programmer than me. I think he wrote it in a way that made sense for him. He wrote most of the code, so he pretty much knows the score of what's going on in it. But what works for him may not work for everybody else. Certainly there is a lot of credit due here. Very few people can even begin to steer 100k+ lines of code single handed, especially with a day job. That is also probably part of the problem here - at some point the thing just gets to be too much. This is a big project that cannot succeed without help. The success of Linux is always a good model. Linus Torvalds is a genius level programmer, but he was also smart enough to accept help. Lots of help. And I think we have to ask this question (I've asked it before): "who is the more prolific code writer, HV or CV?" An answer to that question will tell you whether we should depart from HV's codebase or not. As regards re-design, I think it might be too heroic. It would be heroic - and perhaps a disaster for a single programmer. The existing code has 10+ man years in it - that should serve as a guide to the scope of the project. My own guess would be 3 - 5 people, 1 - 2 years to get to an alpha version, starting from scratch. That assumes everyone is not only skilled, but dedicated to the project. I would not attempt a project of this size without knowing in advance that the resources are available. It can be done, but it is a daunting task. That probably explains why there are so few editing options available, and why the successes have been so limited. I would like people to answer to the following questions: * who writes more code for Cinelerra, HV, or the folks that contribute to the CV? * in user terms, what needs to change? I would place the stability and extensibility of the core as the number one priority. Working minimal functionality that can be maintained. I might be wrong, others seem to have been more successful at this than I have, but I just can't see trying to edit even a simple half hour program with Cinelerra. Looking at the code, it is not clear that fixes would require anything less than major surgery. As for the GUI, that is not something that should be a problem if everything else works. Blender is a good example, the GUI is weird, but the damn thing works - it's so good it almost compels you to learn it. (however you should be able to change the GUI if you don't like it, or need to do a port). Minimal functionality means three point editing, with basic transitions, of the most popular formats raw, DV and HDV (each of these has a specification although HDV is hard to get). You want a time line that gives you the ability to edit in a particular format (to minimize the need to re-encode). Source materials should be rendered to the timeline format. Rendering does not have to be real-time (nice feature though), The output should be able to display HD formats at full framerate on commonly available hardware .The existing code is probably a good guide to what a core would be - source management, timeline (edl), render engine, output. I could write an actual specification if anyone is interested. but the above should suffice to give the general idea. Regards, Brad Hare ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] libcinelerra3
I've been lurking here for a while, but this thread has been too much to resist. I would very much like to find an open source solution for video editing that could be used locally for educational purposes, but right now I can't recommend Cinelerra as I have never been able to get it working well enough on my own machines. In it's present state I'm afraid that it would be an exercise in frustration that would totally defeat the purpose. For now Final Cut Pro or Final Cut Express seats make a lot more sense. They work flawlessly, even on 5 year old g4 (~500 MHz) machines. The cost for both hardware and software in prohibitive though. I will have to admit that I have not looked at some of the work that has been announced recently. It makes me think that I must be doing something wrong, but I've been playing with the source for a while now. It compiles, it runs, but it is slow, crashes in almost every session and the render formats are somewhat limited. Some observations on the discussions so far: End Market Is this thing a professional video editor or is it something for home use. There is a very big difference in scope between the two, both for the programmer and for the end user. What are you trying to achieve. Scripts and Libraries I would worry about the architecture of the thing first. Right now the code extremely tangled with many opportunities for non-deterministic behavior. I assume that's why everyone is arguing about a re-write. My own opinion is that a re-design is needed first. Decouple all the bits and you can write a functional editing core while everyone else is still arguing about scripts and GUI's. Given the need for highly optimized/parallel code, I would classify the core as a non-trivial task. As an example (someone could verify this), I went into the existing decoder for mpeg2 and commented out the DCT routines to see if the mmx routines made any difference, I got about a 5% reduction in frame rate - with no transform mmx or otherwise. Further experiments made the same way lead me to believe that most of the playback overhead is outside of the actual decoding. Tracing the flow through the decoder was itself a "non-trivial" task. De-Interlacing Fine if it's the only alternative, but the interpolation yields a soft image. Interlace, 24P et al. The choice of a particular format is really a creative decision. The common wisdom says interlace for video and sports, progressive (esp. 24P) for storytelling. Ultimately the medium is a tool through which a individual vision is realized. There is no right answer. A creative person can work well in any medium, no matter how limited, but it can be a pain (that also applies to programming). Right now we are locally doing 60i, 720, 24 and 30P. and 1080i. After spending some time with real progressive formats (not post or in-camera processed) I personally would like to see interlacing die a horrible death, but as I noted above, that is only one person's opinion. I do agree that interlaced formats are likely to win in the consumer space. 1080 is a bigger number. Format and feature specifications should follow the identification of the end market. Who's gonna use this ??? What camera's are they likely to use. What are they shooting. What are they going to do to the footage. What's the distribution format, etc etc. That's probably too much already, but I would love to see a successful project here. There really is no other alternative on Linux. I do appreciate the efforts of the community here to try and fix up the existing codebase, but it really appears to be too hard. The upstream compatibility requirement is too restrictive, and even without that you are fighting the design. Regards, Brad Hare ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] about starting over...
Hermann Vosseler wrote: I don'tconsider it right to invent a new "killer feature" every half year and I don't like cinelerra fighting a competitive war against other video editing products, because I want it to stay what it is: a working tool for advanced users, enabling almost unlimited editing possibilities if you know what you want and how to achieve it. I hope you were not deriving that from what I said about competitive analysis. I guess I should have been less cryptic about what I was getting at. The craft of editing has been around for about 100 years now, video editing for about 30-40 years (if you go back to the razor blade days). The expectations for what an editor should do are well established and are reflected in the feature sets of "competing" products. As I said before, I believe that Cinelerra has everything needed, it just needs to be reliable. If we are talking about "advanced" vs "beginning" users there already is a project out there (Kino) which would fulfill the needs of beginners (as a sort of open source iMovie). As for Cinellera, it certainly has not been promoted as a beginners editor. A quick look at the Heroine website would make you think that Cinellera was giving Avid a run for the money. I agree with you completely - Cinelerra needs working, not "Killer" features. Whether or not this can be done with out some redesign of the architecture is a valid question. That is a hard thing to hear, especially if you've spent more than a few nights and weekends trying to patch this thing up. It would also mean a complete separation from Heroine Virtual. At some point you have to ask two questions: what am I trying to achieve, and how close am I to getting there. I do not think that a civilized debate on those two points would do this project any harm. I should have said several thank your's to the people maintaining CinCVS and this list. I do not think my interest in this project would have lasted very long if these resources were not available. After reading this list I realized that there were people out there who could get it to compile, and there were people out there actually using it. That left me with few excuses for not getting my own copy working. I still can't play an m2t clip (720p) without crashes, but maybe if I stop whining and get back to gdb I'll figure it out ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] about starting over...
We'll, I'm new around here, but I have been taking a deep dive through the code via gdb and Cscope. I also know a little bit about editing and have spent more that a few hours with Final Cut Pro and Premier. My own impression of Cinellera is that it is getting there, but it is not something I can recommend to others (in particular the creative types who are wizards at editing, but have little tolerance for anything that fails to live up to their expectations). It is simply too unstable and the feature set is too uneven. Between bugs and features I would place stability in the number one position. A full non-linear editing suite will not be either intuitive or easy to use for someone new to the subject. I have tutored complete newbies in Final Cut and Premier and the comments I have heard are quite similar to those I hear about Cinellera. I am therefore not inclined to criticize the interface. If you know what you want to do, it is relatively easy to figure out how to do it in Cinelerra. The current feature set is sufficient to get real work done. If you want to claim that Cinelerra is a fully featured and competitive editing suite, well, there's a little more left to be done. For anyone interested in the UI design, I would recommend looking at tutorials for the competing products to get an idea of possible the variations in workflow. Look up one and three point editing. A tutorial for Final Cut can be found here: http://www.geniusdv.com/final_cut_pro_courseware/finalcutpro_three_point_editing.php Should look familiar. I have traced through the code, and quite frankly it scares me. Billions and billions of threads - not quite a recipe for determinism. My impression right now is that the giu is probably usable as is, but the core needs to be rewritten. I am particularly interested in native DV and and HDV workflow, so I have been looking at the design from that perspective (that should explain my previous comment about a rewrite). I know that those with more experience in the codebase will probably take issue with such simplistic statements. I hope to have more tangible suggestions later as my understanding of the problem improves. Regards to All, Brad Hare ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
