Now that I was on Fedora 7, things had changed and those FreshRPM packages were no longer good. Specifically, I had some xine-lib packages installed from FreshRPMs which conflicted with either the Livna or Fedora base packages. I removed them:[root@ogre ~]# yum remove xine-lib=============================================================================Package Arch Version Repository Size =============================================================================Removing:xine-lib x86_64 1.1.6-2.fc7 installed 3.9 MRemoving for dependencies:xine-lib-devel x86_64 1.1.6-2.fc7 installed 649 kxine-lib-extras-nonfree x86_64 1.1.7-1.lvn7 installed 1.1 M

Testing the xine install with "xine-check", I got this error:[root@ogre ~]# xine-check[ hint ] No xine-config found. Assuming xine from RPMs The xine-config script can be used to determine some file locations used by xine-lib, but you don't have such a script on your system. However, it looks like you installed xine from the RedHat packages. So I'll just guess that you are using the standard locations. If you want me to be sure about those file locations, you can install the 'xine-lib-devel' package (or 'xine-devel', depend on what packages you're using, which contains xine-config. However, this package is not really needed to run xine... press to continue...

When I ran xine-check again, I no longer received that error. Good. But when I started up xine to play a test mpeg video, I got the dreaded error:There is no demuxer plugin available to handle"file:/usr/share/xine/skins/xine-ui_logo.mpv".Usually this means the file format was not recognized.

Hmm. I listed the packages I installed and found that I didn't have the "xine-lib-extras" packages installed. Specifically, the "xine-lib-extras-nonfree" one from Livna:[root@ogre ~]# rpm -qa | grep xinexine-lib-devel-1.1.10.1-1.fc7xine-0.99.5-1.lvn7xine-lib-1.1.10.1-1.fc7xine-lib-devel-1.1.10.1-1.fc7xine-lib-arts-1.1.10.1-1.fc7xine-lib-1.1.10.1-1.fc7

Happily, my mpeg video played! Also, an x264 video played. Great! So it looks like the Livna "nonfree" package is responsible for this joy. Thanks, Livna!The lesson here folks is that you have to watch your libraries. And stay away from FreshRPMs, if at all possible.

Wednesday, February 20, 2008

Anyone who reads my blog knows that although I am a loyal Penguin, I'm all about getting the work done expeditiously and distributing my videos to the widest array of formats possible. One of those formats is Apple's Quicktime. And for me, a rendered Quicktime usually ends up as an MPEG4 video in iTunes. With Apple announcing that the new Apple TV 2.0 displays web content as well as iTunes podcasts, higher definition content on iTunes is poised for much growth.

Therefore, it is in that light that I have tasked myself to encode and share some of my band videos to iTunes in glorious (or in the case of my band, un-glorious) DVD resolution. And while I'm at it, I should use tasty H.264 compression for maximum quality at a minimum file size. But of course, this seemingly simple task was much easier said than done.

For me, the rub is that encoding to x264 in Cinelerra is broken. I was getting this error when encoding to H.264:x264 [error]: no ratecontrol method specified

FFmpeg had crapped out, so I gave avidemux2 a shot. When I tried to encode using either command line x264 or x264 encoding through avidemux2, I would get this error:x264 [error]: width or height not divisible by 2 (480x1)

Well..the video is 720x480. Certainly those two numbers are divisible by two, so what gives with the logic of that error?

After Googling and trying various tweaks for about an hour, it occurred to me that there seemed to be no rhyme or reason to the error I was seeing. With that thought in mind, I decided to remove the x264 package entirely. I had installed the package from freshrpms:[root@ogre 20080206]# yum remove x264*Loading "installonlyn" pluginSetting upRemove ProcessResolving Dependencies-->Running transaction check---> Package x264.x86_64 0:0.0.0-0.3.20070529.fc7 set to be erased---> Package x264-devel.x86_64 0:0.0.0-0.3.20070529.fc7 set to be erased

