Green Beret parachutes in to help Cinelerra

Unbelievably, just in the past week, the Cinelerra CV community (http://cvs.cinelerra.org/) has had a heavyweight developer parachute in and start fixing stuff all over the place. The guy is Chris "Monty" Montgomery who developed the Ogg multimedia container and Vorbis audio formats (http://en.wikipedia.org/wiki/Chris_Montgomery). He is a developer currently working for Red Hat.

Monty, You're The Man!
His primary effort has been to yank out the kludgy and incompatible file loader in Cinelerra and replace it using good old FFmpeg. FFmpeg has problems of its own, but a helluva lot less problems than the Cinelerra loader. This is a task that the original developer of Cinelerra, Heroine Warrior (http://www.heroinewarrior.com/), has wisely done with the 4.1 version of Cinelerra. Much props to Father HV, for without him, this blog and Open Source video editing would be very different, if exist at all.

Monty is patching the version of FFmpeg that comes with the Cinelerra CV source code (http://cinelerra.org/getting_cinelerra.php). In Cinelerra CV's source code tree, FFmpeg is found under quicktime/ffmpeg. This means that once you compile Cinelerra from source code and add Monty's code fixes, files like the Canon 5D/7D H264 AVC files (the 1080P files spat out of the Canons') will load natively in Cinelerra.

AVC, oh AVC, Why Are You So Stubborn?
Problem here is that you can't really edit with AVC files because the decoding of them is so bloody CPU intensive. AVC playback in Cinelerra on my dual, quad core Dell SC1430 with 10GB RAM is 3-4fps. This is unacceptable for previewing edits. There is a workaround to this such that if you really wanted to edit AVC, you'd need to have background rendering enabled, make your edits and then wait for the background render to finish. But that bg render takes a long time too. You could speed this up to by creating a ramdisk (http://www.techanswerguy.com/2009/02/creating-ramdisk-in-linux.html) and setting the background render to use that ramdisk. But that's a whole other task.

Transcoding Canon 5D/7D Files, as usual
Thus, we're still left with the task of transcoding Canon 5D/7D files into a more compatible format. There are two solutions:
1) get my varied MPEG-TS conversion magic to work for you (http://crazedmuleproductions.blogspot.com/2009/02/dark-of-winter-has-me-in-its-grasp.html)
2) convert the 5D/7D files using FFmpeg into another format that works since FFmpeg is now Cinelerra's loader (with Monty's additions)

Both require research/work, but I did a quick conversion that I tested in Cinelerra with Monty's code additions:
ffmpeg -i [inputFileFromCanon] -acodec mp2 -ar 48000 -ab 384k -ac 2 -vcodec mpeg2video -qscale 1 [outputFile]

The audio format is mpeg, layer II and the video format is mpeg2video. This loads in Cinelerra and is fast to edit with. Once edited, render out from Cinelerra as usual.

How to Compile Cinelerra for Ubuntu and Fedora users
So Monty's additions require compiling from source. I'll provide some quick links here. For Ubuntu folks, Raffaella Traniello has put a nice post together on how to compile Cinelerra in Ubuntu:
http://www.g-raffa.eu/Cinelerra/HOWTO/compilation.html

For Fedora users, I have a post here:
http://crazedmuleproductions.blogspot.com/2010/02/fedora-12-x86-64-cinelerra-install.html

Get Monty's Additions Working
Once you get the source code compiled, install it (make install) and just test that Cinelerra works at a basic level. Once you've tested that your compile has worked, move onto apply Monty's code additions:
- remove your installed Cinelerra (make uninstall)
- download Monty's additions at http://people.xiph.org/~xiphmont/cinelerra/patches/
- apply each of them to the Cinelerra source code tree one at a time (git apply [patch name])
or join in Monty's git branch:
1) git remote add xiphmont git://git.xiph.org/users/xiphmont/cinelerraCV.git
2) git remote update
- compile Cinelerra, this time with all Monty's additions (make clean;make;make install)

