title sequence for birthday video complete..

Between writing doc to help myself and others on the Cinelerra list, I've finally produced some usable output. Check out my birthday video intro titles:
1.5MB

This is an mpeg4 quicktime vid. Mplayer/Xine should play it fine.

zoomed title

Well, this took way too long to do. Again with projector automation and manipulation of bezier curves. But, I figured I'd try it anyway. Nice little zoomed title
670K

first split screen..

I used the projector and camera automation to do my first split screen today:
split.mpg
670K

digging that Batch Render capability!

Since I wrote that document regarding Cinelerra's QT for Linux compatibility, Cin's batch rendering came in quite handy.

Things to watch out for:
1) make sure your output path is not only the directory, but the destination filename as well
2) clicking New will add that render to the list. Now you can highlight the batch item and tweak its settings (file format/audio/video/batch enabling) if need be.
3) make sure to Save List to save out the batch. Inevitably, you'll make a mistake the first time you setup a batch. So it's important to be able to reload it if Cinelerra crashes or you've forgotten something.




Here is an updated discussion of the batch render feature:
http://crazedmuleproductions.blogspot.com/2010/01/batch-render-redux.html

the mule

Quicktime for Linux compatibility chart

I spent Sunday afternoon and evening creating this compatibility chart for QT for Linux formatted files exported from Cinelerra. There are many compression schemes that can be used within this file format and I did not have a list to tell me what scheme works and what doesn't in Cinelerra and some default media players like Mplayer, Quicktime for Win and Windows Media Player 10. Hence the guide.

Enjoy!
html format
open office calc format

upgraded video workstation has arrived!

My video rig is finally ready to go! After one month of hardware and software upgrades, I'm ready to start editing. Here are the upgrades I did:
- from 1GB non-ECC, Dual DDR to 2GB ECC Dual DDR mem
- from a system and a content drive to a system and RAID0 content drive
- from a 128MB ATI video card to a 512MB NVidia video card
- from non-OpenGL to OpenGL editing software

Update (9/19): converted my old 80GB dual-boot XP/Core 4 system drive to shiny new 250GB SATA w/16MB cache! Took about seven hours to backup the filesystems, partition the new drive and restore, with a few lessons learned along the way. Here's how this went:
http://cacasodo.blogspot.com/2006/09/replacing-old-dual-boot-system-drive.html

So, we're ready to go with da editing! Hooray!!

Install notes:
- FC4 install
- fstab/ntfs kernel module/NVidia drivers/xorg.conf/mdadm.conf/rpmkeys/remove libdv/install libdv4
- libdvDeps.sh
- install cinelerra
- cinSourceDeps.sh
- create /mnt/win, /mnt/nt
- window prefs/google/cin window placemnet/save on exit

rebuilding the workstation: lost my damn RAID set!

I *almost* had a minor tragedy last night while rebuilding my Fedora Core 4 box. The *almost* tragedy occurred while reinstalling Core 4. While going through the process, I told the installer to use my existing RAID set, but do not reformat it. I figured what harm could come to the drive if it doesn't get formatted? Well, a lot, apparently. Since I was rushing through the install, I neglected to take proper care of the 40GB of MPEG2 files on the RAID set. Here's what happened.

After the FC installer finished, it asks to reboot the box, so I rebooted. On bootup, the system gave me errors regarding an unrecognized filesystem and dropped me to a filesystem shell to fix what was wrong. I didn't know what was wrong, so I rebooted into a linux rescue disk and simply took the RAID filesystem out of /etc/fstab and rebooted.

On the second bootup, I started fdisk to look at the drives. To my dismay, fdisk did not recognize the RAID set partitions. Agh! I did some preliminary research online. I came to the determination that I figured I had lost my data, though I did have it backed up. But it would be a pain to retrieve the 40GB or so of videos from my backup system. Damn it. So I bit the bullet and created new partitions of type "fd", a Linux RAID autodetect partition as I had done when I setup the RAID set initially. When I wrote the partition table, fdisk gave me some error saying that the drives will resync after the box reboots. I rebooted and looked at the output of "fdisk -l". Things seemed alright, as the drives were recognized as Linux RAID autodetect. So I then reenabled /dev/md0 in /etc/fstab and made sure that /etc/mdadm.conf was correct. Dejectedly I rebooted.

When the system started, it dropped me into a prompt complaining of filesystem problems again. Now what? This time, I looked at the man pages for fsck and figured out the commands I needed to repair the disk. They ran something like this:
fsck -t ext2 /dev/md0 -V -r
-t filesystem type
-V verbose
-r prompt for each repair

