NVidia in da house (er, new server)!

So I've been on a quest to get a modern PCI Express card working in my new Dell SC1430. With this goal in mind, I had ordered a PCI Express 8x to 16x Adapter like this one off of eBay:
http://www.orbitmicro.com/global/pciexpressx8tox16adapter-p-755.html

The SC1430 has 8x connectors (running 4x speed PCI Express). In the hopes that it would work in the box, I bought a BFG Geforce 8500 GT PCI Express 256MB card from BestBuy. I checked and it is cheaper on Amazon.

Here's a good article from Tom's Hardware on PCI Express scaling:
http://www.tomshardware.com/2007/03/27/pci_express_scaling_analysis/

I figured that even if the card didn't work, I'd use it later in the next box I build. Now, I understood that the adapter would raise the card in the slot. The Dell has a hinged metal door that holds all the expansion cards in place, but I noticed that that little door can be left open while the case is closed. This would allow me to use the card for a while until I had the chance to machine a new bracket for the card.

Last night, I attached the adapter to the new BFG card (with a satisfying "click", no less) and put it in the first PCI Express slot (SLOT1_PCIE) of the Dell. I left the hinged door open, but was able to close the case. I hooked up my FP1901 to the digital output and my FP1907 to the analog output. I can tell you I was quite surprised when I started the server and the FP1901 that was connected to the digital output came to life!

I booted into runlevel 3 (nongraphical, multiuser mode) in Fedora and grabbed the latest NVidia driver installer for my 64-bit OS via lynx. I ran the installer. There was not a default kernel module for my particular kernel, so the installer created one and then asked if I wanted to create a new xorg.conf for the X Windows. I said yes and the installer finished. I was elated to see X startup with the NVidia splash screen! I soon had Twin View setup and GLXgears gave me 6200FPS! Unlike the ATI card I had running in the box previously, mplayer and xine ran my HDV videos like champs! Hoohah! Cinelerra runs well, but I've decided to not compile OpenGL just yet, as it did cause some instability on my previous box.

I tell you, NVidia drivers are an absolute joy to setup and use. As I've reiterated many times on this blog, most recently here:
/2007/10/year-later-ati-linux-drivers-still-suck.html

ATIs Linux drivers are riddled with bugs; hence, I returned the ATI card, a VisionTek x1550, to the store.

In sum, the BFG Geforce 8500 GT PCI Express 256MB card works in the Dell with a PCI Express 8x to 16x adapter card. If you use a PCI Express adapter, be aware that the card will be raised in the slot when it is seated.

the mule

ps - Now I just have to debug and fix a nagging audio noise with Fedora and the Dell and I will be one happy dude.

A year later, ATI Linux drivers still suck

Folks, just in case you don't know, ATI's display drivers for Linux still suck, one year later:
/2006/09/ati-opengl-20-implementation.html
/2006/09/opengl-acceleration-for-cinelerra-not.html

Here's a bit of the latest pain:
https://init.linpro.no/pipermail/skolelinux.no/cinelerra/2007-October/012026.html

Here's another tale of woe (read starting with post #1014):
http://forums.fedoraforum.org/showthread.php?t=155503&page=102&pp=10

In the interest of having a clean system to start with, I reinstalled Fedora Core 6, 64-bit. I installed all Cinelerra source dependencies and attendent media players and apps as per this post (/2007/09/building-cinelerra-on-fc6-64-bit.html). I then made the very intelligent choice of backing up my system by using a Knoppix Bootable CD (www.knoppix.com) to load partimage and make an image of my system drive. For those who'd like to know how to do this, I will try to post a doc on what to do.
Update 2008/11/16
Here's how you can do this.
end update

This allows me to easily restore from image if anything went drastically wrong with the ATI install process. It is a good thing I did this.