After starting CinCV with Monty's additions, you should see the startup info change:
[mule@ogre my_cinelerra]$ cinelerra
Cinelerra 2.1CVxiphmont
GIT::8c01c13bbb21d30aff2733454a49fbfe641e51ca
(C) 2006 Heroine Virtual Ltd.
(C) 2006-2010 The CinelerraCV Community
Internal ffmpeg 0.6+fixes
Compiled on Fri Jul 16 20:40:38 EDT 2010

As well, you should see that FFmpeg becomes the default loader for videos in you goto the Resources window, right-click on a video and click "Info". You should see FFMPEG there under File Format:


A Few Git Notes..
While I'm at it..

View current git branches
[mule@ogre my_cinelerra]$ git branch
* master

Add Monty's remote branch
[mule@ogre my_cinelerra]$ git remote add xiphmont git://git.xiph.org/users/xiphmont/cinelerraCV.git

Update the local copy of Monty's remote branch
[mule@ogre my_cinelerra]$ git remote update
Fetching origin
Fetching xiphmont
remote: Counting objects: 2754, done.
remote: Compressing objects: 100% (1904/1904), done.
remote: Total 1981 (delta 997), reused 0 (delta 0)
Receiving objects: 100% (1981/1981), 2.77 MiB 1.07 MiB/s, done.
Resolving deltas: 100% (997/997), completed with 711 local objects.
From git://git.xiph.org/users/xiphmont/cinelerraCV
* [new branch] master -> xiphmont/master


Check that Monty's branch has been added
[mule@ogre my_cinelerra]$ git branch
* master
xiphmont

I then was able to switch branches
[mule@ogre my_cinelerra]$ git checkout -b xiphmont xiphmont/master
Branch xiphmont set up to track remote branch master from xiphmont.
Switched to a new branch 'xiphmont'


"git branch" shows that I have switched to Monty's branch
[mule@ogre my_cinelerra]$ git branch
master
* xiphmont

