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

dreaded x264 compile error: 'struct ' has no member named 'b_cbr'

For fun, I built out a virtual Fedora Core 6 machine with Cinelerra and all supporting apps installed to share with the world (fedora-core-6-virtual-cinelerra-machine.html). During the process, however, I received an error while compiling the package:

 gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DHAVE_AV_CONFIG_H -I./.. -g -O2 -MT x264.lo -MD -MP -MF .deps/x264.Tpo -c x264.c  -fPIC -DPIC -o .libs/x264.o
x264.c: In function 'X264_init':
x264.c:139: error: 'struct ' has no member named 'b_cbr'
make[5]: *** [x264.lo] Error 1
make[5]: Leaving directory `/opt/hvirtual/quicktime/ffmpeg/libavcodec'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/opt/hvirtual/quicktime/ffmpeg/libavcodec'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/opt/hvirtual/quicktime/ffmpeg'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/opt/hvirtual/quicktime'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/opt/hvirtual'
make: *** [all] Error 2

Good Lord! What is this? When I did my first Cinelerra CVS install back in April (fedora-core-6-cinelerra-dependencies.html), I didn't encounter this error. And I was only using the same dries, livna and standard Fedora repositories. So something must have changed with the repositories between the beginning of April and now, early June. But what gives with the compile failure?

No sense complaining about it. Let's just see if someone else has encountered it and we'll fix it. Sure enough, folks on the Ubuntu boards had seen it:
http://ubuntuforums.org/showthread.php?t=215252

Essentially, the problem is that the version of Cinelerra is incompatible with the version of x264. The x264 from Livna is rev. 537 and Cinelerra is version 2.1 (at this time, rev. 1009). We'll use x264 rev. 536 to alleviate the problem.

The solution is hard to pick through on that forum posting, so I will condense the steps to fixing it here:
1) uninstall x264
2) download x264 revision 537
3) compile x264 with specific options
4) reinstall packages that were removed when we uninstalled x264
5) install x264 program files
6) patch directories in the Cinelerra source tree
7) configure Cinelerra with specific options
8) compile Cinlerra and hopefully, install!

1) uninstall x264
yum remove x264

This will remove a bunch of other packages:
Running Transaction
Removing : mjpegtools ####################### [ 1/10]
Removing : mjpegtools-devel ####################### [ 2/10]
Removing : mjpegtools-libs ####################### [ 3/10]
Removing : ffmpeg ####################### [ 4/10]
Removing : ffmpeg-libs ####################### [ 5/10]
Removing : x264 ####################### [ 6/10]
Removing : mencoder ####################### [ 7/10]
Removing : x264-devel ####################### [ 8/10]
Removing : libquicktime ####################### [ 9/10]
Removing : mjpegtools-gui ####################### [10/10]

Don't worry, we'll replace them in Step 4.

2) download x264 revision 537
Assuming you have subversion installed, go get rev 536 of x264:
svn checkout svn://svn.videolan.org/x264/trunk x264 -r536

3) compile x264 with specific options and make the x264 program files
From the directory in which you downloaded the x264 source code, run:
./configure --extra-cflags=-fPIC --extra-asflags=-D__PIC__
make

4) reinstall packages that were removed when we uninstalled x264
yum --disablerepo=dries install ffmpeg libquicktime mencoder mjpegtools*

Note that I have the Fedora Core, Extras, Updates, Livna and Dries repositories only listed in yum when I run the install.

Here we see the final result of the install:
Running Transaction
Installing: x264 ######################### [1/9]
Installing: ffmpeg-libs ######################### [2/9]
Installing: ffmpeg ######################### [3/9]
Installing: libquicktime ######################### [4/9]
Installing: mjpegtools-libs ######################### [5/9]
Installing: mencoder ######################### [6/9]
Installing: mjpegtools ######################### [7/9]
Installing: mjpegtools-devel ######################### [8/9]
Installing: mjpegtools-gui ######################### [9/9]

Notice that installing the programs will also the bad version of x264. In the next step, I will overwrite the program files of the conflicting version of x264 with the working, rev. 536 version.

5) install x264 program files
In the directory you compiled x264, run:
make install

Doing this, I have overwritten the conflicting version of x264 with the one that works with Cinelerra.

6) patch directories in the Cinelerra source tree
In the Cinelerra source tree directory, hvirtual, create these missing directories and fill with appropriate files:
mkdir plugins/chromakey-hsv && cp plugins/chromakeyhsv/* plugins/chromakey-hsv
mkdir plugins/seltempavg && cp plugins/denoiseseltempavg/* plugins/seltempavg/

Take a look at them to make sure they exist and have files in them:
[root@localhost hvirtual]# ls plugins/chromakey-hsv/
chromakey.C chromakey.h Makefile Makefile.am Makefile.in picon.png picon_png.h
[root@localhost hvirtual]# ls plugins/seltempavg/
Makefile Makefile.in picon_png.h seltempavg.C seltempavgwindow.C
Makefile.am picon.png restart_marker.png seltempavg.h seltempavgwindow.h

7) configure Cinelerra with specific compiler options
./configure --with-pic

for Ubuntu 64-bit users, this configure syntax may need to change to this:
./configure --with-pic --disable-shared --enable-static

I cannot confirm this as I am not an Ubuntu user.

To explain: as a general rule, Cinelerra themes and plugins are loaded dynamically as modules. If static linking is defined (the --enable-static part of the command), the SUV theme will not get built as it is not designed for static linking in the CVS tree. A corrolary to this is that if you disable shared libraries (the --disable-shared part of the command), the SUV theme also doesn't get built. My testing on FC6 bears this out.

The unfortunate thing is that if the SUV theme is not built, you'll get this nasty error when you try to startup Cinelerra and the program won't start for love or money:
MWindow::init_theme: theme S.U.V not found

I have not found a workaround, so if at all possible, do not use those two switches in your configure command.

8) compile Cinlerra and hopefully, install!
make
make install

These steps fixed my problem. Hopefully, they will fix it on your system.

Good luck!

Cinelerra compile problem solved, more or less..

To follow up on this thread from a few weeks back, through a fair bit of reading and educated(?) guessing, I was able to get around this problem that stymied me.

One of the guys on the Cinelerra boards did clue me into the fact that the aclocal.m4 file was much too short, as it should be a superset of /usr/share/aclocal/libtool.m4. So that gave me a start. After reading a bit of doc and problem postings in Google regarding aclocal.m4, I saw that the file listing of hvirtual/m4 was about half as long as the list of *.m4 files in /usr/share/aclocal. So, I edited autogen.sh to point aclocal to build aclocal.m4 from the files in /usr/share/aclocal, rather than using the m4 directory under hvirtual. After running autogen, I then had a complete aclocal.m4 file with a libtool section. I did not have the libtool section in the file before building from /usr/share/aclocal.

I don't know what side effects this has, but the CVS compiled and I can playback and render video from my saved projects, so I assume this is a valid solution. The only side effect I've noticed so far is that I get a few more ALSA underruns like this:
AudioALSA::write_buffer underrun

ps - here's some doc I found that may help someone in a similar predicament:
re automake:
http://www.delorie.com/gnu/docs/automake/automake.html#SEC_Top
re libtool:
http://people.debian.org/~keybuk/libtool-updating.html

Unsuccessful compile from CVS source

Today was a frustrating one. Tried to get the latest CVS build of Cinelerra (cvs.cinelerra.org) compiled on my Dell 400SC running Fedora Core 4. No go. I'm not the best at compiling beyond "configure, make, make install", so the process of autogen, aclocal and autoreconf were new to me.

A couple things learned:
- running aclocal creates an aclocal.m4 file. In order to make sure you are pointing to the correct macros within the build files, you need to make sure to point to m4 using:
aclocal -I m4

- the aclocal.m4 file should be larger than /usr/share/aclocal/libtool.m4, because aclocal.m4 is a superset of /usr/share/aclocal/libtool.m4.

If you have trouble compiling Cinelerra, try running autoreconf -i --force.

That's about it for tonight. I'm off to see if my 48Khz audio will match to my 48Khz video! Yeehoo!

talk to you later!