On Friday 10 August 2007 05:31, mark carter wrote: > On Fri, 2007-08-10 at 17:10 +1200, David McNab wrote: > > On Thu, 2007-08-09 at 12:03 +0200, Herman Robak wrote: > > > On Thu, 09 Aug 2007 09:02:06 +0200, Raffaella Traniello > > > > > > <[EMAIL PROTECTED]> wrote: > > > >> From the Manual: > > > > > > > > "Cinelerra is not intended for consumers. [...] > > > > > > I consider that a bug, and I believe that some of the frustration > > > that brought Cinelerra-CV into existance came from that statement. > > I tend to agree. I'm not a pro, I'm just a guy who wants to put together > some clips and stuff for YouTube. My first impression was that "not > intended for consumers" was a nice way of saying "bug-ridden segfaulting > bucket-o-bytes". > "not intended for consumers" is exactly that. If you were to get Cinelerra ready for consumers, you would have to (a) hobble it into a subset of "normal" functionality and (b) spend a couple of years making it foolproof, bearing in mind that the quality of fool keeps increasing.
As for "bug-ridden segfaulting bucket-o-bytes" I submit to you Windows. > > I started out as a 'consumer' a couple of weeks ago as I was looking for > > a Linux video editor. > > I, too, am very new to it, and jsut beginning to "get" it. I just > discovered subtitling - no more separate programs for me in future. ;) > > A thought: when you load a file in with iMovie, it actually "imports" it > - converting it into its own format (quicktime, or whatever). Now, that > got me to thinking - if Cinelerra followed the same idea, that might be > quite good. It could have its own format. That format would be woefully > inefficient (hopefully not outrageously inefficient) as a storage > medium, but it would be excellent for what Cinelerra needs. You would > then have a level of separation between "foreign file formats" and > internal respresentation. You are then paving the way for being able to > test formats in isolation. And ... not that I know what I'm talking > about ... instead of using threads, Cinelerra could start a process that > does the conversion. If the user gets bored half way through, he clicks > the button and the process gets killed. > The problem with having its own format is that you are guaranteed to have image degradation. If memory serves, I think there is already a little bit of lossyness that occurs when editing a compressed format - there was some loss that occurred from the initial compression, you read it in and edit it and then apply more loss with the recompression. As for the use of threads, they are your friend. If you try going the process route, you lose benefits like common memory, thread communications, etc. Process to process communication is going to require more I/O (you have to copy the image into the other memory of the other process and back again) which is already probably THE bottleneck in most systems. Communication between the process is going to involve the operating system, and unless you get real fancy, you're probably not going to see the processed parts of the conversion until the conversion is complete. It just seems more efficient to me to use threads. _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