Now I can switch easily between branches (Monty's and CinelerraCV)
[mule@ogre my_cinelerra]$ git checkout master
Switched to branch 'master'


Switching to Monty's branch
[mule@ogre my_cinelerra]$ git checkout xiphmont
Switched to branch 'xiphmont'


Show the current status of the git code repositories
[sfrase@ogre my_cinelerra]$ git status | head -6
# On branch xiphmont
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# cinelerra-cvs-current.spec
# cinelerra/.deps/
>


View the latest change log
[mule@ogre my_cinelerra]$ git log xiphmont/master | head -6
commit 8c01c13bbb21d30aff2733454a49fbfe641e51ca
Author: Monty
Date: Fri Jul 16 07:30:10 2010 -0400

iAlter/extend versioning to avoid any confusion between this temporarily
forked version and the main CinelerraCV repo

Pull in the latest code updates:
[mule@ogre my_cinelerra]$ git pull


Troubleshooting
I tried to switch branches and got this error
[mule@ogre my_cinelerra]$ git checkout -b xiphmont xiphmont/master
error: You have local changes to 'po/de.po'; cannot switch branches.

I did a hard reset to clear the above error
[mule@ogre my_cinelerra]$ git reset --hard HEAD
HEAD is now at d95887f Pass --libdir given to configure on to ffmpeg configure.

Last resort for repos not working, a destructive clean:
[mule@ogre my_cinelerra]$ git clean -dfx



Update 2010/07/16
Looks like the YUV4MPEG render stream is broken..this simple render pipe outputs a file unreadable in FF
ffmpeg -f yuv4mpegpipe -i - -y -target dvd -f mpeg2video %

I talked to Monty and he will fix..something about colorspace converter.
*** end update ***

Note that you have to compile Cinelerra and do a full reinstall, as the Cinelerra "make" process hard links the installation directory into the cinelerra executable.

So I hope Monty stays with us as long as possible. Thanks man! Hope springs eternal!
the mule

References
http://www.itworld.com/open-source/115063/breaking-open-video-frontier-despite-mpeg-la

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.

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

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

first impressions: Cinelerra on dual, quad core Dell SC1430

I'm on my dual, new quad-core, 64-bit FC6 box (woah!) and I'm happy to say that I've got Cinelerra running, with some minor speed bumps along the way (read /2007/09/building-cinelerra-on-fc6-64-bit.html and
http://www.techanswerguy.com/2007/09/setting-up-dell-sc1430.html

Update 2008/02/03
Here are some related articles:
/2007/10/multithreading-in-ffmpeg-and-mpstat.html
/2007/10/rendering-on-dual-quad-core.html
*** end update ***

Eight Core Power!
I see from the output of /proc/cpuinfo, that I've got eight processors (first and last listed below):

[root@localhost ~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5310 @ 1.60GHz
stepping : 7
cpu MHz : 1595.929
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm
bogomips : 3195.17
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
...
processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5310 @ 1.60GHz
stepping : 7
cpu MHz : 1595.929
cache size : 4096 KB
physical id : 1
siblings : 4
core id : 3
cpu cores : 4
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm
bogomips : 3191.96
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:


HDV Render Test: Project with no effect
Now that I've got her up, I'm testing a render of 40 minutes of MPEG-TS HDV content. While rendering, it seems that my CPUs are sloughin about..only about 30% busy. What is going on here? Shouldn't all the CPUs be working at 100%?


Here is the output of iostat, showing 70% idle CPUs:
Time: 12:14:23 AM
avg-cpu: %user %nice %system %iowait %steal %idle
27.75 0.00 0.60 1.00 0.00 70.65

Time: 12:14:28 AM
avg-cpu: %user %nice %system %iowait %steal %idle
27.35 0.00 0.37 0.95 0.00 71.33

Top seems a little funny too, whereby the third line down shows 27.4%, near what iostat reports, but then the listed CPU utilization for Cinelerra is about 220 in the process list below:

top - 00:15:42 up 46 min, 4 users, load average: 2.83, 2.35, 1.82
Tasks: 186 total, 2 running, 184 sleeping, 0 stopped, 0 zombie
Cpu(s): 27.4%us, 0.4%sy, 0.0%ni, 70.9%id, 1.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2055048k total, 2038468k used, 16580k free, 736k buffers
Swap: 4562440k total, 632k used, 4561808k free, 514344k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5640 root 17 0 3170m 1.0g 45m S 220 53.2 41:39.23 cinelerra
3540 root 15 0 183m 89m 34m S 1 4.4 6:43.95 Xorg

I will investigate that inconsistency later.

The render finished in about 50 minutes, so that's a little bit longer than Heroine Warrior's assertion that encoding HD content with a 64-bit system should be in realtime:
http://www.heroinewarrior.com/cinelerra7.php3

HDV Render Test 2: Project with Oil Painting effect
So then I ran a Cinelerra project with a more computationally intense render (one with an Oil Painting effect applied to an HDV track), CPU utilization is now up to 80-90% per cpu (attached graphic):


Here's the test video:


Analysis
There are many cores and they are relatively low speed (1.6Ghz). As Cinelerra takes advantage of all the processors, each CPU is working on a task (the render) and those tasks process at the speed of each corresponding CPU. In other words, as fast as each individual processor can handle. So simple tasks, like rendering raw HDV video with no effects, don't take up much individual CPU. However, more computationally intense tasks, like adding the oil painting effect to a video, utilize more of each CPU. Thus, the video rendered with the oil paint effect takes more CPU horsepower than the simple, no effect render.

This server is kind of like having a big dump truck. The thing has a powerful engine and can haul a ton of stuff, but can't go very fast. Unlike a Ferrari that can't handle much luggage, but can go super fast. I think we might see that a box with faster CPUs would get simple renders done quicker than what my Dell can do, but it might choke on renders with lots of complex effects.

Now if I could only harness these CPUs for speed! I'd be interested in getting people's opinions on 64-bit and multicore operation, as this is my first multicore/64 system.

Other Observations on 64-bit Fedora Core 6
1) I see that command-line ffmpeg is not multithreaded for multi processing machines. I will have see if I can use the external ffmpeg compile option in Cinelerra.
2) I can't get an NVidia card to work in this box. Much pain listed here:
http://forums.anandtech.com/messageview.aspx?catid=31&threadid=2080542
3) The Adobe Flash plugin only works in 32-bit mode Firefox