After having the core softwares installed, I compiled Cinelerra and created a project by recording a screen capture with voiceover, some fades and a simple mask. This worked well, so I then decided to tackle building the 8.36.5 version of the ATI installer. I built the ATI rpms with the following command:
./ati-driver-installer-8.36.5-x86.x86_64.run --buildpkg Fedora/FC6
With the recent clean install of FC6 x86-64-bit, I was surprised to see that the build process actually worked! Previously, this build process failed. I speculate that the reason for the previous failure was that I kept my repositories consistent on this OS build. This means I tried not to mix rpm bases from more than two non-Fedora repositories: Dries and Livna, respectively. Refer to http://crazedmuleproductions.blogspot.com/2007/09/building-cinelerra-on-fc6-64-bit.html) for the detail. So having this build process work was unexpected. It gave me hope that I might have some resolution to my ATI woes.

I installed the created ATI rpms and shutdown the box. I popped in the VisionTek card and rebooted to init 3, full multi-user mode, without X enabled. I then ran the ATI configurator:
./aticonfig --initial -f

[sodo@ogre 8.36]# ls -l
total 65244
-rwxr-xr-x 1 root root 53331877 Oct 8 21:18 ati-driver-installer-8.36.5-x86.x86_64.run
-rw-r--r-- 1 root root 6469324 Oct 10 22:49 ATI-fglrx-8.36.5-1.fc6.x86_64.rpm
-rw-r--r-- 1 root root 3367465 Oct 10 22:49 ATI-fglrx-control-center-8.36.5-1.fc6.x86_64.rpm
-rw-r--r-- 1 root root 45017 Oct 10 22:49 ATI-fglrx-devel-8.36.5-1.fc6.x86_64.rpm
-rw-r--r-- 1 root root 3192548 Oct 10 22:49 ATI-fglrx-IA32-libs-8.36.5-1.fc6.x86_64.rpm
-rw-r--r-- 1 root root 309737 Oct 10 22:49 kernel-module-ATI-fglrx-2.6.18-1.2798.fc6-8.36.5-1.fc6.x86_64.rpm


This created a default fglrx /etc/X11/xorg.conf file. I started X and was pleasantly surprised to see both my monitors (Dell FP1901 and FP1907) come alive. I started the ATI Catalyst Display utility and was excited to see that OpenGL was indeed active. I switched from Clone mode (2 separate screens displaying the same thing) to Big Desktop mode, one large desktop. Excitedly, I wanted to see the behavior of xine and mplayer under 8.36.5, as I read some threads that lead me to believe I might get OpenGL without the xine crashes and mplayer sluggishness I had seen using 8.39.4 and 8.40.4. Unfortunately, it was not to be, as I loaded mplayer to see the same sluggishness on HDV content display. I then started xine and true to form, xine displayed the HDV content, but then promptly crashed X.

Ah well. At this point, I decided to restart the system, just to see if the restart improved conditions. When I restarted, I got the following error:
/etc/rc.d/rc.sysinit line 819: Segmentation fault

Oh boy. That does not look good. And the entire system has locked up..I can't even reboot. After a hard shutdown, I restarted, only to find the same error condition reappear. Google is again my best friend:
http://www.linuxforums.org/forum/servers/15670-help-segmentation-fault.html

So, it seems my choices are that:
1) my system memory is corrupt
2) grep is corrupt
3) I've been hacked

This is a new server with ECC memory, so I really doubt the memory has gone bad. But I'd rather be sure. Through the above Google find, I see that memtest86 (www.memtest86.com) is a solid program for testing your system memory that I haven't used before. The doc on the website is very good. I grabbed the ISO online and burned a copy to CD and let my machine churn for about three hours running through memory tests. Thank goodness, no memory errors were found. It seems that Mr. Brady knows his stuff! Thanks Chris!

Secondly, I tried to remark out the offending "for" loop within rc.sysinit. I needed to boot off a Knoppix (www.knoppix.com) CD to be able to assemble my software RAID partition, mount it and edit the file. Doing this and rebooting yielded the same results.

My third and final troubleshooting procedure was to remove and replace "grep" which is where the init loader failed. Again, I booted off the Knoppix CD, assembled and mounted my RAID. This time, however, I changed my root (chroot) partition in order the remove and reinstall grep via rpm and the Fedora install DVD. I did this, rebooted and received the same error.

