Cinelerra stability

Posted Dec 8, 2009 7:01 UTC (Tue) by cantsin (guest, #4420)
Parent article: The CinelerraCV Project (Linux Journal)

I edit all my video work in Cinelerra (here are samples: http://www.vimeo.com/user743667/videos), consider myself a heavy user but curiously enough, rarely experience crashes, and am generally happy with the program. What's really unfortunate about it that it contains a bunch of functions that should simply removed because they're incomplete or unreliable. That includes the recording/capturing module, and many of the A/V codecs that seem to be supported.

I strongly suspect the issue in the AVI files Dave Philipps tried to edit. Safe and reliable editing formats are DV, DNxHD, high-bitrate MJPEG or uncompressed YUV/RGB with uncompressed 16bit sound in a Quicktime container. With dvgrab, grabbing DV is straightforward, with ffmpeg, it's a matter of a single command to convert other formats into the aforementioned codecs. For best output quality, I recommend to render to Quicktime with uncompressed RGB video and uncompressed audio, and create the eventual distribution video files with ffmpeg.

One should not run Cinelerra on a 32-bit machine. A fast (at least 2.4GHz) 64bit Dual- or Quadcore machine with at least 4 Gigs of RAM and a second SATA drive for the video project is strongly recommended.

While all this might sound cumbersome and discouraging, Cinelerra is a professional tool, and using it for editing AVI files misses the point of the software just as much as the use of Ardour for editing downloaded mp3s.

Cinelerra stability

Posted Dec 8, 2009 11:02 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (4 responses)

So, one problem that hurts badly on volunteer projects writing software mostly for experts / professionals is "learned avoidance". Both the programmers and the (majority) users unconsciously avoid parts of the program which either traditionally weren't reliable or just don't do anything useful to an experienced user. They may even have "muscle memory" ensuring that they never open the Frozbozz dialog without first flipping into Doodad mode, because "everyone" knows it crashes otherwise.

What you see in these cases is that beginners, who can't get the program to do hardly anything yet, can crash it, lock it up or cause other weird bugs. That's because they're still behaving intuitively. They aren't unconsciously compensating for your hopelessly buggy and badly designed program yet.

There are two possible perspectives on this:

1. Don't bother fixing bugs found by anyone with less than a week's user experience. No serious users will trip on these bugs anyway, so they're a waste of your time to fix, much better to concentrate on adding that feature 10% of the professional users wanted.

2. Work hard to capture and fix these bugs - you have only a short time before the user becomes experienced and never opens a Frozbozz dialog without flipping into Doodad mode, whereupon they won't be able to reproduce the bug and help you find and fix it.

Blender has this problem, I could crash it or lock it up every few minutes for the first hour I spent playing with it. But I wanted to learn so I pressed on. Now? I can't figure out what I did, so I can't report the bugs I found, whatever they were my unconscious now seamlessly compensates for them.

When we released our RDF storage engine as Free Software after it had previously been in-house software, many of the issues reported in the first week were hauntingly familiar - we'd had those problems, but we'd become used to them and stopped thinking about them as bugs, they were just things you had to compensate for when using the software. Now they're fixed and everyone's better off for that.

Cinelerra stability

Posted Dec 8, 2009 14:44 UTC (Tue) by macc (guest, #510) [Link]

He,he,

Robert Sheckley: "The Minimum Man"

uwe

Cinelerra stability

Posted Dec 8, 2009 16:27 UTC (Tue) by martinfick (subscriber, #4455) [Link] (1 responses)

I don't think that this is open source specific. I am convinced this is the case with almost all software, windows for sure. I had primarily used unix/linux for almost 10 years and then had to use windows for simple tasks at work. Every time I did something simple, I found weird behavior and felt that it was entirely unusable and sometimes crashed. When querying coworkers, I found the common answer would be, "oh just don't do that", as if you were supposed to just know that you shouldn't do things that I consider very simple on other operating systems or you should expect disaster. Almost all software users have learned habits that help keep them out of trouble (and yes, the few times a decade that I use a Mac, I find the same thing). But, just as you say, I would have a hard time telling you many of the specifics already, because, I am likely just used to them by now.

Cinelerra stability

Posted Dec 8, 2009 17:28 UTC (Tue) by iabervon (subscriber, #722) [Link]

Approximately the first thing I ever tried doing with Windows XP after not using Windows since 3.1 was making a copy of a shortcut and changing what the copy was a shortcut to. Then I stopped using Windows again for several years. I hear that there are things you can do with Windows XP, but you wouldn't know it from my experience.

Cinelerra stability

Posted Dec 8, 2009 17:07 UTC (Tue) by endecotp (guest, #36428) [Link]

I've heard these described as "institutionalised bugs".

That was in the context of web features that are in the specs but that no-one who's been around for a while even expects to work. They're the things that have been in the browsers' bugzillas since 2002. Now, people even argue that the wrong behaviour is actually right...

Cinelerra stability

Posted Dec 8, 2009 15:01 UTC (Tue) by MattPerry (guest, #46341) [Link] (3 responses)

> Cinelerra is a professional tool, and using it for editing AVI files
> misses the point of the software

Your perception of a file format being professional or not is irrelevant. If the program supports using AVI files for source material then it should do so reliably.

Cinelerra stability

Posted Dec 8, 2009 16:26 UTC (Tue) by cantsin (guest, #4420) [Link] (2 responses)

That's why my original comment suggested to remove functionality that is
not reliable. If Cinelerra would ditch the Record/Capture module, limit
import and rendering to Quicktime with a small number of editing-safe
codecs, prompt a default warning message on systems with insufficient
CPU/RAM resources, and have safe default preferences (such as the use of
OSS instead of ALSA for audio output), it would avoid shock and awe for
most first-time users.

Cinelerra stability

Posted Dec 9, 2009 8:10 UTC (Wed) by drag (guest, #31333) [Link] (1 responses)

Well the safe bet would be to fix Alsa and drop OSS. OSS support is so depreciated at this point that pretty soon even the most basic support of it is going to be missing completely in many Linux systems.

--------------

That's the thing, right? Alsa support is a requirement, not optional. Not unless you want to re-do most of the audio to use Gstreamer or SDL or something like that so you don't have to give a shit about Alsa vs OSS anymore.

AVI files themselves are nothing special.. it's just a container format that commonly has mpeg4 and mp3 audio. If Cinelerra can't handle importing that then there is something massively wrong in this day and age. There is some sort of fundamental design flaw going on there. Hell just off the top of my head spawning a helper script to use ffmpeg to dump raw YUV video into a fifo that directs to a internal buffer should not be that difficult and will probably be easily made to work 95 times out of a 100.

Cinelerra is useful to some people because it has features that nobody else has and capabilities that nobody else comes close to. Stripping out features to make it 'newbie friendly' is going to negate the entire purpose of it. It's a professional-style tool. It is like suggesting that GCC should just strip out warning and errors so that it can be more friendly to new C programmers. It's not a desktop or a browser and has to be useful for a general case. It has to be useful for a specific case.

This program has been around for years and years. Long ass time. It looks as if it has hit some sort of wall in terms of progress. I am sure the CinelerraCVS folks are working hard, but to progress to the next level they are simply going to have to do what the Blender folks have done. That is they need to sit down, get some funding, and work with people using it in a real environment with real video and audio in a real project. There is a insurmountable difference between arguing about features and UI in a mailing list versus standing behind professionals taking notes and suggestions as they struggle to use your software.

It's the difference between something like this:
Blender 2.37 screenshot
versus:
blender 2.5 beta screenshot

Ditto for Gimp and Krita or any other tool that wants to be more then just a useful tool to play around with.

Cinelerra stability

Posted Dec 9, 2009 9:21 UTC (Wed) by halla (subscriber, #14185) [Link]

Well, Krita is busy raising funds just now: see the Krita fund raiser, though we were clearly not ambitious enough: we managed to raise the 3000 euros needed to have one of us work on Krita full-time for three months in three days instead of the three months we thought we would need.

And we have got a plan, some real users who work with us to go through the issues they have with Krita and who tell us what is missing and what is crappy, so I am really confident that the next major release of Krita, around August or September 2010 will be a very significant improvement.

Especially if people don't stop donating, but go on so we can have Lukas for another month, fixing bugs full-time in the running up to the release!