more to come,
the crazed mule

building Cinelerra on FC6 64-bit

Update 10/26/2007:
These instructions work well for F7 (Fedora 7), 64-bit, too!

Update 10/29/2008:
These instructions still kick ass..a year later when I blew up my system!

Update 11/20/2008:
I've rebuilt my Fedora 7 system as Fedora 9. The Cinelerra build instructions are different than the Fedora 7 instructions in that they use ATrpms repository. But all-in-all, the install went well!

I just purchased a Dell SC1430 dual Xeon, quad-core server to replace my aging Dell SC400 tower. I will give a full review of that server in a later post. More immediately however, I thought I'd give the 64-bit Fedora Core 6 installation a whirl, as these Xeons support 64-bit. I figured that Cinelerra should fly with 64-bit install! Also, to ease my pain, I figured I'd stay with FC6, as I'm well familiar with this distribution. Eventually, I'll build out a 64-bit Debian Lenny distro to see how that performs (thanks for the suggestion, Graham)!

Here's How Things Went
The Fedora install is the same installer you get with the 32-bit version and went very smoothly.

I then proceeded to install the dependencies for building Cinelerra from source. In a nutshell, the yum installation was very similar to my 32-bit FC6 install which I described here, with some minor differences:
/2007/03/fedora-core-6-cinelerra-dependencies.html

The quick steps are:
1) have the proper yum repositories online (all Fedora, Livna and Dries)
2) make sure you have your GPG-KEYs loaded from Livna and Dries
3) remove the dries repositories (with the --disablerepo=dries switch shown) and install using the script below with only Fedora and Livna online:
4) remove the Livna repositories, enable FreshRPMs and install mjpegtools using the command:
yum --disablerepo=livna install mjpegtools*
5) get Cinelerra source code (refer to previous post on those details)
6) build from source (refer to previous post on those details)
7) install your favorite multimedia applications

The only differences between the 32-bit install and the 64-bit install that I noticed were that I had to specify the install of fftw specifically on 64-bit:
1) fftw (instead of fftw3)
2) fftw-devel

I've amended the script below to reflect those differences. Another interesting note is that with FC6 and above, no SMP-specific kernel is necessary. This is good! Finally, I installed my favorite multimedia apps:
yum install avidemux mencoder mplayer transcode vlc* xmms

However, to avoid this error, you should install xine separately without Livna repos online:
yum --disablerepo=livna install xine

I haven't gotten to really test out Cinelerra's capabilities on 64-bit, but I did render out a 40 minute Cinelerra project with full 720P HDV in a little over an hour. I rendered using QT container, MPEG-4 video compression with a constant bit rate of 10,000,000 and twos complement audio. This *almost* achieves what Heroine Warrior states about being able to achieve real-time rendering with HDV. Obviously, I believe some performance tweaks are in order and will need to work through these issues.

Here is that yum script which should get you going on 64-bit Fedora Core 6:

The Cinelerra FC6 64-bit Source Dependencies Install Script
yum install --disablerepo=dries \
libquicktime \
ffmpeg \
gsm-devel \
xvidcore* \
lame \
lame-devel \
libvorbis* \
libogg* \
libtool* \
a52* \
libtheora* \
libpng* \
libjpeg* \
libtiff* \
esound* \
audiofile* \
libraw1394* \
libavc1394* \
freetype* \
fontconfig* \
nasm \
e2fsprogs* \
faad2-dev* \
OpenEXR* \
fftw \
fftw-devel \
libsndfile* \
libiec61883* \
x264 \
x264-d* \
faac* \
libdv*

Don't forget to chmod a+x the file!

cheers,
the mule