At this point, I threw my hands up in the air and decided to reinstall my clean partimage image. Knoppix to the rescue again, and I restored the image of my clean install off a second drive I had on the system. A reboot later and I was back up and running. Praise the Lord!

So..what is the moral of this story, you might ask? It must be this, cause I can't think of anything else right now: Don't trust people over 30 and be sure that ATI will always disappoint you if you run Linux.

Harumph!
The Mule

rendering on the dual quad core Dell SC1430

I'm starting to get used to the new rig and what works and what doesn't. Here's a video describing how a render works on the new Dell SC1430, dual quad core xeon box running FC6, 64-bit Cinelerra. The render format (not shown in the video) is the following:
File format: Quicktime for Linux
Audio compression scheme: MPEG-4 audio, 128kbps bitrate, quantization quality 50%
Video compression scheme: H.264, 1000000 fixed bitrate (1Mbps)

I was listening to Aaron Newcomb's SourceShow podcast from LinuxWorld in Ohio while describing the render, so that's the voice you'll hear in the background.


PS - I rendered to Quicktime for Linux in this example, but you can use the
-threads [numberOfCpus]
command line switch to use more than one CPU.

enjoy,
the mule

getting started with Cinelerra

A couple of friends asked me about how to get started with Cinelerra. Here are a few techniques that have helped me:

Download and install the CV version of Cinelerra
As it is actively updated, the community version of Cinelerra is a good starting point:
http://cvs.cinelerra.org/getting_cinelerra.php

Run Cinelerra from a Terminal
Once you install it, run Cinelerra in a terminal, so you can see the error output. It will look like this:
[mule@ogre ~]# cinelerra
Cinelerra 2.1CV (C) 2006 Heroine Virtual Ltd.
Compiled on Mon Oct 8 23:47:21 EDT 2007

Cinelerra is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. There is absolutely no warranty for Cinelerra.
Render::run 1
Render::run 2
Render::run 3
Render::run 4
Render::run 5
Render::run 6
Render::run 7
Render::run 8
Render::run 8.1
Render::run 8.2
Render::run 8.3
Render::run 9
Render::run 10
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:71 Avg QP: 2.00 size:199495 PSNR Mean Y:64.88 U:65.58 V:65.60 Avg:65.10 Global:65.06
x264 [info]: slice P:17600 Avg QP: 5.00 size: 3153 PSNR Mean Y:62.18 U:62.58 V:62.57 Avg:62.30 Global:62.12
x264 [info]: mb I I16..4: 41.8% 0.0% 58.2%
x264 [info]: mb P I16..4: 1.0% 0.0% 0.2% P16..4: 9.6% 0.2% 0.1% 0.0% 0.0% skip:89.0%
x264 [info]: SSIM Mean Y:0.9999576
x264 [info]: PSNR Mean Y:62.192 U:62.595 V:62.579 Avg:62.308 Global:62.131 kb/s:945.04

Read the Doc!
The most important step! As Cinelerra is a very powerful program, its functionality is very deep. Therefore, there is a lot to know about it. Read the documentation! If you don't read documentation, this program is not for you.
http://cvs.cinelerra.org/docs.php

A very nice beginner's guide written by Raffaella Traniello:
Cinelerra for Grandma

If Cinelerra Crashes
1) restart and select File -> Load from Backup
- This allows you to start where you left off
2) Check the buglist:
http://bugs.cinelerra.org/

Try Alternatives
If something doesn't work in the expected fashion:
1) Read the documentation (as above)
2) Try alternatives
For instance, if a file does not import in Cinelerra, convert it to a format that will! You can use ffmpeg to convert from any format to almost any format. Here is a sample ffmpeg command line to do this:
ffmpeg -i inputFile.containerFormat outputFile.containerFormat

For example
ffmpeg -i inputDvd.mpg outputQuicktime.mov