Hmmm. Looking at the version number, it seemed like the x264 from FreshRPMs was a VERY early version number. Let me see if another repository has a different version. Luckily, Livna had some love waiting for me:[root@ogre 20080206]# yum install x264* --disablerepo=freshrpmsLoading "installonlyn" pluginSetting up Install ProcessParsing package install argumentsResolving Dependencies-->Running transaction check---> Package x264.x86_64 0:0-0.8.20061028.lvn7 set to be updated---> Package x264-devel.x86_64 0:0-0.8.20061028.lvn7 set to be updated

Now that version looks a little more recent, yes? With the new Livna repository x264 installed, I tried my render using the shortest path possible: avidemux2. Lo and behold, x264 no longer complained about my height and width not being divisible by 2! Better yet, I was able to render a complete file using avidemux2's two pass defaults without any errors! Some folks might appreciate seeing the verbose output:**saving:**Output format:7AVI familyEnc X264, using /mnt/videos/20070912/StormPigs20070912.mp4.stat as logfile

Friday, February 08, 2008

I received a question from a person unfamiliar with Cinelerra and I thought that my response should be shared. The person has a friend who runs Cinelerra in Ubuntu and he wanted a more experienced users' perspective on how Cinelerra compares to the more established, commercial packages like Premiere or Vegas. Here is how I responded to him.

Cinelerra is very powerful software if you can overcome some of its idiosyncracies. Idiosyncracies like:1) it is difficult to install for most people2) it sometimes crashes. There are more crashes on 32-bit systems. However, the consequences of a crash aren't bad, as you can simply restart Cinelerra, load the automatically generated backup file and pick up where you left off.3) rendering to final formats is challenging

Cinelerra is buggy in a consistent way. In other words, if you have the time and energy to figure out what works and what doesn't work, then you can base a workflow around that. But that effort is a huge time sink.

It doesn't get any better when you upgrade your system, because what once worked in a previous distro will break in your new distro. So, you spend oodles of time figuring out how to fix it.

It takes a certain kind of person who relishes the constant challenges of Cinelerra and Linux to power through these difficulties. Cinelerra is not everyone's cup of tea for sure, but you can get usable content out of Cinelerra if you know what works and what doesn't. Otherwise, save your valuable time and effort, buy a dual quad core Mac or PC with Final Cut Pro or Avid or Premiere or Vegas and be happy that everything works out of the box. Which isn't always the case even with those softwares.

Because Cinelerra is free software, it will never be as well supported as those commercial products. That being said, I have Cinelerra installed on Fedora 10 x86, 64-bit and the only time it has crashed is when I've done something stupid like try to write to a filesystem that is full or trigger a known bug, like using the broken DV import-record function.

I have spent the last two years learning the software and documenting specific processes using Cinelerra. You might glean some useful information by subscribing to my blog's RSS feed, because it documents the challenges I face in getting the software to work properly:http://crazedmuleproductions.blogspot.com/

I would suggest that a 64-bit machine is most stable for Cinelerra, moreso than a 32-bit machine. That is due to the fact that the 64-bit build will take full advantage of the memory resources on your computer and video editing is very taxing on a computers memory.

From the conversations on http://cvs.cinelerra.org/, the largest installed base of users seems to be on Ubuntu, Fedora and Debian distros. I would suggest starting with one of those distros, as many people on the CVS will be able to help you if you encounter problems.

There are two versions of Cinelerra. The original version you can get from http://www.heroinewarrior.com/, but the author does not support the software. The most actively supported version of the software is the Community Version (CV) and can be found on http://cvs.cinelerra.org/. That community of which I am part, has done significant work to fix bugs, accumulate and pass on knowledge to people interested in this great, free software and video editing in general.

Why Mule?

"Mules are not really stubborn. They can seem lazy because they will not put themselves in danger. A horse can be worked until it drops, but not so with a mule. The "stubborn" streak is just the mule's way of telling humans that things are not right. Mules are very intelligent and it is not a good idea to abuse a mule. They will do their best for their owner, with the utmost patience."About Mules