The CinelerraCV Project (Linux Journal) [LWN.net]

The CinelerraCV Project (Linux Journal)

Posted Dec 7, 2009 21:57 UTC (Mon) by jra (subscriber, #55261) [Link] (7 responses)

In the age of valgrind, I don't understand why GUI projects still have reproducible crashes.....

Jeremy.

The CinelerraCV Project (Linux Journal)

Posted Dec 7, 2009 22:01 UTC (Mon) by BrucePerens (guest, #2510) [Link] (6 responses)

Yes, this sounds like wild pointers to me. Cinelerra is enormously memory-intensive, but it should be possible to instrument and debug. Valgrind should do it, Electric Fence might work on a machine with lots of RAM.

The CinelerraCV Project (Linux Journal)

Posted Dec 7, 2009 23:59 UTC (Mon) by elanthis (guest, #6227) [Link] (5 responses)

If nothign else, learning how to write quality code could do wonders. Well-written code is damn hard to crash.

The CinelerraCV Project (Linux Journal)

Posted Dec 8, 2009 0:48 UTC (Tue) by BrucePerens (guest, #2510) [Link] (4 responses)

Let's not be too fast here. Cinelerra is a huge, extremely functional, powerful program of the type that only a few years ago people said you could never get as Open Source. Good programmers write bugs too. If you want to know what the real problem is, instrument the code (on a system with lots of RAM and a fast CPU, I bet) and you'll be able to report back to us.

The CinelerraCV Project (Linux Journal)

Posted Dec 8, 2009 2:55 UTC (Tue) by madscientist (subscriber, #16861) [Link] (3 responses)

Heck, you don't have to instrument the code: most of the time all you have to do is run the thing in the debugger (assuming you have a debug build) full time. Then when it crashes you usually have all the info you need right there to figure out what happened, at least enough to get a good start. I ran Evolution for probably a year in the debugger, and we fixed a number of bugs in the OWA interface (and even some in Gnome itself) because of stack traces etc. obtained that way.

The CinelerraCV Project (Linux Journal)

Posted Dec 8, 2009 15:48 UTC (Tue) by mjthayer (guest, #39183) [Link] (2 responses)

> Heck, you don't have to instrument the code: most of the time all you have to do is run the thing in the debugger (assuming you have a debug build) full time.
This sort of thing can all be automated. Many distributions do that already, but things could still be improved a lot. At least Ubuntu disables it by default in releases to avoid swamping the bug system, they require a Launchpad account and I don't think they do it for all packages. I would have thought that this should always be the default, and that the traces should just be mailed to an e-mail address without requiring any login. That address should have the logic behind it for automatically filtering duplicates, spam and broken reports, and add valid reports to a database, keeping a duplicate count. Like kerneloops, but for userspace. It takes a bit of work, but it could be reused for virtually any software.

The CinelerraCV Project (Linux Journal)

Posted Dec 8, 2009 17:18 UTC (Tue) by madscientist (subscriber, #16861) [Link]

You're talking about automating collection of backtraces. That's useful. But I'm talking about actually invoking the problem application inside GDB; that is, instead of running "someprog", you run "gdb someprog" then "run" at the prompt.

The advantage of this is that when the process dies you are right there and can do live debugging. It's not so useful if you don't have any programming experience at all, but even if you have just a smidgen you can often poke around and look at variable values, etc. that give a LOT more information than just a backtrace. Even if you don't know programming, if you find a properly motivated developer he can give you lots of pointers and instruction over email or IRC or whatever; you'll be able to pick it up pretty quickly.

The CinelerraCV Project (Linux Journal)

Posted Dec 9, 2009 15:58 UTC (Wed) by mjthayer (guest, #39183) [Link]

Ubuntu upload an entire core dump by default, but that is rather bulky. I could imagine refining the process a bit - like accepting core dumps if a developer has looked at the stack trace for a given crash and decided that they would be interested in more information. Obviously being there with a running gdb when a crash occurs will let you obtain a lot more information, but that rather limits the surface of attack available to you. The advantage of the automatic backtrace thing is that you get information about a much wider range of crashes than you are ever likely to see yourself.

The CinelerraCV Project (Linux Journal)

Posted Dec 8, 2009 5:21 UTC (Tue) by yodermk (subscriber, #3803) [Link]

I've used Cinelerra for a few little things and have been very happy with it. Crashes? Yes sometimes but less recently and, helpfully, you can almost always get back to exactly where you left off with only a couple clicks and little waiting. It always saves its temporary work after every operation.

Cinelerra stability

Posted Dec 8, 2009 7:01 UTC (Tue) by cantsin (guest, #4420) [Link] (9 responses)

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!

The CinelerraCV Project (Linux Journal)

Posted Dec 8, 2009 12:06 UTC (Tue) by maks (guest, #32426) [Link]

Since the Grumpy Editors review pitivi has geared up. It would be the choice of these days i'd guess. :)