FFMPEG References
Nice howto: http://howto-pages.org/ffmpeg/
FFMPEG documentation: http://http//ffmpeg.sourceforge.net/documentation.php

Don't forget to read my Beginner's Guide to Exporting Video from Cinelerra!
/2007/06/beginners-guide-to-exporting-video-from.html

I hope this helps,
the mule

introduction to Blogger video tutorial

Written for a friend, thought others might find it useful. Screencaptured and edited in Cinelerra, of course!

Part I - regarding settings within blogger


Part II - regarding posting


Part III - regarding the template, analytics and adsense

moving my RAID set to a new box: collision!

For performance, I have my videos stored on a stripe set, using Fedora's software RAID technology. I've recently setup my Dell Octo Core box, but had not yet migrated the RAID set to it. This morning, at about midnight, I decided to start the migration. That was my first mistake.

Contention for the Same Device Name
The RAID set is a couple of 120GB IDE drives on a Sil680 PCI card. Not the best performers, but I was minding my pennies when I bought the drives and card. So I popped the card and the drives in the server. Thankfully, the card was immediately recognized by the BIOS on bootup. However, from the dmesg output:
Oct 4 23:53:53 localhost kernel: md: considering hdd1 ...
Oct 4 23:53:53 localhost kernel: md: adding hdd1 ...
Oct 4 23:53:53 localhost kernel: md: adding hdc1 ...
Oct 4 23:53:53 localhost kernel: md: md0 already running, cannot run hdd1

I saw that the device name of RAID set that held my videos /dev/md0 conflicted with the RAID set that I had created as my / (root) partition for 64-bit Core 6. Argh! Once per year, like Christmas, I have to dust off my rusty mdadm skills. Ugh. This was that time.

The Plan
After reading a number of references listed below, I decided to eliminate the contention, by renaming my video RAID set from /dev/md0 to /dev/md1. To accomplish this, I had to update the superblock on the RAID set to a different preferred minor number. More on this in a moment.

Since putting the drives in the new server, I was a little nervous about the condition of the data on them drives. To give myself a bit more of comfort, I decided on the following course of action:
- put the drives and card back in the original computer
- renumber the preferred minor number of the RAID set there
- test to verify that I can still mount the filesystems on the RAID and access the data
- move the devices back into the new server
- assemble, test and mount the RAID