A couple of inodes were missing or corrupt. OK. Fsck seemed to continue on with the different stages of the five stage check procedure. About five or ten minutes of this, I was getting worried. Happily, it finished the checks and dropped me to a prompt in order to exit and reboot. OK..that's progress! Also, the box came up clean with no errors. Sweet. I now went to view the filesystem, and to my shock and surprise, my original files were there! Awesome!! But now the real test is reading from and writing to files. I first viewed one of the videos in mplayer. This worked! I then performed an extensive write test. Cinelerra needs table of contents files for each video. These are index file, essentially. So at a prompt, I generated a bunch of toc files for the 30GB or so of video I had by using this one command:
for i in `ls -1 *.m2t` ; do echo $i ; mpeg3toc $i $i.toc ; done

The file creation took about twenty minutes but worked! I then loaded the files into Cinelerra, started editing and wouldn't you know they are good to go! Hooray! But I'm still an idiot.

Moral of the story is make sure you do your research on RAID before you decide to implement it.

ATI OpenGL 2.0 implementation incomplete..hello NVidia!

Sad to say, but all you ATI lovers (like I USED to be) are in for a rude surprise with ATIs' "OpenGL2.0" Linux driver implementation. After 1 1/2 days of finally getting my ATI All in Wonder 9800 Pro to actually use Direct Rendering and OpenGL2.0 and see it working well (5000FPS on glxgears), it was very disheartening to find out that ATI had not provided the proper 2.0 hooks for Cinelerra to use. Specifically, programming hooks like glDeleteShader were not implemented. The troubleshooting was quite informative, as I am not an active C programmer.

The solution was typical of today's PC market. If it don't work, buy one that does! So I went to B&H Photo and bought a BFG nVidia GeForce 7600GS, 512MB. Twenty minutes after getting home, the card was in the box, drivers were compiled, installed and working. Fifteen minutes after that, Cinelerra was compiled and I was using OpenGL2.0! Yeehoo!! And at twice the playback speed of what I was getting previously with the ATI card. I will report back on the performance of this card once I actually USE it.

openGL acceleration for Cinelerra not working just yet

Well, I spent all Sunday and Monday reconfiguring my workstation for hardware rendering (as detailed here), but my recompile of the latest Cinelerra code blew up on some obscure header file. Hopefully, the smart fellows on http://cvs.cinelerra.org can help out.

tracing a specific path using camera automation

For my Paris video, I wanted to simulate our walk of the city by panning an old map of Paris highlighted with the streets we traveled. To do this, I imported a series of large (2800x2100) still images created in Gimp and used camera automation to simulate movement. The camera automation needed to be very specific to trace our path. Thus, I had to get the X,Y coordinate pairs of each point I wanted the camera to center upon. The hurdle I encountered is that the origin of the X,Y coordinate system used in Gimp is at the upper-left hand corner of the image, whereas the origin of an image or video imported into Cinelerra is at the center of the image. So I had to do a conversion.

For an image that is 2800x2100:
(0,0) in Gimp is (-1400,-1050) in Cinelerra
(1400,1050) in Gimp is (0,0) in Cinelerra
(2800,2100) in Gimp is (1400,1050) in Cinelerra

Hence, in Gimp, all X/Y values are positive, but in Cinelerra, X and Y can have negative values.

Most of the camera automations to simulate our walk required about four coordinate pairs; hence, four conversions:
1) origin
2) first leg of walk
3) second leg of walk
4) destination

As you can see, when I wanted to change the speed or direction of the pan, the conversion of coordinates got a bit tedious. Also, I varied the movement of some of the camera automations so that not all were bezier curves, but more linear. As noted in an earlier post, this can be accomplished by displaying the X and Y camera positions and using CTRL-click on the vertices to "pull" the curves straight. This takes a little getting used to and is very time consuming. Note that there will be two sets of "pull" vertices on either side of the actual X/Y positions that you can adjust to straighten the curve slope.

But the result is quite pleasing:
ParisRoutes
55MB

outputting HDV from Cinelerra

Update 9/10/06:
This procedure doesn't work. The working one is listed here:
/2006/11/cam-compatible-hdv-edit-chain-part-ii.html

Do it with FFMPEG:

Audio and Video Mux Example:
ffmpeg -i jpegphoto.mov -f mpegts -vcodec mpeg2video -aspect 1.777 -b 18300 -r 29.97 -s 1280x720 -acodec mp2 -ac 2 -ab 384 -ar 48000 output.m2t

Container/File Format:
-f mpegts

Video
-vcodec mpeg2video
-aspect 1.777
-b 18300
-r 29.97
-s 1280x720

Audio
-acodec mp2
-ac 2
-ab 384
-ar 48000