Two Steps Forward for Linux Multimedia

chill writes: "A while ago Heroine Virtual had a video editing program out called Broadcast 2000. Then something weird happened and the program was pulled from release with the homepage saying it was too dangerous legally to put out. Something about liability. Anyway, the successor to that program, called Cinelerra, is now available in beta form. Give it a shot and see what is what." And Dominic Mazzoni writes: "Talk about a tough act to follow. On the same day that Mozilla 1.0 was released last week, we released version 1.0.0 of Audacity, our GPL cross-platform audio editor that has been under development for nearly three years. It is based on wxWindows and runs natively on Linux (of course!), Windows, Mac OS (both 9 and X), and some other POSIX systems. Version 1.0.0 just adds a couple of minor features and bug fixes, but it is basically stable and quite useful, though it has some limitations. In addition, we also released a snapshot of our unstable development branch as Audacity 1.1.0. This version adds support for 24-bit and 32-bit samples, automatic resampling, LADSPA plug-ins, and internationalization, plus it has many nifty new UI enhancements."

Comments

The Cinerella installation process is `unique'

[Nailer]

Use rpm -i --force --nodeps to install it.

Euw. A package management system, like any other management system, has network effects. I.e, the power of the system is the square of the nodes. I don't install unpackaged applications because removing one of those nodes has a substantial effect on the usefulness of the system. I.e, I can't install any apps on top of Cinererella if I install it from an unpackaged tarball. Luckily we have the Linux Standard Base and RPM, but the
Cinererella package apparently must be force installed. Euw.

If Heroine Warrior or anyone reading this will host it, I can provide RPMs that will install on most major Linux distributions. If package dependencies are a support issue that HW don't want to deal with, make an apt repository to serve out the RPMs. Any dependent package will be downloaded as necessary from the apt source of the main distro and installed automatically. My email address is mikem, at the domain name above.

Re:The Cinerella installation process is `unique'

[Slackrat]

This seems to be the case with a lot of Multimedia applications in Linux. Xine, Mplayer, transcode... they all seem to include all their required libraries internally instead of just linking to the appropriate one already on the system. Perhaps this is a reflection on how chaotic multimedia is in Linux. The only way to get consistent libraries is to just include them directly?

Re:The Cinerella installation process is `unique'

[Slackrat]

I don't think the "library hell" we have imposed on ourselves is so much a function of limitations in RPM, but rather inconsistent packaging. You can do anything with an RPM if you know how to tweak it. The problem in my mind comes from inconsistent library naming.

For example, say you have libfoo which you package as Version: 1.0. When you move to libfoo v2.0, you introduce feature changes that make it incompatable with v1.0. Theoretically, you could have libfoo.so.1.0 and libfoo.so.2.0 installed at the same time, but you kept your RPM named libfoo for both RPMS. Thus, the RPM engine won't let you have both installed at once. If the new library had simply been named "libfoo2", no problem.

All this gets back to what you called for: standards. While I don't think UL is the best way of doing it (they are only interested in dethroning RedHat), LSB would be a good place to start.

As for multimedia applications, they have a different sort of library hell. Most of these libraries are 0.x betas and thus their feature sets are evolving by the day. To release your application, you generally have to include the libraries from a given day just to lockdown what features your application will use. Once these libraries and applications mature, maybe things won't be so bad?

Re:Cinelerra sounds like great news for fan films

[damiam]

Independent film makers are not going to be using the beta version of an incomplete Linux video tool. If they can afford to pay for a computer, digital cameras, and a cast, I think it's safe to say most of them can afford something much nicer, like Final Cut Pro.