So Let's Get Started!
I put the card and drives back into the original box. Here is the detail of what the RAID set looked like there:
[root@computer ~]# mdadm --detail /dev/md0
/dev/md0:
Version : 00.90.03
Creation Time : Sat Aug 19 23:57:28 2006
Raid Level : raid0
Array Size : 234436352 (223.58 GiB 240.06 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Fri Oct 5 14:31:37 2007
State : active
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Chunk Size : 64K
UUID : 9c4c078f:8935e3e4:bfface8f:6a3c2c18
Events : 0.15

Number Major Minor RaidDevice State
0 22 1 0 active sync /dev/hdc1
1 22 65 1 active sync /dev/hdd1

Update the RAID Device Number (Preferred Minor)
I first stopped the RAID set:
[root@computer ~]# mdadm --stop /dev/md0
mdadm: stopped /dev/md0

Next, I issued the following command to update the minor number. Unfortunately, it didn't work, as I received the following error:
[root@computer ~]# mdadm --assemble /dev/md1 --update=super-minor -m0 /dev/hdd1 /dev/hdc1
mdadm: error opening /dev/md1: No such file or directory

Oh boy. From the error, it looked like I needed to have a block device file called /dev/md1 created. I wasn't sure, though, as my mdadm and RAID chops were rusty. So, after a LOT of research (references listed below), I learned that I needed to create the block device file.

Creating a Block Device
Referring to these instructions, I created the block device for /dev/md1 with the following commands:
[root@computer ~]# mknod /dev/md1 b 9 1

I wanted to keep the permissions consistent with the old /dev/md0 device file, so I ran the following commands:
[root@computer ~]# chmod 640 /dev/md1;chown disk /dev/md1
[root@computer ~]# ll /dev/md*
brw-r----- 1 root disk 9, 0 Oct 5 14:24 /dev/md0
brw-r----- 1 root disk 9, 1 Oct 5 14:43 /dev/md1

Updating and Testing the Preferred Minor Number (device id)
Once the block device file was created, I issued the command to update the preferred minor number of the RAID set to 1:
[root@computer ~]# mdadm --assemble /dev/md1 --update=super-minor -m0 /dev/hdd1 /dev/hdc1
mdadm: /dev/md1 has been started with 2 drives.

Sweet! The RAID device started! Let's see how it looks (note the Preferred Minor number!):
[root@computer ~]# mdadm --detail /dev/md1
/dev/md1:
Version : 00.90.03
Creation Time : Sat Aug 19 23:57:28 2006
Raid Level : raid0
Array Size : 234436352 (223.58 GiB 240.06 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 1
Persistence : Superblock is persistent

Update Time : Fri Oct 5 15:43:48 2007
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Chunk Size : 64K
UUID : 9c4c078f:8935e3e4:bfface8f:6a3c2c18
Events : 0.20

Number Major Minor RaidDevice State
0 22 1 0 active sync /dev/hdc1
1 22 65 1 active sync /dev/hdd1

I like the word "clean"! And how are the individual drives making up the set doing?
[root@computer ~]# mdadm -E /dev/hdc1
/dev/hdc1:
Magic : a92b4efc
Version : 00.90.01
UUID : 9c4c078f:8935e3e4:bfface8f:6a3c2c18
Creation Time : Sat Aug 19 23:57:28 2006
Raid Level : raid0
Device Size : 117218176 (111.79 GiB 120.03 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 1

Update Time : Fri Oct 5 16:03:24 2007
State : active
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Checksum : 8bd047df - correct
Events : 0.21
Chunk Size : 64K

Number Major Minor RaidDevice State
this 0 22 1 0 active sync /dev/hdc1

0 0 22 1 0 active sync /dev/hdc1
1 1 22 65 1 active sync /dev/hdd1

[root@computer ~]# mdadm -E /dev/hdd1
/dev/hdd1:
Magic : a92b4efc
Version : 00.90.01
UUID : 9c4c078f:8935e3e4:bfface8f:6a3c2c18
Creation Time : Sat Aug 19 23:57:28 2006
Raid Level : raid0
Device Size : 117218176 (111.79 GiB 120.03 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 1

Update Time : Fri Oct 5 16:03:24 2007
State : active
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Checksum : 8bd04821 - correct
Events : 0.21
Chunk Size : 64K

Number Major Minor RaidDevice State
this 1 22 65 1 active sync /dev/hdd1

0 0 22 1 0 active sync /dev/hdc1
1 1 22 65 1 active sync /dev/hdd1

Love the word "correct"!

Is My Data Still There?
So how about we try a mount?
[root@computer ~]# mount -t ext2 /dev/md1 /mnt/videos
[root@computer ~]#

No errors on the mount! That's great! Now for the finale..let's look at a test file:
[root@computer ~]# head -2 /mnt/videos/paris/newtrip.xml
<?xml version="1.0"?>
<EDL VERSION="2.0CV" PROJECT_PATH="/root/installFiles/paris/newtrip.xml">

Awesome! I'm very relieved I can read the content off the drive. That is a load off my mind. The last task was to edit /etc/fstab and reboot to make sure the RAID set comes up correctly on boot. Blissfully, those steps were also successful.

Put 'Em In Da New Box!
I then took the whole kit and caboodle to the new server. I am very happy to report that the kernel recognized the newly renumbered RAID set, as shown in the output of dmesg:
md: created md1
md1: setting max_sectors to 128, segment boundary to 32767

and created the /dev/md1 device, as shown in this file listing:
[root@ogre ~]# ll /dev/md*
brw-r----- 1 root disk 9, 0 Oct 5 19:27 /dev/md0
brw-r----- 1 root disk 9, 1 Oct 5 19:27 /dev/md1

I added the following line to /etc/fstab:
/dev/md1 /mnt/videos ext2 defaults 1 1

And ran "mount -a" to reinitialize the file system table. Lo and behold, I've got data on my drive!
[root@ogre ~]# ls /mnt/videos
20060319 20060812 20070316 20070811 axe cinelerra movies paris_tape1 stockholm_tape1
20060406 20070111 20070425 20070912 bloody lost+found paris paris_tape2 stockholm_tape2

Caveat for RAID under a Knoppix CD
At one point in my debugging, I pulled out my trusty Knoppix bootable CD. If you need to load your RAID set from a rescue disk or more specifically, Knoppix, you'll need to load the md module and then run mdadm --assemble to start your existing RAID set.
root@Knoppix:/ramdisk/home/knoppix# modprobe md
root@Knoppix:/ramdisk/home/knoppix# mdadm --assemble -m 0 /dev/md0

Well, another chapter in the life of the Mule is closed. Hopefully, someone will find these notes instructive.

Update 2009/03/25
Some hdparm drive read measurements. Note the 60% read speed increase of the stripe set versus the mirrored set.

/dev/md0 is a software RAID0 (stripe) of two 500GB, 16MB cache SATA drives:
[mule@ogre ~]$ sudo hdparm -tT /dev/md0
sudo hdparm -tT /dev/md0

/dev/md0:
Timing cached reads: 5748 MB in 2.00 seconds = 2877.62 MB/sec
Timing buffered disk reads: 352 MB in 3.02 seconds = 116.68 MB/sec

/dev/md0 is a software RAID1 (mirror) of two 500GB, 16MB cache SATA drives:
[mule@ogre ~]$ sudo hdparm -tT /dev/md2

/dev/md2:
Timing cached reads: 5218 MB in 2.00 seconds = 2612.72 MB/sec
Timing buffered disk reads: 218 MB in 3.03 seconds = 72.04 MB/sec

*** end update ***

The Mule

References
http://www.redhat.com/magazine/019may06/departments/tips_tricks
http://www.linuxdevcenter.com/pub/a/linux/2002/12/05/RAID.html?page=1
http://www.docunext.com/category/raid/

Nice Beginner's Guide
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch26_:_Linux_Software_RAID

The Man Page
http://www.linuxmanpages.com/man8/mdadm.8.php

HowTo (with good description of chunk sizes)
http://www.tldp.org/HOWTO/Software-RAID-HOWTO.html

MDADM Recipes
http://www.koders.com/noncode/fid76840E0EBBC19222CBCC0913D4AED97C1F5D2A45.aspx

Notes for Debian MDADM users
http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/README.upgrading-2.5.3?op=file

xmms error: alsa_setup_mixer(): Failed to find mixer element: PCM

So here's a way to not spend an hour troubleshooting a problem:
LOOK AT THE F'ING PREFERENCES MENU!!

Sorry to be yelling, but man, do I hate my own stupidity. I had installed the xmms-wma plugin and wanted to test the playability of WMA files in Linux. Since this is my new Dell server with a new Creative Labs AudigyLS card and a fresh build of FC6, x86-64, I hadn't used the xmms install on the system yet. So when I started xmms, I noticed that I got the following error:
alsa_setup_mixer(): Failed to find mixer element: PCM

Oooh. That's not nice. So, it my typical fashion, I googled the error:

And found that a lot of people had a similar issue. And the more I looked at the entries, the more the people seemed to be having pretty cryptic difficulties. Oh, this might be a bad one. I assumed the worst.

So back and forth I went. Looking at the google results, trying to find the correct ALSA device name and hand entering it into xmms's config file. I got confused at the lsmod and modprobe.conf output and entered the wrong sound device name. I repeated this process multiple times.

Finally, after the end of an hour, I remembered that there was a Preferences menu within xmms! So I started up xmms and saw the original error, but xmms still allowed me to go into the menus. In Preferences, I found the following "Audio I/O Plugins" menu:


Under the "Audio I/O Plugins" menu, I found a Configure button specifically related to the ALSA sound output on my box. I clicked it:


Therein, I saw that the "Mixer Device" was indeed set to PCM. Well, look at that neat little arrow thingy next to PCM. Why, it's a pull-down menu showing me more choices! And look at that! There is a choice for the Audigy's "Analog Front" slider! Gee! Can I really select that? Why, of course! >:[

You'd never know that I've spent the last twenty years working with computers. And the final kick in the nuts was that even though I have the xmms-wma plugin installed, the WMAs didn't even play after I got xmms working properly! I received this error:
[root@localhost dell]# xmms ../beck1.wma
*** stack smashing detected ***: /usr/libexec/xmms terminated
Aborted

I'm too tired to resolve this issue tonight. But in sum, outside of my own stupidity..if you have a Creative Labs Audigy installed in your Fedora box and see the above error, do yourself a favor and use the Preferences->Audio I/O Plugins->Configure->Mixer Device to change PCM to Analog Front.

Good Night!
the stupid mule

ps - this is what I get for staying up until 3:30am the previous evening

multithreading in ffmpeg and the mpstat program

My new server, the Dell SC1430, is dual Xeon processor, quad core. Therefore, I have a full eight cores available for processing tasks. As I have recently completed a new install of FC6, 64-bit on this system, I've been focused on Cinelerra performance optimization. As an adjunct, I happened to notice that when I ran command line ffmpeg, only one of my processors was being used. I had thought that FFMPEG was multithreaded by default, so I was perplexed.

Chasing My Tail
Thinking it was a compile option that needed to be specified, I bounced a few ideas off my friend Graham and at the time, we were thinking "compile option." I googled FFMPEG_CFLAGS, ffmpeg smp and a host of other searches while sniffing down what was to be the wrong track. Taking a step back, I figured I'd try to find information from the source, rather than looking for just a command line option solution. I found from the FFMPEG site (http://ffmpeg.mplayerhq.hu/changelog.html) that that as of version 0.4.9-pre1, FFMPEG supports multithreading/smp for the following codecs:
- multithreaded/SMP motion estimation
- multithreaded/SMP encoding for MPEG-1/MPEG-2/MPEG-4/H.263
- multithreaded/SMP decoding for MPEG-2

OK. So it supports multithreading, but not for all codecs. The absence of multithreading of jpeg/mjpeg was a bummer. And when I ran the following conversion script to convert a DVD to a smaller format MPEG:
ffmpeg -i testdvd.mpg -target svcd output.mpg

I saw that only one of my processors was being utilized. Let's investigate this further.

mpstat to the rescue!
A new find for me is mpstat. mpstat is a program available in RedHat/Fedora that allows you to view the CPU utilization of each processor in your system. Nice! From its output, I saw that only one processor out of eight was being utilized:
[root@localhost ~]# mpstat -P 0 -P 1 -P 2 -P 3 -P 4 -P 5 -P 6 -P 7 4
09:51:21 AM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s
09:51:23 AM 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 6.00
09:51:23 AM 1 89.50 0.00 1.50 1.00 0.00 0.00 0.00 7.50 17.00
09:51:23 AM 2 7.00 0.00 0.50 0.00 0.00 0.00 0.00 93.00 3.00
09:51:23 AM 3 8.00 0.00 0.00 0.00 0.00 0.00 0.00 92.00 0.00
09:51:23 AM 4 5.50 0.00 0.00 0.00 0.00 0.00 0.00 94.50 250.50
09:51:23 AM 5 3.00 0.00 0.00 0.00 0.00 0.00 0.00 97.00 0.00
09:51:23 AM 6 5.50 0.00 0.50 1.00 0.00 0.00 0.00 93.00 0.00
09:51:23 AM 7 9.00 0.00 0.00 0.00 0.00 0.00 0.00 91.00 0.00

So something is wrong. As I was out of ideas, I finally decided to ask the folks who should know: the ffmpeg-users mailing list:
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

I soon received an answer from Lukas: the "-threads" option!

I tried the "-threads" parameter with various settings (1,2,8 threads). As I have eight processors, the limit was eight threads. If I used more threads than available CPUs, I saw this error at the bottom of the FFMPEG output:
[mpeg2video @ 0x3bfd518850]too many threads

So I then ran a couple of interesting tests.

TEST 1
Convert QT mov file to MPEG2 DVD

Syntax:
ffmpeg -i test.mov -threads 8 -target dvd output.mpg

In this test, the Quicktime file used MJPEG video compression scheme and is not supported for multithreading in FFMPEG. However, MPEG2 is supported.

From the output of top, I did see that process utilization increased slightly each time I increased the number of threads:
1 thread: 12.5% cpu used
2 threads: 14.7% cpu used
8 threads: 16.3% cpu used

However, when I looked at the output of mpstat, it showed the original behavior, whereby one processor was getting fed the entire task:
09:51:29 AM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s
09:51:31 AM 0 7.00 0.00 0.00 0.00 0.00 0.00 0.00 93.00 6.00
09:51:31 AM 1 95.00 0.00 1.00 1.00 0.00 0.00 0.00 3.00 10.00
09:51:31 AM 2 5.00 0.00 0.00 0.00 0.00 0.00 0.00 95.00 3.00
09:51:31 AM 3 7.00 0.00 0.50 0.00 0.00 0.00 0.00 92.50 0.00
09:51:31 AM 4 5.00 0.00 0.00 0.00 0.00 0.00 0.00 95.00 0.00
09:51:31 AM 5 3.50 0.00 0.00 0.00 0.00 0.00 0.00 97.00 250.50
09:51:31 AM 6 5.00 0.00 0.00 0.00 0.00 0.00 0.00 95.00 0.00
09:51:31 AM 7 3.50 0.00 0.00 0.00 0.00 0.00 0.00 96.50 0.00

Hmmm. On to test two:

TEST 2
Convert a DVD of high quality to smaller resolution mpeg2video

Syntax:
ffmpeg -i testdvd.mpg -threads 8 -target svcd output.mpg

In this test, both the source and destination codecs are supported for multithreading in FFMPEG. Now this is where the testing got fun. The output from mpstat was somewhat different this time:
10:00:28 AM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s
10:00:32 AM 0 22.50 0.00 0.50 0.00 0.00 0.00 0.00 77.00 5.00
10:00:32 AM 1 17.50 0.00 0.00 0.00 0.00 0.00 0.00 82.50 3.00
10:00:32 AM 2 23.00 0.00 1.50 0.00 0.00 0.00 0.00 75.75 0.00
10:00:32 AM 3 12.00 0.00 0.25 0.00 0.00 0.00 0.00 88.00 250.25
10:00:32 AM 4 29.00 0.00 1.25 0.00 0.00 0.00 0.00 70.25 0.00
10:00:32 AM 5 12.00 0.00 0.25 2.25 0.00 0.00 0.00 85.75 0.00
10:00:32 AM 6 71.25 0.00 3.25 4.00 0.00 0.00 0.00 22.00 17.00
10:00:32 AM 7 18.75 0.00 0.25 0.00 0.00 0.00 0.00 81.00 0.00

Sweet! Notice that all my processors are being utilized. Best part of all, my resulting render fps went from 48fps to 150fps. Awesome!

The Key Thing to Remember
So the key is that multithreading using the "-threads" option in FFMPEG only works when BOTH the source and destination files are of the supported types:
- multithreaded/SMP motion estimation
- multithreaded/SMP encoding for MPEG-1/MPEG-2/MPEG-4/H.263
- multithreaded/SMP decoding for MPEG-2

Remember this, Grasshopper.

And I am so very happy that I don't have to recompile..

thanks to Graham Evans and the ffmpeg-users mail list!
The Mule

related posts
http://crazedmuleproductions.blogspot.com/2010/01/batch-render-redux.html
/2010/01/compile-times-performance-improved.html