Crazed Mule Productions

ffmpeg pipe to mpeg2enc

2009-05-18T10:50:00.011-04:00

Occasionally, I'll need to send a video stream into mpeg2enc. Mpeg2enc doesn't take an input file; it only accepts a yuv4mpeg stream. In order to send a yuv4mpeg stream to mpeg2enc, I do this using ffmpeg and the -f yuv4mpegpipe command line switch. Also, for best quality, I will send the stream using the FFMPEG variant of the Huffyuv lossless compression algorithm. ffyhuff is an enhanced version of Huffyuv that compresses better than Huffyuv.

Update 2009/05/19
As per Dan Dennedy's comment below, ffmpeg's yuv4mpegpipe command will ignore the -vcodec option and pipe the video stream to mpeg2enc using an uncompressed C420jpeg stream, which is an uncompressed YUV format. Certainly good enough for the likes of me!
*** end update ***

Here is a sample command to reencode a 720P video stream as a yuv4mpeg pipe to mpeg2enc:
ffmpeg -threads 4 -i INPUT.M2V -f yuv4mpegpipe - ¦ mpeg2enc --verbose 0 --multi-thread 4 --aspect 3 --format 3 --frame-rate 4 --video-bitrate 18300 --nonvideo-bitrate 384 --interlace-mode 0 --force-b-b-p --video-buffer 448 --video-norm n --keep-hf --no-constraints --sequence-header-every-gop --min-gop-size 6 --max-gop-size 6 -o OUTPUT.M2V

Note that I am taking advantage of the eight processors in my dual quad core using the multithread switches in the commands to both ffmpeg and mpeg2enc. Note that the eight threads have been split evenly, four to each encoder, to avoid CPU context switching. (Thanks again, Dan!)

As a final note, I am a bit confused on the differences between FFMPEG compression algorithms: ffyhuff and ffv1. If someone has pointers to the documentation on these, I'd be interested in finding out more. A google search just added to my confusion.

the mule

References
mpeg2enc man page
ffmpeg vs mpeg2enc
Huffyuv
FFV1

VMware virtual appliance for video editing

2009-05-13T11:18:00.002-04:00

Over the weekend, I created a VMware Partner Account and got my Fedora 10, x86-64 virtual machine approved to be listed on VMware's Virtual Appliance listings:
http://www.vmware.com/appliances/directory/148183

If you want to try out Cinelerra and you use 64-bit VMware Player, Workstation or Server, this is an easy way to get started. I'd appreciate someone giving it a shot and letting me know how it works.

the mule

presentation at TCF, 4/25/09

2009-04-24T11:28:00.011-04:00

Got my presentation worked out for the Trenton Computer Festival (http://www.tcf-nj.org/web/) tomorrow. It looks ugly, but the content of the presentation should outweigh the aesthetic of the slides:

Video Production Using Open Source Tools

View more presentations from Crazed Mule.

http://www.slideshare.net/crazedmule/video-production-using-open-source-tools

Update 2009/5/15
Here are a few pics from the talk.

The Mule in front of a LARGE display (only got to 1024x768 resolution, though).

A rapt audience.

The Mule making an important point.

Definitely had some fun, with a little help from my buddy Ironlung on the Mark II 5D.
*** end update ***

The Mule

animated route in Cinelerra

2009-04-05T10:25:00.012-04:00

This was fun. I spent the day perfecting a way to automate a line on a map in Cinelerra. You might think that was a somewhat pedantic exercise, but I think the image I used was very pretty and that the moving line, ala Raiders of the Lost Ark, came out great. What would make it even better would be to use an ancient map of some sort.

Here it is:

a line on a map from crazed mule on Vimeo.

Update 2009/04/07
For some reason, this video is not playing as embedded on this page. Please visit my crazed mule profile on Vimeo to view.

Thanks!
*** end update ***

Using Gimp to Spice Things Up
I created the graphics in Gimp:
-the line representing the route and its shadow
-the circle representing the route's start
-the star representing the route's end

The circle and the star were created using Gfig, the Gimp add-on utility that let's you create geometric shapes. Also note that the shadow of the line matches the position of the light source in the photo of the globe.

Note that the circle and the star are not flat, 2D creations, but they look like stickers pasted on the side of the globe. I acheived that effect by using Gimp's Perspective and Shear tools. Here's a resource that discusses Perspective in Gimp:
http://gimp-university.blogspot.com/2008/03/perspective-and-layers.html

I created four images to import in Cinelerra:
1) globe with no Gimp object overlays
2) globe with just the circle as start of route
3) globe with the circle and the line
4) globe with the circle, line and star representing the full trip

Assembling the Images in Cinelerra
The tracks in Cinelerra looked like this:
Top Video Track
image 1 (plain globe) at beginning of timeline and image 4 (all objects) at end of timeline
Bottom Video Track
image 2 (globe and circle) and image 3 (globe, circle and line)

Gradient Created for Line's Movement
The key to the movement of the route was a screen wipe that travelled from the upper left corner of the screen to the lower right, mimicking the direction of the line's travel. Since Cinelerra does not have a built in wipe that moves in this direction, I had to create my own gradient using Gimp and plop it in /usr/local/lib/cinelerra/shapewipe. I then used that gradient in the Shape Wipe video transition tool:

In the timeline picture above, you can see the Shape Wipe transition effect that I used between the image of the map with the circle and the image of the map with the circle and the line.

Here are some resources on wipes and making your own wipe in Cinelerra:
http://cvs.cinelerra.org/transitions.php
http://www.mail-archive.com/cinelerra@skolelinux.no/msg05664.html
http://akiradproject.net/your_own_transition
http://cvs.cinelerra.org/images/

I love the way this turned out, because it looks a s*1tload better than most of the other animated routes I've seen out there. In fact, it blows away the lame route create with Photoshop and After Effects that I read about in VideoMaker magazine this month.
http://www.videomaker.com/article/14206/

enjoy,
the mule

motion stabilization tutorial

2009-03-14T20:50:00.024-04:00

After reading Jacob's post today:
http://jakedth.tumblr.com/post/85794790/cinelerra-cv-motion-tracking-tutorial

I realized I never mastered a repeatable method to stabilize shakey video using Cinelerra's motion tracking tool. The Motion effect is very powerful, but also difficult to understand. At least for me. In addition, the manual isn't much help because it is couched in confusing terminology.

The motion tracker can do a lot of different things. However in this post, I am going to keep it simple and only describe how to stabilize shakey video. I made it easy for myself and chose a sample piece of video that bounces around pretty badly:

This movement left and right and up and down is called Translation. Or to a programmer, movement on the Cartesian Coordination System. Before we get into further discussion, familiarize yourself with what the manual says about the motion tracker:
http://heroinewarrior.com/cinelerra/cinelerra.html#MOTION

What You Need to Make It Work
Since the manual's description of motion tracking is cryptic, I'm going to try to clarify the muddy waters. In order to stabilize a section of video, you're going to need a few things:
1) a easily identifiable object in your video that will be used to track motion
2) a box that encircles that object. The following is important: this box needs to be wide and tall enough to encompass the range of motion of the shakey video.
3) a video track (master layer) with the range of motion that needs to be stabilized
4) a video track (target layer) that will be stabilized

I would suggest starting small. Just try stabilization with a clip of video that is short (<10seconds) and needs stabilization throughout.

Step 1: Apply the motion effect to the video track you want to stabilize
Like so:

Step 2: Open the Motion tracker effect dialog.
In order to simplify the configuration process for the motion tracker, I've divided the configuration box into the only three sections you'll need to worry about:

Step 3: Enable Draw Vectors (in Section 2 of the graphic above)
You may leave Track Single Frame selected. Also, Frame Number set to 0 means that the motion tracking of your video will start at the beginning of the timeline.

Step 4: Use Translation Block and Search Radius and Block X/Y to fit a box around an easily identifiable object in your video that will be used to track motion (in Section 1 of the graphic above)

In the above picture, you'll notice there are two boxes around the Budweiser sign. The center box around the Budweiser sign is the Translation Block. You'll make the Translation Block fit neatly around the object you're tracking. The outer box is the Translation Search Radius. For the purpose of this tutorial, we'll make the Translation Block always fit within the Translation Search Radius. Below is a graphic depicting these components:

The Translation Search Radius needs to be as large as the range of motion of the video. In other words, the Search Radius needs to be large enough to accommodate all the shaking of your video. If the shaking extends beyond that box, strange things happen, like the motion tracker will start tracking another object in your video. Remember that.

Finally, Block X and Block Y represent the X/Y coordinate location of where you will move your Translation Search Radius.

In sum, you will configure those objects just discussed in the Motion Tracker effect dialog. To review:
1) Encircle the object you want to track with the Translation Block
2) Encompass the entire range of motion of your shakey video inside the Translation Search Radius
3) Use the Block X and Block Y coordinates to move the Translation Search Radius (including the Translation Block) around the screen

It is cumbersome to move the boxes around and X/Y coordinate plane using a round dial. The Translation Block and Search Radius should be drag and drop. The motion tracker interface can definitely be improved upon in this respect.

Step 5: In Section 3 of the Motion config screen, set Action to Track Pixel and set Calculation to Save Coordinates to /tmp
The reason why we do this is that we are going to Track the motion of the video around our selected object (the Translation Block). The coordinates of the movement will be saved in temporary files, which we will later apply to a second track.

You may now either playback the video or render out a test video to see the results of the motion tracking. As the motion effect is very CPU intensive, I would recommend just doing a few seconds of playback or rendering, just to make sure the motion tracker is working properly. I also recommend rendering to a file, as it will be at the same speed as a playback, but will also give you some output that you can replay at will.

Reviewing Vector Paths and Translation Block object
Once you've rendered out a test file, review the vector path to make sure the Motion tracker is always centered on the Translation Block, the object you want to track. I have found that the Motion tracker is easily confused if the object you've chosen to track is a similar color to the background. You'll know it loses track when the arrow on one end of the vector path no longer points to the original object in your translation block.

Also, the Motion tracker will lose track if the Translation Search Radius is not wide enough to capture the entire range of motion of the camera movement. In my Budweiser example, I found that I needed to widen Search Radius to more than half the width of the video so that the Motion tracker would stay on track.

Step 6: In the Motion effect on the original track, deselect Draw Vectors, set Action to Stabilize Pixel and set Calculation to Load Coordinates from /tmp

Step 7: Make a duplicate of your original track
Once you have good motion tracking, you will then be able to apply your saved coordinates to another track or Target Layer. In my Budweiser example, I simply made a duplicate of the track that I generated the coordinates from. One way to make a duplicate of the original track is to:
* in the patch bay of the original track, set both the playback and record to on
* select the entire track (key "a")
* press "c" for copy
* create a new video track (Shift-T)
* in the patch bay of the new track, make sure playback and record are both set to on
* press "v" for paste

This procedure *should* copy the motion effect as well, with the settings from Step 6. If the settings from Step 6 are not in the Motion effect dialog, manually set them.

Step 8: Set the original track to not playback.
The Target Layer (duplicated track) should already be set to playback from the last step.

Step 9: Playback or Render the Video
Again, I suggest to render out the video to a file, as playing back or rendering will take the same amount of time.

Step 10: Analyze your results
You'll find that with motion stabilization, your video will tend to bounce around and you'll see black borders appear along with the motion removal. The easiest way to remove them is to experiment with different zoom levels (Z axis levels) using the Projector (NOT the Camera). For my Budweiser video, I found I needed to zoom in 1.6x. Of course, the side effect is that it may ruin whatever cinematic effect you were trying to achieve. So be advised!

Here were my results from earlier today:
1) The original video:

2) Motion vectors being generated to /tmp:

3) Motion stabilized

4) Video zoomed in to crop after stabilization. Note this crops out most of the interesting content of the video:

Advanced Use
I had a second video that bounced around quite a bit:

This time, I followed my own directions from above, but the resulting video came out jittery and jumpy:

Therefore, I increased the sensitivity of the Motion tracker by increasing Translation Search Steps from 256 to 1024:

This still was not sufficient, as I saw a couple jitters and jumps. I increased Translation Search Steps from 1024 to 8196. Be advised that this took about four times as long to render as having Translation Search Steps set to 1024. But it did remove the jitters and jumps!

The final outcome..sweet!

Enjoy!
The Mule

Adobe 64-bit Flash plugin..and it works!

2009-02-21T11:21:00.006-05:00

At the end of November, Adobe released a 64-bit Flash plugin:
http://labs.adobe.com/technologies/flashplayer10/

And, shocker of shockers, it actually works!

To Install Flash Plugin on x86-64
You'll download the tarball from here:
http://labs.adobe.com/downloads/flashplayer10.html

The only thing in the tarball is libflashplayer.so. To install the 64-bit Flash plugin, simply move libflashplayer.so into your user's .mozilla/plugins directory and restart Firefox.

Even more amazing, the bloody thing works on my Fedora 10, x86-64 virtual machine running in VMware Fusion on my MacBook Pro! Yee haw! This will definetly help me as I'm preparing a presentation on Cinelerra for the Trenton Computer Festival in April.

Much thanks to the Adobe Linux team!
http://blogs.adobe.com/penguin.swf/2008/11/now_supporting_16_exabytes.html

the mule

Fedora 10 x86-64 Cinelerra build

2009-02-15T12:46:00.019-05:00

Update 2009/02/24
You can avoid having to build Cinelerra from source by using Nicolas Chauvet's (Kwizart) precompiled Cinelerra installs:
1) install the Kwizart yum repositories
http://rpms.kwizart.net/kwizart-release-10.rpm

2) install cinelerra-cv
[mule@ogre doc]$ sudo yum install cinelerra-cv* --enablerepo=kwizart
[sudo] password for sfrase:
Loaded plugins: refresh-packagekit
Setting up Install Process
Parsing package install arguments
Resolving Dependencies
--> Running transaction check
---> Package cinelerra-cv.x86_64 0:2.1-21.git20081103.fc10 set to be updated
--> Processing Dependency: bitstream-vera-fonts for package: cinelerra-cv
--> Processing Dependency: libmpeg3-utils for package: cinelerra-cv
---> Package cinelerra-cv-debuginfo.x86_64 0:2.1-21.git20081103.fc10 set to be updated
--> Running transaction check
---> Package libmpeg3-utils.x86_64 0:1.8-1.fc10 set to be updated
---> Package bitstream-vera-fonts.noarch 0:1.10-8 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
cinelerra-cv x86_64 2.1-21.git20081103.fc10 kwizart 6.3 M
cinelerra-cv-debuginfo x86_64 2.1-21.git20081103.fc10 kwizart 9.6 M
Installing for dependencies:
bitstream-vera-fonts noarch 1.10-8 fedora 345 k
libmpeg3-utils x86_64 1.8-1.fc10 rpmfusion-free 19 k

Transaction Summary
================================================================================
Install 4 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 16 M
Is this ok [y/N]: y
Downloading Packages:
(1/4): libmpeg3-utils-1.8-1.fc10.x86_64.rpm | 19 kB 00:00
(2/4): bitstream-vera-fonts-1.10-8.noarch.rpm | 345 kB 00:00
(3/4): cinelerra-cv-2.1-21.git20081103.fc10.x86_64.rpm | 6.3 MB 00:05
(4/4): cinelerra-cv-debuginfo-2.1-21.git20081103.fc10.x8 | 9.6 MB 00:11
--------------------------------------------------------------------------------
Total 688 kB/s | 16 MB 00:24
warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 5b01f801
kwizart/gpgkey | 1.7 kB 00:00
Importing GPG key 0x5B01F801 "Nicolas Chauvet (kwizart) " from /etc/pki/rpm-gpg/RPM-GPG-KEY-kwizart
Is this ok [y/N]: y
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : libmpeg3-utils 1/4
Installing : bitstream-vera-fonts 2/4
Installing : cinelerra-cv-debuginfo 3/4
Installing : cinelerra-cv 4/4

Installed:
cinelerra-cv.x86_64 0:2.1-21.git20081103.fc10
cinelerra-cv-debuginfo.x86_64 0:2.1-21.git20081103.fc10

You're done!
*** end update ***

Building from Source
Though editing video on Linux is never easy, I'm happy to say that Fedora 10 is finally stable, after I've resolved or worked around the various bugs I've encountered.

I built Cinelerra from the CVS repository (not Heroine Warrior's) on Fedora 10 x86-64 about a month and a half ago, but haven't had time to post the steps. I can say I've put the Fedora 10 build through its paces by editing all different formats in the context of 1080p video. I will add the caveat that Cinelerra is very choosy about the formats it likes, as shown in my testing results below:

* Note that I haven't tested all combinations of containers and compression schemes, but this is a good first step

The steps are the same as the steps I ran to build Cinelerra on Fedora 9. Though this post will be rather short, consult my Fedora 9 post for all the details. FYI - the Fedora 9 system and Cinelerra build was so fraught with problems that I opted to move on to Fedora 10. I suggest you do the same.

Detail
The below steps should all be run as "root" or sudo
1) install Fedora 10
I usually select the Developer's package, as it will include many of the developer libraries necessary to build Cinelerra from source. Be aware that this install is rather large, weighing in at around 7GB.

Update 2008/02/17
After reviewing the storage consuming "Developer" install, I decided to build out a "Custom" install of Fedora. The base + Cinelerra dependencies yielded a slimmer install, at about 3.5GB.

However, for ease of use, it is probably easier to go ahead and install the "Developer" install. I did not do this, and even with all the Cinelerra dependencies checking out as "Found", I encountered three problems:
1) g++ was missing (go ahead and do "yum install gcc-c++" to resolve this)
2) libXv-devel was missing (the Cinelerra make process failed on a libxv header file)
3) libXxf86vm-devel was missing (the Cinelerra process failed on "/usr/bin/ld cannot find -lXxf86vm")

Oh, the fun we have!
*** end update ***

2) add the RPM Fusion repository for yum
http://rpmfusion.org/Configuration

3) install the dependencies for Cinelerra
For this step, I've provided a script below that installs all dependent programs for a Cinelerra installation from two repos: Fedora base and RPM Fusion.

Paste the below text into a file, save it and run it as a script. Don't forget to "chmod a+x yourFile" in order to make your script executable. The script will install all the dependencies in order to build Cinelerra
yum install gsm-devel \
libvorbis* \
libogg* \
libtool* \
libtheora* \
libpng* \
libjpeg* \
libtiff* \
esound* \
audiofile* \
libraw1394* \
libavc1394* \
freetype* \
fontconfig* \
nasm \
e2fsprogs* \
OpenEXR* \
fftw \
fftw-devel \
libsndfile* \
libiec61883* \
libdv* \
libquicktime \
ffmpeg \
xvidcore* \
lame \
lame-devel \
a52* \
faad2* \
x264* \
mjpegtools* \
faac* \
vlc*

4) get the Cinelerra source
git clone git://git.cinelerra.org/j6t/cinelerra.git cinelerra_source

5) in the Cinelerra source directory, run ./autogen.sh

6) in the Cinelerra source directory, run ./configure

7) As long as configure shows no errors, go ahead and run "make"

8) As long as make showed no errors, run "make install"

That should be it. Again, consult my Fedora 9 Cinelerra install post for more detail on these steps.

Lastly, you could avoid the whole build process and just use my Fedora 10, x86-64 VMware virtual machine, about 3GB, here:
Fedora10_x86_64.tar.gz

Please drop me a line and let me know how it goes..love to hear from you.

Good luck,
The Mule

the dark of winter has me in its grasp

2009-02-07T12:16:00.024-05:00

The Mule has been working long hours for himself and you, valued video compatriots!

That sounds positive, as it should be. Though in truth, I am feeling less positive than that message implies. Personal and professional life has got me down, but is par for the course these days. Oh well. A pithy quote to pick myself up would be rather nice here. Instead, let me regale you of the past weeks activities, as some of the tribulations may help individuals in similar need.

Sh*t Storm
This week, as I look back at my notes, I see a hailstorm of problems that I've dealt with:
-Fedora 10, x86-64 spontaneous system lockups/reboots (workaround: noapic on kernel cmd line)
-pulseaudio screwing up my audio
-usb keyboard stops working (workaround: disable keyboard acceleration)
-Gnome session saving broken (the workaround seems more of a pain than its worth)
-1080p editing eats RAM! (bought more RAM)
-Belkin firewire card causing reboots
-I didn't order my RAM in matched pairs, so I'm stuck waiting until Monday for RAM! (finally got it!)
-Evolution has trouble fetching mail from Comcast's POP servers, so I've reverted to use Pine (now "Alpine")

Needless to say, my productivity dropped and frustration was running high.

The Good News
Knock on wood, I think I was able to workaround the spontaneous reboots using "noapic" boot option to the kernel. Whereas the box was rebooting every six hours, now it has been up a full two days without a reboot! Of course, this isn't a true fix and I will have to submit a bug to the Fedora team. And the other problems still exist.

Most importantly, I've discovered a new scheme for solid, fast 1080P editing in Cinelerra:
1) convert Canon 5D video to MPEG2-TS
2) import into Cinelerra
3) render to any format you need

A Couple of Options
In my initial post on editing Canon 5D video, I found that the easiest way for me to get content from the Canon 5D into Cinelerra was using a conversion to MJPEG. However, the drawback with using mjpeg is that the image quality is lacking. Specifically, the output is darker than the original content. So over the past week, I found two solutions to convert the beautiful output of the Canon:

1) convert to H264 using this two pass string:
#CONVERT CANON USING H264, pass 1
ffmpeg -y -i INPUT.MOV -an -v 1 -threads 8 -vcodec libx264 -aspect 1.7777 -b 9000k -bt 7775k -refs 1 -loop 1 -deblockalpha 0 -deblockbeta 0 -parti4x4 1 -partp8x8 1 -me full -subq 1 -me_range 21 -chroma 1 -slice 2 -bf 0 -level 30 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -maxrate 10000k -bufsize 2M -cmp 1 -f mp4 -pass 1 /dev/null

#CONVERT CANON USING H264, pass 2
ffmpeg -y -i INPUT.MOV -v 1 -threads 8 -vcodec libx264 -aspect 1.7777 -b 9000k -bt 7775k -refs 1 -loop 1 -deblockalpha 0 -deblockbeta 0 -parti4x4 1 -partp8x8 1 -me full -subq 1 -me_range 21 -chroma 1 -slice 2 -bf 0 -level 30 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -maxrate 10000k -bufsize 2M -acodec libfaac -ab 160k -ar 48000 -ac 2 -cmp 1 -f mp4 -pass 2 OUTPUT.mp4

Now, this H264 content is beautiful, will import into Cinelerra and is editable. However, I found that when I went to render the final output, four minutes of the 1080p, H264 content took SIX HOURS to render!! That is unacceptable. I believe the lengthy render time has something to do with the color space or internal conversion that Cinelerra is doing. This bears further research.

If you're not familiar with H264 (x264 libraries on Linux), here's some useful H264 reference material.

2) convert to MPEG2-TS

Converting Canon to 1080p, MPEG2-TS
Now, there are a few steps here.

a. Take a file from the Canon and use ffmpeg to pass a lossless yuv4mpegpipe stream into mpeg2enc, with the result a video stream with no audio:
ffmpeg -i INPUT.MOV -threads 8 -s 1920x1088 -f yuv4mpegpipe - | mpeg2enc --multi-thread 8 --verbose 0 --aspect 3 --format 13 --frame-rate 5 --video-bitrate 24000 --nonvideo-bitrate 384 --interlace-mode 0 --force-b-b-p --video-buffer 448 --video-norm n --keep-hf --no-constraints --sequence-header-every-gop --min-gop-size 6 --max-gop-size 6 -o OUTPUT.m2v

Next, render out the audio:
ffmpeg -y -i INPUT.MOV -acodec mp2 -ar 44100 -ab 256k -ac 2 OUTPUT.m2a

Using mplex, mux the video and audio streams together:
mplex -f 3 -b 2000 OUTPUT.m2a OUTPUT.m2v -o OUTPUT.ps

Using VLC, convert the MPEG2-PS into an MPEG2-TS:
cvlc OUTPUT.ps --sout '#duplicate{dst=std{access=file,mux=ts,dst="OUTPUT.m2t"}}' vlc://quit

Update 2009/02/13
I've found that VLC is not writing proper keyframes at the beginning of the converted MPEG-PS video output from mplex. This is only for 1080p video. The VLC command for 720p video still works. For the 1080p, I've found a workaround using our savior, ffmpeg:
ffmpeg -y -i OUTPUT.ps -acodec copy -f mpegts -qscale 1 OUTPUT.m2t
*** end update ***

I used this method to output a new version of my Water video from Cinelerra to Vimeo here:
/2009/01/water-new-canon-5d-video.html

The quality and the colors are definetly improved upon over the old version. However, the larger file size is a drawback (479MB for 4m16s of video). So I'd like to get the H264 output without compression artifacts during the scenes with a lot of motion. So now its time to figure that out. Erg.

In general though, I think this is some good news!

Until the next time,
the mule

high quality h264 output

2009-01-30T10:03:00.012-05:00

For the last few years, I've been working with 720P content. With the recent purchase of a Canon 5D, I'm now working with 1080P video. Both formats are in 16:9 aspect ratio.

720P video implies a horizontal resolution of 1280 pixels, 1280x720 frame resolution with a total of 921,600 pixels.

1080P video implies a horizontal resolution of 1920 pixels, 1920x1080 frame resolution with a total of 2,073,600 pixels.

Though this is a blog on Linux video editing, I heartily welcome good information on the often confusing subject of video compression. Here is an article on Apple's site that conveys the basic information you'll need to understand about encoding H264 videos:
http://www.apple.com/quicktime/tutorials/h264.html

As I work to produce higher quality video, one of the things I've thought about is the possibility of getting my material aired on cable TV. So the Broadcast Standards discussion in the above Wikipedia article was very interesting. Also, it occurred to me that I've never properly understood the differences between fields and frames, in the context of telecine, or how film is transferred to video. The Wiki article above clarified it for me and is highly recommended. Fields and frames are also useful in the context of how Cinelerra processes video.

Rendering High Quality H264 video
It is important to understand aspect ratio in the context of rendering high quality video. Lately, I've been encoding H264 video; specifically, I've been reducing the size of my videos to load onto an iPhone/iTouch. For this task, one of the easiest ways to assure best output quality is to make sure that both the height and width of the rendered output are divisible by 16.

Without going into the highly technical details of the H.264/MPEG-4 AVC standard or how video compression works, here is a somewhat simplistic analysis:
"..it's slightly better to have dimensions divisible by 16, but only because H.264 divides up a picture into 16x16 blocks and if you have a partial block it still has to expend time and bandwidth on it.

A size that is an exact multiple of 16 H & V will compress a tiny bit more efficiently, or look slightly better at the same bitrate."
-extracted from this conversation

To make sure the dimensions of my videos are always divisible by 16, you can do the calculations yourself, or take a look at a couple nice charts from Andrew Armstrong's site to help you choose dimensions where the height and width are both divisible by 16. To make it easy for you, there are only a few choices:
1536x864
1280x720
768x432
512x288
256x144

This will avoid the dread "width or height not divisible by 16, compression will suffer" error you would see in many H264 encoders.

Robert Swain's blog was very helpful in determining x264 parameters that yield great looking video. Especially the page regarding ffmpeg presets, though I haven't yet determined what preset is best for my content. The presets listed on Robert's page need to be put into a .ffmpeg directory under your user's home directory.

Finally, this bitrate calculator for Adobe's Flash Videos was something useful I stumbled up while researching this post:
http://www.adobe.com/devnet/flash/apps/flv_bitrate_calculator/

the Mule

stock footage, encoding H264 and the iPod

2009-01-25T02:13:00.023-05:00

I had a bit of a rough day yesterday. I started early, about 8am, upgrading my MacBook Pro to Leopard. That process went more or less smoothly and finished around noon. Next, I had taken some video the night before and wanted to create a video that would serve as a table of contents to my archive. Also, this short video might enable me to market some of my source material as stock footage. So it might be a fun little project that shouldn't take long. I should know to never say "shouldn't take too long", because things have a way of blowing up in your face when you don't expect them to.

Converting 1080P directly to an iPod-ready format
The goal was to convert some 1080P video from my Canon 5D directly into an iPod readable format. However, as I was overly tired on this day, my mind defeated me. Essentially what happened was that after I rendered out the video and loaded it to the iPod, I kept seeing only three quarters of the video. Flummoxed, I thought it must be a rendering problem. Long story short, I found that the problem was not with my rendering parameters, but the fact that my iTouch has a zoom/scaling feature that I forgot about, but had enabled. Here is the little bugger:

So I had spent about three hours until 2am fighting with encoding parameters, re-encoding video, transferring many test files to my Mac and then loading them to the iPod, only to find that the source of the problem was this little stupid icon on the iTouch.

Boy, am I dense.

A Learning Experience
I did learn a few things through my travails this weekend:
1) The el cheapo haze filter on my camera shows a lot of lens flare and needs to be replaced.

2) Don't merge a longer audio stream with a shorter video stream or else you'll be wondering why your 1m45s video is suddenly 9m30s. Duh.

3) When encoding videos to H264 format, always try to use resolutions where the height and width are divisible by 16. This will make the level of compression and quality of the resulting video better. I will post separately about resolutions that are divisible by 16.

4) A dvd video encoded by ffmpeg using -target ntsc-dvd and then downrezzed using the following command syntax will NOT have the proper aspect ratio once loaded onto the iPod:
ffmpeg -y -i ${NAME}.mpg -an -v 1 -threads 8 -vcodec h264 -b 250k -bt 175k -refs 1 -loop 1 -deblockalpha 0 -deblockbeta 0 -parti4x4 1 -partp8x8 1 -me full -subq 1 -me_range 21 -chroma 1 -slice 2 -bf 0 -level 30 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -maxrate 450k -bufsize 2M -cmp 1 -s 720x480 -f mp4 -pass 1 /dev/null

ffmpeg -y -i ${NAME}.mpg -v 1 -threads 8 -vcodec h264 -b 250k -bt 175k -refs 1 -loop 1 -deblockalpha 0 -deblockbeta 0 -parti4x4 1 -partp8x8 1 -me full -subq 6 -me_range 21 -chroma 1 -slice 2 -bf 0 -level 30 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -maxrate 450k -bufsize 2M -cmp 1 -s 720x480 -acodec aac -ab 160k -ar 48000 -ac 2 -f mp4 -pass 2 -threads 8 ${NAME}.mp4

So don't try that at home, kids.

I had previously been using this string of encoding parameters to encode a video of my band rehearsals. The encode was from a DVD source file, so perhaps I will just use the 1080P as source going forward. I will have to test this out first. Strangely, the conversion of the audio from AC3 format had audible hiccups from time to time. Since this process was working fine on Fedora 7, perhaps this is just an issue with Fedora 10.

Downrezzed 1080P Video Ready for the iPod
The following two pass Cinelerra encoding parameters via yuv4mpeg stream worked well to produce a high quality video from 1080P source. In short, you will do two renders from a YUV4MPEG stream:
render 1: the pipe to /dev/null in order to create the optimization log
render 2: the pipe to create the file

#CINELERRA YUV4MPEG RENDER 1
ffmpeg -f yuv4mpegpipe -y -i - -an -v 1 -threads 8 -vcodec libx264 -b 1000k -bt 775k -refs 1 -loop 1 -deblockalpha 0 -deblockbeta 0 -parti4x4 1 -partp8x8 1 -me full -subq 1 -me_range 21 -chroma 1 -slice 2 -bf 0 -level 30 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -maxrate 1000k -bufsize 2M -cmp 1 -s 512x288 -f mp4 -pass 1 /dev/null

#CINELERRA YUV4MPEG RENDER 2
ffmpeg -f yuv4mpegpipe -y -i - -i /mnt/videos/projects/2009_01_23/nightUrbanIndustrialIpod.mp3 -v 1 -threads 8 -vcodec libx264 -b 1000k -bt 775k -refs 1 -loop 1 -deblockalpha 0 -deblockbeta 0 -parti4x4 1 -partp8x8 1 -me full -subq 6 -me_range 21 -chroma 1 -slice 2 -bf 0 -level 30 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -maxrate 1000k -bufsize 2M -cmp 1 -s 512x288 -acodec libfaac -ab 160k -ar 48000 -ac 2 -f mp4 -pass 2 -threads 8 %

I chose a resolution of 512x288 because:
1) the aspect ratio is the same as my 1080P source video, 16:9 (1.777)
2) both the height and width are divisible by 16
3) there were no errors and it comes out looking great on the iPod

Rendering Parameters for a High Quality Vimeo Upload
Finally, I was able to output an H264 video at 1920x1080 that looks great in Vimeo. Psych! I was able to remove the ugly bottom bar seen in Vimeo from my previous post. Here is the two-pass encoding method that I used from Cinelerra. Two notes:
1) the two passes are YUV4MPEG stream renders from Cinelerra using FFMPEG and will need to be run as individual renders in Cinelerra.
2) the second pass muxes (combines) a pre-rendered audio stream with the video stream. So you'll need to render that audio file first.

Here is your first render command string (the first pass of the two-pass) that will create the optimization log:
#CINELERRA RENDER PASS1
ffmpeg -f yuv4mpegpipe -y -i - -an -v 1 -threads 8 -vcodec libx264 -aspect 1.7777 -b 9000k -bt 7775k -refs 1 -loop 1 -deblockalpha 0 -deblockbeta 0 -parti4x4 1 -partp8x8 1 -me full -subq 1 -me_range 21 -chroma 1 -slice 2 -bf 0 -level 30 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -maxrate 10000k -bufsize 2M -cmp 1 -f mp4 -pass 1 /dev/null

Here is the second render command that takes advantage of the optimization log created in the first-pass render. I rendered an audio file of my project earlier, so this second command also combines that audio file with the video for my final result:
#CINELERRA RENDER PASS2
ffmpeg -f yuv4mpegpipe -y -i - -i /mnt/videos/projects/blog/waterSmall.mp3 -v 1 -threads 8 -vcodec libx264 -aspect 1.7777 -b 9000k -bt 7775k -refs 1 -loop 1 -deblockalpha 0 -deblockbeta 0 -parti4x4 1 -partp8x8 1 -me full -subq 1 -me_range 21 -chroma 1 -slice 2 -bf 0 -level 30 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -maxrate 10000k -bufsize 2M -acodec libfaac -ab 160k -ar 48000 -ac 2 -cmp 1 -f mp4 -pass 2 %

I think the quality is bloody AWESOME! Take a gander:

2009/01/23: night, urban, industrial from crazed mule on Vimeo.

Conclusion
Through pain, there can sometimes be the brighter side. In this case, I learned a few things. In retrospect, I may have chosen my production company's name correctly. A mule is one stubborn beast.

Related to crazed mules, here is a story I stumbled upon the other day you might find funny:
The Day the Mules Went Crazy

The Mule

Reference
H264 Encoding

Water, a new Canon 5D video

2009-01-12T15:36:00.020-05:00

After a couple of weeks of gathering content, I completed my first real Cinelerra project using the 1080P output from my brand new Canon EOS 5D Mark II.

This camera outputs some gorgeous video as I showed in my last post. Now I have to learn how to shoot with it!

The Project
My goal with this short production was:
1) to show the capabilities of the camera
2) to prove that Cinelerra was up to the task of editing 1080P content
3) to output the final results to different output formats (media player, Vimeo, back into Cinelerra)

I'm a hobbyist, so I don't have a budget and "script" like Vincent Laforet. However, I like to compile scenes and organize them with musical accompaniment in thoughtful ways that are (hopefully) enjoyable to the viewer.

The Images
Since I am not a professional photographer, I did not have a slew of lenses before I bought the cam. I only used two lenses that I recently bought for this video:
Canon EF 24-105mm f/4 L IS USM Lens
Canon EF 50mm f1.4 USM Lens

In regards to the imagery, about half of the shots were taken with a tripod. Where you see shakey video is obviously where I held the cam by hand. You definetly do NOT want to shoot high definition video by hand. It serves to amplify any wobbling present and looks terrible when presented on a high definition television. One thing that saved me was the stabilization provided by the Canon L series zoom lens. It is very effective in dampening bounces, though the stabilization mechanism is loud and is picked up by the camera's poor quality, but usable internal stereo microphone.

I used the 50mm mainly for the indoor shots and the zoom for the outdoor shots. I shot some of the outdoor night shots with the zoom, but then realized that the zoom doesn't do well in low light conditions since it has such a long zoom barrel. So just last week, I bought the 50mm. The 50mm fixed length (prime) lens really makes night shots clear with none of the spotty, dappled artifacts that you see with high ISO night shots. During the video, you'll notice those artifacts on the shot of the ferry.

Note that I used no filters on the shots..what you see in the video is truly what you get with the camera. As I gain expertise with the camera, I look forward to acquiring lenses over the next few years.

The Editing Process
The editing process has been a bit of a challenge, as the native output from the camera does not import cleanly into Cinelerra. Hence, I needed to transcode the native output into something more Cinelerra friendly, which I discuss in earlier posts:
/2009/01/first-edit-canon-5d-mark-ii.html
/2008/11/playing-tokyo-reality-in-1080p.html

I didn't want to revisit the conversion process, so I opted to use the MJPEG conversion command I previously discovered:
ffmpeg -i input.mov -b 3000k -vcodec mjpeg -ab 256k -ar 44100 -acodec libfaac -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -subq 5 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 output.mov

Once loaded in Cinelerra, I found I had quite a few assets from the last couple weeks of shooting.

If I could have one improvement made to the software, it would be to add folders to the Media bin in order to better manage assets.

I went about editing the video as normal. I applied only time-based effects, like speeding up or slowing down the video, and transitions. The time-based effects were accomplished by attaching the ReframeRT video effect:

Output
I needed to output files from the project for different purposes:
1) to reimport back into Cinelerra (JPEG or MJPEG Quicktime video)
2) to export/render a format usable with my MG-350HD Media Player
(1080I/1080P MPEG2 video)
3) to export/render a format usable for Vimeo (720P MPEG2)

For #1, I exported a Quicktime for Linux container, using MJPEG compression. I just needed the video, so I had no audio on the export. I was able to reimport the resulting file easily into Cinelerra.

For #2, I rendered the video using a YUV4MPEG pipe. I needed to adjust the pipe command to export a different format and higher video bitrate.
mpeg2enc --verbose 0 --aspect 3 --format 13 --frame-rate 4 --video-bitrate 24000 --nonvideo-bitrate 384 --interlace-mode 0 --force-b-b-p --video-buffer 448 --video-norm n --keep-hf --no-constraints --sequence-header-every-gop --min-gop-size 6 --max-gop-size 6 -o %

Using mplex, I then combined the video stream with an existing audio track to an MPEG2 Program Stream:
mplex -f 3 -b 2000 canon5d.m2a canon5d.m2v -o canon5d.ps

Finally, I converted the program stream to an MPEG2 Transport Stream using vlc:
cvlc canon5d.ps --sout '#duplicate{dst=std{access=file,mux=ts,dst="canon5d.m2t"}}' vlc:quit

For #3, I reduced the 1080i/p output to 720P using FFMPEG:
ffmpeg -i canon5d.m2t -target ntsc-dvd -s 1280x720 -qscale 1 -threads 8 canon5d.mpg

Update 2008/01/13
I hadn't noticed before, but after I uploaded the 720P file to Vimeo, there was a little bit of a line on the bottom of the video. I am going to have to revisit the edit to make sure I didn't mess something up.
*** end update ***

I think the quality of the output can definitely be improved. However, I am glad that I was able to output to formats usable across different platforms (HDTV/Internet/Linux-Cinelerra).

Update 2008/02/08
I've been working on improving the quality of the output from Cinelerra. Specifically, instead of using MJPEG source files (the first conversion from the cam), I'm converting the Canon's video to MPEG2-TS. The MPEG2-TS format has very nice quality and edits quickly in Cinelerra. Here's the full skinny:
/2009/02/dark-of-winter-has-me-in-its-grasp.html
*** end update ***

In Sum
Dealing with a new media format in Linux and Cinelerra is never easy. But if you have patience, it is very satisfying to get a project done that makes your friends say "Wow" or have a laugh.

the mule

Canon 5D Mark II video: Cinelerra edit

2009-01-03T15:58:00.025-05:00

Well folks, I got myself quite a present for Christmas: the Canon EOS 5D Mark II:
http://www.usa.canon.com/consumer/controller?act=ModelInfoAct&fcategoryid=139&modelid=17662
Amazon: Canon EOS 5D Mark II

I've acquired a bit of video over the first few days with the cam. Now let's make sure I can edit the bloody stuff in Cinelerra! :)

Update 1/14/2009
I've done a full edit session with the output of the 5D. Lovely!
*** end update ***

I've found the following process works pretty well.

1) Convert video to a Cinelerra-usable format
As I explained in one of my earlier posts, mjpeg seems a good format to convert the H264 output of the cam:
[mule@ogre 2008_12_26]$ ffmpeg -i MVI_0072.MOV -b 3000k -vcodec mjpeg -ab 256k -ar 44100 -acodec libfaac -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -subq 5 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 mvi_0072.mov

Here's an image that compares the original, Canon saved H264 video to the MJPEG conversion:

Pretty close, eh? The MJPEG video seems a little lighter and you can see more detail, though the colors are a little washed out.

2) Import into Cinelerra
Unlike the H264 format the Canon saves, the MJPEG conversion imports cleanly into Cinelerra without error messages. Also, on my dual, quad core Dell running Fedora 10, I get about 18fps playing back the raw video. Nice.

3) Render to YUV4MPEG stream as H264 video
I do this step in two parts:

a. Render the audio
The Canon stores its audio in 44Khz, 16-bit PCM format. I rendered out an MPEGI, Layer2 audio file:
--------------------------------------------
Input File : 'stdin' 44.1 kHz
Output File: '/mnt/videos/projects/2008_12_26/audioTrack.m2a'
256 kbps MPEG-1 Layer II j-stereo Psy model 1
[De-emph:Off Copyright:No Original:No CRC:Off]
[Padding:Normal Byte-swap:Off Chanswap:Off DAB:Off]
ATH adjustment 0.000000
--------------------------------------------
encode_init: using tablenum 0 with sblimit 27
Hit end of audio data
Avg slots/frame = 768.000; b/smp = 5.33; bitrate = 256.000 kbps
Render::run: Session finished.

b. Render a YUV4MPEG stream. Using the following pipe, I combine the audio track that was output in the previous step with the video that is being rendered:
ffmpeg -f yuv4mpegpipe -y -i - -i /mnt/videos/projects/2008_12_26/audioTrack.m2a -b 3000k -vcodec libx264 -ab 256k -ar 44100 -acodec libfaac -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -subq 5 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 %

Step B is very similar to the advanced rendering technique I showed you in the Beginner's Guide to Exporting Video from Cinelerra. Here's how the render looks in a terminal window:
Input #0, yuv4mpegpipe, from 'pipe:':
Duration: N/A, bitrate: N/A
Stream #0.0: Video: rawvideo, yuv420p, 1920x1080, 30.00 tb(r)
Input #1, mp3, from '/mnt/videos/projects/2008_12_26/audioTrack.m2a':
Duration: 00:00:28.42, start: 0.000000, bitrate: 255 kb/s
Stream #1.0: Audio: mp2, 44100 Hz, stereo, s16, 256 kb/s
Output #0, mp4, to '/mnt/videos/projects/2008_12_26/mvi_0072_h264.mp4':
Stream #0.0: Video: libx264, yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], q=2-31, 3000 kb/s, 30.00 tb(c)
Stream #0.1: Audio: libfaac, 44100 Hz, stereo, s16, 256 kb/s
Stream mapping:
Stream #0.0 -> #0.0
Stream #1.0 -> #0.1
[libx264 @ 0x1ec6200]using SAR=1/1
[libx264 @ 0x1ec6200]using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
frame= 852 fps= 5 q=5.0 Lsize= 18223kB time=28.35 bitrate=5265.6kbits/s
video:17680kB audio:526kB global headers:0kB muxing overhead 0.092246%
[libx264 @ 0x1ec6200]slice I:4 Avg QP:27.33 size: 74266
[libx264 @ 0x1ec6200]slice P:848 Avg QP:28.42 size: 21000
[libx264 @ 0x1ec6200]mb I I16..4: 61.4% 0.0% 38.6%
[libx264 @ 0x1ec6200]mb P I16..4: 16.9% 0.0% 2.2% P16..4: 28.4% 8.9% 1.0% 0.0% 0.0% skip:42.6%
[libx264 @ 0x1ec6200]final ratefactor: 35.54
[libx264 @ 0x1ec6200]SSIM Mean Y:0.9495821
[libx264 @ 0x1ec6200]kb/s:5099.9
Render::run: Session finished.

The Result
Comparing the resulting video, the quality seems acceptable, though a bit dark and drained of color in comparison to the original. Notice the removal of the color bands in the sky:

That's a bit of a bummer. I am going to have to investigate how to improve the quality, especially the color.

However, you can't argue with the efficiency of the file size of the H264. Here's a comparison of all three files:

-rw-r--r--    1 mule  ogre       138M Jan  3 16:04 MVI_0072orig.MOV (ORIGINAL)
-rw-r--r--    1 mule  ogre       164M Jan  3 16:02 MVI_0072_convert.MOV (MJPEG CONVERSION)
-rw-r--r--    1 mule  ogre        17M Jan  3 20:02 mvi_0072_h264.mp4 (H264 FINAL)

All in all, its still pretty cool.

Here is the video on Vimeo:
http://vimeo.com/2711794

Since I'm on Fedora, the Vimeo uploader seems to hang. So for Fedora (and I'm sure other Linux distributions) uploads seem to work better using the Basic Uploader:
http://www.vimeo.com/upload/video/basic
Thanks Raffa!

Keep you posted,
The Mule

Cinelerra render compatibility on Fedora 10, x86-64

2008-12-20T16:40:00.045-05:00

I spent the last four days building a new Fedora 10, x86-64 server for video editing based on programs available through the RPM Fusion repository. I'll post something soon about that whole process, which required more work and frustration than expected. However, my primary goal was to create a flexible and solid Cinelerra video editing rig.

Update 2009/02/15
Here's a post on how to build Cinelerra from source on Fedora 10, x86-64
*** end update ***

Testing the New System
In order to verify my new build, I needed to test high quality, rendered output from Cinelerra. More specifically, I wanted to test formats that required no external multiplexing (muxing). This will save me time in the future.

Assumptions
Also, note the test will be conducted against a larger resolution, 720P project. This will influence the playback ability of some of the programs.

Testing Procedure
During the testing phase, I was able to put Cinelerra's batch processing feature to use. This is very nice if you need to render large masses of files. Especially nice if you want to repeat or standardize that process across different Linux distributions.

Thinking more about this, it might be a boon to the cvs.cinelerra.org community if I made the XML of the batch list available to the community. That way, we could standardize the testing of output on different Linux distributions. At the end of the day, we could say things like "mplayer on SUSE 11 doesn't playback a 720P Quicktime rendered from Cinelerra that uses MPEG4 video compression with AAC audio encoding. However, that same file does work in mplayer on Fedora 10." So, it would be helpful to the QA process. I will bring this up as an idea to the community.

Source File
The original video is 21 seconds long and is in 720P format, 1280x720 at 29.97fps.

In order to test the new operating system, I exported various combinations of audio and video formats, choosing fixed bitrates that seemed appropriate given the resolution of the source project:

I tested the output in standard Linux media players (vlc/mplayer/ffplay/totem), as well as reimported them into Cinelerra.

Results
In order to make it easy for people to comprehend the results, I've put together this graphic:

Using a stop light analogy, green means that the file plays with no problem. So, if you want to know the "best" or "good", compatible formats to use in Linux media players and Cinelerra, go for the green. Red means the file doesn't play at all. And yellow means that the file plays, but plays with some problem. For instance, the audio may be out of sync or stutters, or the video plays but maybe at the wrong resolution. Be advised that my system is fairly powerful, so your mileage may vary:
* Dell SC1430, dual quad core, 1.6Ghz, 2GB RAM
* RAID0 sys/working drive, RAID1 storage drive
* NVidia 8800GT video card

Observations
JPEG and MPEG-4 Quicktimes seem to work well and have the side benefit of being re-usable within Cinelerra. MPEG-4 rendering is unbelievably quick. H264 direct out of Cinelerra seems not to work at all in most cases. There was a tie for the file type with the widest compatibility among the chosen media players: Ogg/Vorbis and surprisingly, Microsoft MPEG4 using twos complement audio.

It is interesting to note the varying file sizes of the output from Cinelerra: Besides the uncompressed formats, Motion JPEG A creates the largest file sizes, while either of the MPEG4 formats are the most space efficient. Given the chart above, this is an important data point that video editors will be able to consider when selecting a particular format.

Conclusion
Though it is powerful, Cinelerra has been somewhat crippled by new users' ability to get usable content out of Cinelerra. I think this chart will improve that situation, even if it has only been proven out on Fedora 10, 64-bit. In that light, it would be interesting to see the same chart from an alternate Linux distribution. With my source Cinelerra and batch process EDL files, it should be easy to replicate the procedure on another system. I'd be happy to share them if an interested party wants to drop me a line.

Finally, I realize there are some missing file types like avi container, MPEG2 program and transport stream formats. The MPEG2 formates generally require external muxing and thus, were off the list for this test. However, I will try to test the at some point.

enjoy,
The Mule

Fedora 9 Cinelerra deps, ATrpms note

2008-12-12T20:56:00.009-05:00

Some people have complained of incompatibilities with Fedora and ATrpms. Instead, they recommend using the better supported RPMFusion, the repository that has merged all the other repositories for Fedora. This is a good idea; however, I have not yet had a chance to test the Fusion RPMs.

Update 2009/02/15
Here's a post on how to build Cinelerra from source on Fedora 10, x86-64
*** end update ***

I'm using ATrpms for a small number of Cinelerra dependencies, sixteen programs in all (listed below). I've given my new Fedora 9 system a fairly good break in test and have not found any issues arising from my use of ATrpms.

12/17/2008 Note regarding my use of ATrpms
So often in this topsy-turvy world of new distributions and funky repositories, the moment you write that an install is without problems, that old devil fate creeps up on you and proves you wrong.

Such is the case with my recent Cinelerra build from source using ATrpms dependencies. The whole day last Sunday was shot with a nasty Cinelerra hang that was only resolved when I removed the ATrpms repo programs, installed the RPM Fusion repository and recompiled Cinelerra. I'll follow up with a more detailed explanation but for now, The Mule would like to humbly apologize to anyone he led astray by recommending ATrpms.

On the positive side, unexpected problems usually lead one to find new solutions and better ways of doing things. So that's the upside of this mess.
end note

Here are the packages that I installed from ATrpms (and subsequently removed) on my Fedora 9, x86-64 system:


Name       : ffmpeg
Version    : 0.4.9
Release    : 28_r15845.fc9
--
Name       : fftw
Version    : 3.1.2
Release    : 11.fc9
--
Name       : fftw-devel
Version    : 3.1.2
Release    : 11.fc9
--
Name       : freetype-static
Version    : 2.3.5
Release    : 4.fc9.cubbi2
--
Name       : lame
Version    : 3.98.2
Release    : 19.1.fc9
--
Name       : libdvdcss
Version    : 1.2.10
Release    : 5.fc9
--
Name       : libdvdcss-devel
Version    : 1.2.10
Release    : 5.fc9
--
Name       : libdvdcss2
Version    : 1.2.10
Release    : 5.fc9
--
Name       : libdvdnav4
Version    : 0.1.10
Release    : 2.fc9
--
Name       : libraw1394
Version    : 1.3.0
Release    : 8_11.fc9
--
Name       : libraw1394
Version    : 1.3.0
Release    : 8_11.fc9
--
Name       : libraw1394-devel
Version    : 1.3.0
Release    : 8_11.fc9
--
Name       : libraw1394_8
Version    : 1.3.0
Release    : 8_11.fc9
--
Name       : libraw1394_8
Version    : 1.3.0
Release    : 8_11.fc9
--
Name       : x264
Version    : 0.65
Release    : 8_20081108.2245.fc9
--
Name       : x264-devel
Version    : 0.65
Release    : 8_20081108.2245.fc9

I've put my system through the following tests:
-edit 720P project in Cinelerra
-via Cinelerra's YUV4MPEG streamer and mpeg2enc, export 720P resolution MPEG2 video
-from Cinelerra, export MPEG, Layer II audio
-using mplex, combine MPEG2 video and MPEG Layer II audio stream into MPEG-PS
-using VLC, convert program stream into MPEG-TS
-using FFMPEG, convert transport stream into DVD
-using FFMPEG, convert DVD file into iTunes compatible format

This is my normal workflow. Nothing seems to have broken in this workflow, so I think ATrpms has not effected my particular install.

Again, my apologies if anyone had tried using ATrpms based on my advice.
the mule

minor problems from new Fedora 9

2008-11-23T16:42:00.011-05:00

I'm glad I took the time to rerun my main encoding script, as it showed a number of errors due to changes between Fedora 7 and Fedora 9. The first four I've encountered are specific to VLC; the last couple are problems with the latest FFMPEG install.

VLC Problems
1) permissions issue
This is not necessarily a problem with a change in Fedora, just a problem with how I've reorganized some of my videos to be owned by a different user. When I ran VLC to convert one of the files, I got this error:
[00000436] access_output_file access out error: cannot open `20081123.m2t' (Permission denied)
[00000434] stream_out_standard stream out error: no suitable sout access module for `file/ts://20081123.m2t'

At least the text of the error was not ambiguous..Permission Denied! :) Once I identified the permissions problem and granted appropriate privileges to the file, this message went away. A good option when running VLC is to run it with the -vvv verbose switch in order to get full debug stream on what is going on.

2) command line VLC doesn't accept quit anymore
VLC used to quit properly when my old script used to look like this:
vlc input.ps --sout '#duplicate{dst=std{access=file,mux=ts,dst="output.m2t"}}' vlc:quit

VLC's authors must now be enforcing command line syntax, as there now needs to be two slashes after the colon in the quit directive. So the following works again:
vlc input.ps --sout '#duplicate{dst=std{access=file,mux=ts,dst="output.m2t"}}' vlc://quit

Update 12/13/2008
3) Can't run VLC as root anymore
When I tried to run VLC from a script as root, I got this error:
VLC is not supposed to be run as root. Sorry.
If you need to use real-time priorities and/or privileged TCP ports
you can use vlc-wrapper (make sure it is Set-UID root first and
cannot be run by non-trusted users first).

For security reasons, it is probably better that VLC enforces this. I addressed the issue in two ways:
1) login as a non-privileged user to run VLC
2) if I need to run VLC as root, I will use the "su" command to run the command using a different user's privileges. Using my non-privileged "mule" user, the syntax of the command is something like the below. I am using command line VLC, which is started by "cvlc":
su mule -c "cvlc input.ps --sout '#duplicate{dst=std{access=file,mux=ts,dst=output.mp4}}' vlc://quit"

In either case, I made sure that all my files are owned by or at least accessible by the user that runs VLC.
end update

4) Some obscure dbus error
[00000415] inhibit interface error: Failed to connect to the D-Bus session daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Looking up this error in Google points to a number of threads regarding the reinstall of dbus message bus. However, this error doesn't inhibit my ability to convert video, so I'm not going to do anything about this error right now.

5) a bunch of other GUI related errors
[00000415] main interface error: no suitable interface module [00000001] main libvlc error: interface "inhibit,none" initialization failed
[00000001] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
No protocol specified
[00000421] qt4 interface error: Could not connect to X server
No protocol specified
[00000421] skins2 interface error: Cannot open display
[00000421] skins2 interface error: cannot initialize OSFactory

Even with these errors, VLC does start, though in remote control mode only. You can quit out of this mode by typing "quit" after the line that reads:
Remote control interface initialized. Type `help' for help.

Since I am running VLC as part of a command script, I changed the script to use the command-line version of VLC, CVLC as below:
cvlc input.ps --sout '#duplicate{dst=std{access=file,mux=ts,dst="output.m2t"}}' vlc://quit

Note that the quit directive is still "vlc://quit". Eventually, I do want to run VLC's GUI mode, so I will have to return to fixing this error.

FFMPEG Problems: library naming
Running this FFMPEG command on my shiny new Fedora 9 system:
ffmpeg -i input.mpg -threads 8 -f mov -vcodec mpeg4 -qscale 3 -s 320x180 -r 29.97 -aspect 16:9 -acodec aac -ac 2 -ar 48000 -ab 448k output.mov

Gave me this error:
Unknown encoder 'aac'

Researching on Google led me to this thread, which stated that the proper syntax is to now using the name of the library, libfaac:
http://bbs.archlinux.org/viewtopic.php?id=46958.

The version of FFMPEG that I had been using with Fedora 7 was SVN version 9975. With Fedora 9, that is revised to SVN version 12135. During the interim between the two versions, command syntax now requires full library names.

So using the proper library name 'libfaac' fixed the issue and allowed ffmpeg to continue:
ffmpeg -i input.mpg -threads 8 -f mov -vcodec mpeg4 -qscale 3 -s 320x180 -r 29.97 -aspect 16:9 -acodec libfaac -ac 2 -ar 48000 -ab 448k output.mov

The same error occurred with my command to encode a file to h264 format:
ffmpeg -y -i input.mpg -v 1 -threads 8 -vcodec h264 -b 250k -bt 175k -refs 1 -loop 1 -deblockalpha 0 -deblockbeta 0 -parti4x4 1 -partp8x8 1 -me full -subq 6 -me_range 21 -chroma 1 -slice 2 -bf 0 -level 30 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -maxrate 450k -bufsize 2M -cmp 1 -s 720x480 -acodec libfaac -ab 160k -ar 48000 -ac 2 -f mp4 -pass 2 -threads 8 output.mp4

I received this error:
Unknown encoder 'h264'

The solution was to simply replace 'h264' with 'libx264' in the command line:

Silliness!
the mule

video distribution and the blogosphere

2008-11-22T17:23:00.012-05:00

After having this blog for a few years now, I've been thinking about the entire chain of events that occur when producing a video. So I mapped out the different components of this production workflow in relation to distribution and marketing via the blogosphere.

The Blogging Ecosystem
In the clickable map below, I've listed the major steps in the production chain, as well as specific subjects within each step. Go ahead and click on anything in the picture and it will take you to a summary of that particular topic or a direct resource on the web. Some of this is old hat for readers, but it was helpful to see it holistically, as an ecosystem of sorts. The flow represents a way to distribute one's video creations (content) over the web and get some eyes looking at that content.

(the graphic is hotlinked, so click on a subject for further investigation)

Summary
In general, the white boxes represent steps that the producer is responsible for; the blue box represent actions taken by the consumers of the content. The main steps are:
-having an idea for a video and storyboarding (not shown)
-acquiring source content (video/audio/imagery)
-bringing the idea to life via a production workflow
-distributing that video via the web
-syndicating the content via rss feed
-having individuals consume that feed
-monitoring and analyzing the consumption
-promoting and marketing of content
-perhaps making some money one day

Detail
If you click on any part of the graph, you'll be able to dig down further into the resources I've provided. As it will require some explaining, I'll probably do a follow up video to this graphic.

Enjoy!

burning blu-ray discs on Linux

2008-11-21T17:10:00.015-05:00

If I actually get a camera that can do 1080p, I'm going to have to have some means of distribution.
Update 2009/01/11
Gosh darnit, I DID get a new cam! Hooray!
*** end update ***

Blu ray seems the best bet. For testing, I'd opt to use the Blu ray rewriteable format, BD-RE.

From a few hours of research, these facts appear:
1) It IS possible to write blu ray data discs via the dvd+rw-tools. See Technical discussion and Burning links below
2) The burning of blu ray video discs to be played in consumer players may be possible in the dvd+rw-tools, but should be definetly possible in the Nero 3 product for Linux (around $25). This bears testing.

Final Thoughts
Prices are still high: $300-$400 for an internal burner and roughly $10 per disc. Testing these options out will be essential.

the mule

Blu Ray US site
http://www.blu-raydisc.com/bluray_site.htm

Technical discussion of dvd+rw-tools methodology
http://fy.chalmers.se/~appro/linux/DVD+RW/

Burning BD-RE disks with dvd+rw-tools
http://forums.aliensoup.com/showthread.php?t=24180

Untested open source blu ray authoring tools *
http://linux.softpedia.com/get/Multimedia/Video/Blu-ray-video-authoring-tools-28112.shtml
* UDF generator, does not generate ISO9660 structures
Update 1/23/2009
Looks like these tools compile under 32-bit systems, but not 64-bit systems. A user (E Chalaron) got this to work under 32-bit Ubuntu Feisty. Thanks E!
*** end update ***

Nero 3 Linux product
http://club.cdfreaks.com/f104/blu-ray-burning-hw-support-236218/
http://www.burnworld.com/software/cdrburning/linux.htm
http://www.nero.com/enu/linux3.html?NeroSID=75c7543438b27626c11913f2ed0c329e

Recent prices
http://club.cdfreaks.com/f142/blu-ray-blank-media-player-recorder-prices-japan-254787/

Hardware
http://www.addonics.com/support/application_notes/app_hd.asp
LG BE06LU11 Blu-ray
LG GGW-H10N Blu-ray/HD-DVD
LG GBW-H10N Blu-ray
Panasonic SW-5582 Blu-ray

Playing BluRay/HDDVD under Ubuntu
https://help.ubuntu.com/community/RestrictedFormats/BluRayAndHDDVD

Other Options
Perhaps run HD DVD Fab under Wine
http://ubuntuforums.org/showthread.php?t=763837

Google, dammit
http://www.google.com/search?num=100&hl=en&rls=com.microsoft%3Aen-us&q=burn+blu+ray+video+in+linux

Other BluRay references
http://sourceforge.net/projects/blurayauthor/

Fedora 9 x86-64, Cinelerra dependencies

2008-11-17T22:42:00.030-05:00

I'm happy to report that the installation of Fedora 9 x86-64 went very smoothly tonight. I yanked down a DVD install from here via torrent. I then burnt an ISO dvd of Fedora 9 using my own instructions here. From the perspective of a Cinelerra advocate, the biggest change from Fedora 7 is that Fedora 9 is more reliant on the ATrpms repository for Cinelerra source code dependencies.

Update 2009/02/15
Since writing this article, I've had very strange crashes and hangs from Cinelerra on Fedora 9. So I've moved on to using Fedora 10 x86-64. The general steps listed below to install Cinelerra still apply, but here's a post that summarizes the steps on how to build Cinelerra from source on Fedora 10, x86-64
*** end update ***

Advice on the Use of Repositories
As a general note, use as few repositories as possible for the various Cinelerra dependencies. Mixing many repos will result in a compile that doesn't work or worse, poor performance or odd behavior in Cinelerra resulting from slightly incompatible libraries. I've lived both and the latter is far worse because you'll spend hours or days pulling your hair out when, in the end, you've got some natty problem that only occurs between this library or that library. Ugh! I get the shivers just thinking about it!

Building Cinelerra from Source?
If you're using Cinelerra on Fedora 9 and want to build Cinelerra from source, here's what you need to do. There will be only three repos needed:
1) Fedora
2) ATrpms
3) Freshrpms (only for mjpegtools)

12/17/2008 NOTE on my strikethrough above
It was brought to my attention that RPM Fusion is the new repository of the repositories for Fedora (a note about Fedora and ATrpms). As I experimented more with my Fedora 9 build, I found an issue with Cinelerra hanging that I will describe in a later post. I fixed the problem by removing the ATrpms dependencies and adding RPMFusion as the only additional Fedora repository.

To reiterate, going forward, I am only using RPM Fusion in addition to Fedora's own repo.

The text below has been updated to reflect this new reality.
end NOTE

There will be only two repos needed:
1) Fedora
2) RPM Fusion

Here are the steps
1) install base Fedora 9 by selecting Office/Productivity and Development tools

2) The set of Cinelerra dependencies will come mainly from the RPM Fusion repository, so add the Fusion repo from here:
http://rpmfusion.org/Configuration

3) In addition to the Fedora repo, you'll now have RPMFusion added as a repository. Use the following script to install core programs for the Cinelerra build. Don't forget to chmod a+x your script!
yum install gsm-devel \
libvorbis* \
libogg* \
libtool* \
libtheora* \
libpng* \
libjpeg* \
libtiff* \
esound* \
audiofile* \
libraw1394* \
libavc1394* \
freetype* \
fontconfig* \
nasm \
e2fsprogs* \
OpenEXR* \
fftw \
fftw-devel \
libsndfile* \
libiec61883* \
libdv* \
libquicktime \
ffmpeg \
xvidcore* \
lame \
lame-devel \
a52* \
faad2* \
x264* \
mjpegtools \
faac*

4) As the Cinelerra CVS source code is no longer available via subversion, install git:
yum install git

Here's a good intro to git
Another good git reference
http://www-cs-students.stanford.edu/~blynn/gitmagic/ch02.html

Here are a couple useful git commands:
To find an earlier version of source code:
git whatchanged --since="20 weeks ago"

To checkout an earlier version of source code:
git checkout [revision number]

example:
git checkout d91e062cadb8a5a7b8c35e9092234948d6918767

5) Grab the Cinelerra CVS source:
git clone git://git.cinelerra.org/j6t/cinelerra.git cinelerra_source

6) Run autogen.sh
[mule@ogre cinelerra_source]# ./autogen.sh
User defined paths to the preferred autoconf and automake versions.
Read the script if you would like to modify them.
AUTOMAKE=automake
ACLOCAL=aclocal
AUTOCONF=autoconf
AUTOHEADER=autoheader
..

7) Run configure
[mule@ogre cinelerra_source]# ./configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
..

8) Hopefully, configure ran properly and shows that you have all the prerequisites for a build from source:
Summary of mandatory components:
libogg found
libvorbis found
libvorbisenc found
libvorbisfile found
libtheora found
OpenEXR found
libdv found
libpng found
libjpeg libraries found
libjpeg headers found
libtiff libraries found
libtiff headers found
FreeType 2 found
libx264 libraries found
libx264 headers found
libuuid libraries found
libuuid headers found
mjpegtools found
libfftw3 libraries found
libfftw3 headers found
liba52 libraries found
liba52 headers found
libmp3lame libraries found
libmp3lame headers found
libsndfile libraries found
libsndfile headers found
libfaac libraries found
libfaac headers found
libfaad libraries found
libfaad headers found

Summary of optional components:
ESD subsystem found
ESD (Enlightenment Sound Daemon) is enabled
ALSA subsystem found
ALSA is enabled
libraw1394 found
libiec61883 found
libavc1394 libraries found
libavc1394 headers found
librom1394 libraries found
librom1394 headers found
Firewire is enabled
OpenGL 2.0 libraries found
Hardware acceleration using OpenGL 2.0 is enabled

Now type
make

to start compilation.

9) Run "make"

10) Hopefully, there were no errors on make, so run "make install"

11) As the topper, don't forget to install some media players and extra encoding tools!:
yum install avidemux mencoder mplayer transcode audacious vnc

Good luck!
The Mule

Update 2008/11/23
I verified that importing live HDV video from my cam via test-mpeg2 still works. This is done with the following command:
test-mpeg2 -r [node] [file]
end update

playing Tokyo Reality in 1080p

2008-11-16T16:50:00.028-05:00

The guys at Akihabara News got their hands on a Canon EOS 5D Mark II and produced some beautiful (though shakey) video while running and gunning around Tokyo:

The video is on Vimeo, but the guys kindly also made the 1080p source available here. I downloaded the gigantic 1.8GB Torrent from here. That is 1.8GB for six minutes and ten seconds of video. Wow!

Linux Playback
I wanted to see which media players could handle such a large file. Here were my results on my Fedora 7 x86-64 system:
- dual quad core, 1.6Ghz
- 2GB
- NVidia 8800GT dual head system with twin Dell FP1905 monitors

mplayer played the file cleanly if the application window was stretched to a max of about 1400 pixels wide. Any wider, and mplayer would stutter.

xine couldn't play the file as it seems I do not have the correct codec installed. I got the dreaded "file uses an unsupported codec" error:

ffplay played it with slight audio stutters and the following error:
[mpeg4aac @ 0x3947e23ca0]faac: frame decoding failed: Gain control not yet implemented

I will have to investigate this.

Update 2008/11/23
Reviewing Google for this error, most of the suggestions for fixing the problem state that you should have the latest version of faad2/faac. According to the developer at www.audiocoding.com, I do:
faac x86_64 1.26-3.fc9 installed 182 k
faac-devel x86_64 1.26-3.fc9 installed 49 k
faad2 x86_64 1:2.6.1-10.fc9 installed 344 k
faad2-devel x86_64 1:2.6.1-10.fc9 installed 414 k

So, I'm at a loss why these messages are occurring.
end update

I converted Tokyo Reality using mjpeg as the video compression method:
ffmpeg -i Tokyo-Reality-h264-1080p.mp4 -b 3000k -vcodec mjpeg -ab 256k -ar 44100 -acodec mpeg4aac -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -me hex -subq 5 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 tokyo.mp4

On my Dell SC1430, 1.6Ghz with eight cores, the conversion took about the same time as the file was long, about 6 minutes, 10 seconds. The size of the original was 1.8GB; the size of the conversion was 1.6GB. Not much difference there.

Update 2008/11/22
I compared the output of the original to the output of the MJPEG conversion. On the left of the below screengrab is the original from Akihabara. On the right is my conversion. You'll notice that the converted image on the right is slightly more saturated than the one on the left. I'll have to play with the conversion parameters to get the colors a little more like the original.

end update

When I replayed this video, within about four minutes, I exhausted 2GB of RAM and 4GB of swap. Holy crap! The normal Cinelerra editing functions (cutting/pasting) did not exacerbate this memory issue. Only the replay function seemed to suck up all my memory:

The replay was a little choppy at the beginning, but ran at 30fps. However, as RAM filled up, playback performance dropped to 12fps, as RAM was exhausted and swap was being utilized. Once swap was exhausted, the entire box locked up! Scary!!

Update 2008/11/17
I had been planning on upgrading my system to Fedora 9 and the above memory leak was enough for me to say "fuck it" and just do the upgrade. Upgrades are increasingly complex as I've added four RAID drives to my setup. Well, just when you think it is going to be a nightmare, along comes Fedora and actually made the process pretty seemless. Within two hours, I had Fedora 9 installed, all my Cinelerra source dependencies installed, Cinelerra compiled and up and running. Of course, this is from a guy who has been doing this for how many years now? But still..two hours..I hardly believe it myself.

The icing on the cake is that my memory leak is no longer present! The below chart show CPU utilization and memory while the video plays:

So far, the system is much more responsive than the old Fedora 7, 64-bit. I guess I had some old/outdated/corrupted libraries in there. Now playback of Tokyo Reality in Cinelerra is more consistent, albeit at a slower 19fps.
end update

MacBook Pro Playback
I next copied the file to my 2GB, dual core Intel 2.2Ghz MacBook Pro 17". I attached my 42inch display to the second head on the MacBook's video card. The file played in QuickTime. It played without errors when I manually enlarged the Quicktime window to fill the screen; however, QuickTime stuttered when the video was maximized to Full Screen using the 42" monitor as the output display.

Finally, I tried to play the file on my MediaGate to absolutely no avail.

So, it looks like the only reliable players are mplayer on Fedora 7 and QuickTime on my MacBook Pro.

I think I need to upgrade my Fedora 7 system to a newer OS. Hopefully, a more recent OS and supporting encoders/decoders will do a better job of playing these large files back.

The Mule

using partimage with RAID

2008-11-16T10:24:00.011-05:00

Background
As I am planning on a purchase of a 1080p cam, I will need my system to be up on the latest and greatest kernal and software to get the highest performance from Cinelerra. In that light, I'd like to backup my current Fedora 7 boot and root filesystems, just in case something goes wrong with the Fedora 9 install.

Partimage and My System
I will use partimage to backup these filesystems. Partimage will need to see source and destination filesystems. My first task is to figure out what I have. I built this system over a year ago and don't remember all the specifics of which physical drive has x or y filesystems. I could go back into my notes to find out how I partitioned my system, but that would be cheating. So let's see what the filesystem tells me.

The first thing I do is look at the output of df:
[mule@ogre ~]# df -m
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/md0 457295 6720 426972 2% /
/dev/md2 469453 417004 28602 94% /mnt/videos
/dev/sda1 99 19 76 20% /boot
tmpfs 1007 0 1007 0% /dev/shm

I have two RAID devices, one mounted as my root partition (/dev/md0) and one mounted as my video storage (/dev/md2). Next, I see that /dev/sda1 is my boot partition. Finally, there is a filesystem defined for shared memory, though I am not concerned about saving the contents of that as it is RAM.

How It Works
Partimage backs up filesystems that are not mounted. But partimage is started from a bootable rescue disk, like Knoppix or SysRescCd. The twist here is that I am using RAID partitions. Thus, when I boot with one of these CDs, I will need to assemble my RAID drives in order to have a source to backup (my root filesystem) and a destination to write to (my /mnt/videos filesystem). Partimage will not use a mounted filesystem as a source, but I will need to mount the destination.

Assembling My RAID Drives
I have forgotten the configuration of my RAID drives, so I look at /etc/mdadm.conf to figure out what partitions and UUIDs make up my two RAID sets:
[mule@ogre ~]# cat /etc/mdadm.conf
# mdadm.conf written out by anaconda
DEVICE partitions
MAILADDR root
ARRAY /dev/md0 level=raid0 num-devices=2 uuid=c0d4b597:c33b3014:ab694cee:76920165
ARRAY /dev/md2 level=raid1 num-devices=2 UUID=1705b387:1c71d83e:364b60b4:fb0cc192

This tells me that my root partition (/dev/md0) is a stripe set (RAID0) and that the storage for my important stuff, all my videos in /mnt/video is mirrored (RAID1) in case of a failure. I'm glad I built the system this way, as I like the performance benefits of a stripe set for my root partition, but I would consider it tragic if I lost all my work. Therefore, I've mirrored the video drive on two drives in case of a failure.

Video Display Problem with Linux and NVidia Card
For some reason I have not figured out, I cannot see virtual consoles once I exit Gnome. This is due to some incompatibility between the NVidia 8800GT card and my Dell SC1430. This also effects the display when I boot with either Knoppix or SysRescCD. Using these tools, the screen goes black and I can't see any terminal sessions or virtual consoles. Therefore, in order to use the boot cd, I removed the NVidia card and booted using Dell's ATI ES1000 onboard video.

Booting with Knoppix
Once Knoppix is fully booted, I need to assemble my two RAID partitions. You can use either use the UUID or the super-minor number of each RAID set to do this. I chose the super-minor, as it was simpler.

Assemble the Source RAID set
Here I am assembling the source drive, my root filesystem:
root@Knoppix:/ramdisk/home/knoppix# modprobe md
root@Knoppix:/ramdisk/home/knoppix# mdadm --assemble -m 0 /dev/md0

Mount the Destination Partition
Since I want to store the backup image on the same mirrored drive set that holds my videos, I'll mount that partition as the destination for the partimage. Of course, I first have to create the mount point:
mkdir /mnt/videos
mount -t ext3 /dev/md2 /mnt/videos

Run Partimage to Backup Root Partition
I'll need three things to run partimage:
-an assembled RAID set of the source, my root/boot partitions, unmounted
-an assembled RAID set of the destination, mounted
-a compression method

Here's the partimage process:
1) Select the partition to save and give the backup a destination and name. Note that the "Save partition into an image file" is selected as the default behavior:

2) Select a compression method:

3) Give the backup image a description (optional):

4) Partimage takes a few minutes to gather information about large (500GB+ drives), but then displays basic information about the partition to be backed up:

5) Partimage starts the imaging process. I had about 6GB to backup:

6) Partimage took about 20 minutes to create the backup image:

Backup complete. The restore process is similar, but instead of backing up an image file as in Step 1 above, you'll choose the "Restore Partition from an image file" option.

Run Partimage for Boot Partition
Since my boot partition is small 128MB, creating a backup image shouldn't take very long. My boot partition is /dev/sda1

Now I should be ready to an upgrade to Fedora 9. One hurdle I already see: the Fedora 9 installation doesn't recognize pre-existing RAID sets. Yarg. Looks like I might have to blow away the existing stripe set that is home to my root partition. Let you know how that goes.

Update 11/17/2008
The Fedora 9 x86-64 install went well. Here are some of the natty details:
http://crazedmuleproductions.blogspot.com/2008/11/fedora-9-x86-64-install.html
end update

Good day,
The Mule

References
mdadm man page

converting 1080p video, part III

2008-11-06T21:53:00.013-05:00

Here is another experiment in order to justify my planned expenditure of $4000 on the Canon EOS 5D Mark II. Down the road of doom I plod, unabated in my quest.

If I am to get the new Canon, I will be integrating some of its video along with video from my current 720p cam, the JVC HD10U. Therefore as a test, I threw some test 1080p video from the Canon and output from my JVC together on the timeline in Cinelerra.

Upconvert 720p or Downconvert 1080p?
For the time being, I don't want to upconvert the 720p video. Instead, I reduced the 1080p's resolution (downrezzed) in Cinelerra. This makes more sense from a practical point of view, as rendering 1080p video in its pure, unadulterated state will surely:
1) increase my storage needs
2) increase the time to render final output

In the future, after I have a few bucks lying around to spend on a next generation dual, quad core with terabytes of disk and a bluray writer, I will then start rendering final videos to 1080p format.

Integrating the two videos
Back to the task at hand, I put the mjpeg conversion of the 1080p video from my last 1080p blog entry on the timeline, along with another video I recently finished:

I set my project format to 720P:

This reduced the size of the 1080P track in the Compositor:

I could see that I only had part of the 1080p video displayed, I used a calculator to find the ratio between 1280 and 1920 pixels:
1280/1920 = .6667

In the Compositor window, I entered this percentage into the Z-Axis of the Projector's "Show Tool Info" screen:

This effectively "zoomed out" on the 1080p video track so that the entire frame is now shown:

Now, both tracks of the video are for all intents and purposes, 720P. If interested, I've put the downrezzed video (3.2MB) here for you to check out.

Please forgive the lousy quality of the 720p track, but the JVC is really horrible in low light..another reason why I want to get the Canon.

Update 11/9/2008
One thing I neglected to mention is that the frame rate of the 1080p track from the Canon is 30fps, whereas the 720p video track from my JVC is 29.97. In order to accurately merge these two tracks into my 720p project, I will need to apply the Decimate video effect in Cinelerra. Decimate drops frames from a video track. It takes an input frame rate of a higher fps and uses the project's lower frame rate as output. In this case, I want to lower the frame rate of the Canon's track from 30 down to 29.97fps. So the input rate would be 30fps and the output is the frame rate of the project, 29.97 fps.

As noted in the Cinelerra documentation, always place computationally intensive effects AFTER the Decimate effect, as those effects will be rendered at the lower frame rate, thus using less CPU cycles.

Using Decimate, I can now be assured that I will have no synchronization problems when merging 1080p and 720p video.
end update

Tally ho!
the mule

flash player 9 install in Fedora 7/9/10 64-bit

2008-11-02T13:24:00.007-05:00

I inadvertantly removed the flash-plugin from my 64-bit system and figuring out how to reinstall the thing took about two hours, so I thought I'd write the steps down:

Update 2009/02/21
Finally, Adobe has released a 64-bit Flash plugin:
http://labs.adobe.com/technologies/flashplayer10/

And, shocker of shockers, it actually works!

To Install Flash Plugin on x86-64
You'll download the tarball from here:
http://labs.adobe.com/downloads/flashplayer10.html

The only thing in the tarball is libflashplayer.so. To install the 64-bit Flash plugin, simply move libflashplayer.so into your user's .mozilla/plugins directory and restart Firefox.

Even more amazing, the bloody thing works on my Fedora 10, x86-64 virtual machine running in VMware Fusion on my MacBook Pro! Yee haw!

Awesome!
end update

Update 2008/12/19
As my recent build of Fedora 9 may have gotten corrupted by bad ATrpms repo files, I upgraded AGAIN, this time to Fedora 10, x86_64. Here are some nice instructions for the Fedora 10 Flash install:
http://fedoraproject.org/wiki/Flash

I learned a new trick in Firefox to check plugins. Type "about:plugins" in the URL bar.
end update

Update 2008/11/18
I just upgraded to Fedora 9, x86_64. Here are some nice instructions for the Fedora 9 Flash install:
http://fedorasolved.org/browser-solutions/flash
http://macromedia.mplug.org/
end update

As Flash 9 was not built for 64-bit systems, I'll need to install nspluginwrapper to get Flash to work on my Fedora 7, 64-bit box.
1) install nspluginwrapper
yum install nspluginwrapper

Installed Packages
Name : nspluginwrapper
Arch : x86_64
Version: 1.0.0
Release: 1
Size : 124 k
Repo : installed
Summary: A compatibility layer for Netscape 4 plugins

Description:
nspluginwrapper makes it possible to use Netscape 4 compatible plugins
compiled for i386 into Mozilla for another architecture, e.g. x86_64.

This package consists in:
* npviewer: the plugin viewer
* npwrapper.so: the browser-side plugin
* nspluginwrapper: a tool to manage plugins installation and update

2) Download the flash 9 install
wget http://fpdownload.macromedia.com/get/flashplayer/current/install_flash_player_9_linux.tar.gz

3) Unpack the tarball
gunzip install_flash_player_9_linux.tar.gz
tar xvf install_flash_player_9_linux.tar

4) From the install directory created from the extract, copy libflashplayer.so to Mozilla's plugin directory:
cp libflashplayer.so /usr/lib/mozilla/plugins/

5) Use nspluginwrapper to enable the 32-bit flash to work in 64-bit Firefox
nspluginwrapper -i /usr/lib/mozilla/plugins/libflashplayer.so

6) Restart Firefox.

Lovely, now YouTube works again.

that's all folks!
mule

converting 1080p video, part II

2008-10-28T17:19:00.031-04:00

A couple nights back, I spent a few hours finding a usable intermediate format for 1080P video editing. Of course, my goal was to prove that I can still use my preferred NLE Cinelerra in order to edit the gorgeous, high definition output from the Canon EOS 5D Mark II. An alternative way of putting it is that this is my justification for purchasing what will amount to a $4000 camera!

Import: which format works well?
Since Cinelerra is rather picky about the types of video it accepts (see my original Quicktime compatability document), it was a challenge to find a Cinelerra-editable intermediate format for that test 1080p video I told you about in the first part of this two-part blog entry. The video is a five-second city scene of a bicycler launching from a stop. That video is 23MB.

Keep in mind that various versions of media encoders (like ffmpeg and mplayer) do not always implement codecs and container formats consistently. Also, program dependencies for the encoders across different Linux distros complicate matters. So what I state as working below may not work for you. (Your mileage may vary). Note that I am currently using Fedora 7, 64-bit.

Caveats aside, transcoding the biker video to the following formats did NOT work:
- I420 from ffmpeg
- rawvideo (RAW YV12) from ffmpeg

Here are a couple formats that did work:
1) MJPEG output from ffmpeg
2) RAW YV12 output from mplayer

MJPEG from FFmpeg
Playback Performance
This format seems to be a likely candidate, as I got about 15fps on my dual, quad core Dell SC1430 in Cinelerra.

File Size
The resulting file size is small..about 35MB for five seconds of 1080P.

Image Quality Compared to Original
The image quality is very good. However, the colors seem bit oversaturated and dark in contrast to the original. With a bit of tweaking to the conversion command, I might be able to get more realistic colors out of the conversion. Here's a comparison shot:

Editing Notes
No problems surfaced with a couple initial edits and renderings. As this is a compressed format, there will be some loss of quality over successive encodings.

Here is the command I used to convert the video:
ffmpeg -i Video1.MOV -b 3000k -vcodec mjpeg -ab 256k -ar 44100 -acodec mpeg4aac -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -me hex -subq 5 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 testmjpeg.mov

This is the same conversion command that I ran in part I of this blog entry.

Information about the file looks like this in mplayer:
Playing testmjpeg.mov. ISO: File Type Major Brand: Original QuickTime Quicktime/MOV file format detected. [mov] Video stream found, -vid 0 VIDEO: [jpeg] 1920x1080 24bpp 30.000 fps 0.0 kbps ( 0.0 kbyte/s) ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffmjpeg] vfm: ffmpeg (FFmpeg MJPEG decoder) ==========================================================================

RAWYV12 from mplayer
Playback Performance
Playback is slow, 7fps, roughly 1/2 the speed of MJPEG. Not a show stopper.

File Size
Huge. About 450MB for about five seconds of video. Woah!

Image Quality Compared to Original
Image quality is very good as well. Less saturated then the mjpeg version. That's what almost 100MB/sec pays for.

Editing Notes
This is an uncompressed format, corresponding to the YUV 4:2:0 spec:
http://en.wikipedia.org/wiki/YUV#Y.27UV420p_.28and_Y.27V12.29

Also, here is an excellent article on understanding color sampling:
http://www.dvxuser.com/articles/colorspace/

Cinelerra loads the raw YV12 file, but the timeline does not show thumbnails. Not a show stopper, but a bit of a bummer. The one benefit of yuv4mpeg stream from mplayer is that you can feed that stream directly into mjpegtools for further processing.

Update 2008/11/22
It seems that 1080p in raw yuv format is actually unusable in my Fedora 9 Cinelerra install. When I load a project with a large raw yuv file, Cinelerra hangs for ten minutes as it loads the file. Once loaded, the GUI tends to freeze for another ten minutes. Thus, it seems that MJPEG may be my only choice for rendering 1080p.

I will continue to experiment.
end update

Here is the command I used to convert the video:
mplayer Video1.MOV -vo yuv4mpeg

I received this message while trying to convert the video
************************************************
**** Your system is too SLOW to play this! ****
************************************************
Possible reasons, problems, workarounds:
- Most common: broken/buggy _audio_ driver
- Try -ao sdl or use the OSS emulation of ALSA.
- Experiment with different values for -autosync, 30 is a good start.

So, I amended my command to add the autosync feature, which gradually adjusts the audio/video synchronization based on audio delay:
mplayer Video1.MOV -autosync 30 -vo yuv4mpeg

That seemed to alleviate the messages. Without redirecting to a specified filename, Mplayer outputs a file called "stream.yuv".

Information about the file looks like this in mplayer:
Playing stream.yuv. YUV4MPEG2 file format detected. YUV4MPEG2 Video stream 0 size: display: 1920x1080, codec: 1920x1080 VIDEO: [YV12] 1920x1080 12bpp 30.000 fps 0.0 kbps ( 0.0 kbyte/s) ========================================================================== Opening video decoder: [raw] RAW Uncompressed Video VDec: vo config request - 1920 x 1080 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [xv] 1920x1080 => 1920x1080 Planar YV12 [ASPECT] Warning: No suitable new res found! [ASPECT] Warning: No suitable new res found! Selected video codec: [rawyv12] vfm: raw (RAW YV12) ==========================================================================

Quality
There seem to be quite a difference in the colors rendered by each format. The MJPEG-formatted file seems to much closer to the original than the raw YV12.

Applying Effects

For fun, I applied an oil painting effect to this five seconds of video. I then rendered the output to MJPEG format. I was disappointed to find out that five seconds of video with the oil paint effect applied takes a full three minutes and twenty seconds to render at 1080p in my dual, quad core Dell SC1430. Holy cow! I guess I won't be doing Star Wars green screens in 1080p!

In the interest of full disclosure, the oil paint effect is a notorious CPU hog and is not indicative of the type of work the average editor will perform. Another note: while rendering the output, all eight CPUs were maxed out at 95% utilization. Kowabunga!

To give people hope, applying a simple title to the image doesn't do too much damage to load on the CPU. The video with a title rendered to MJPEG format took twenty seconds.

Thoughts
My goal is to get some really fantastic looking video rendered from Cinelerra. In combination with the new Canon and some wise encoding choices, I believe I should be able to do this. This article shows that I'm getting closer, but I'm not there yet. I'm hoping to get closer with another round of experimentation.

One final thing..be ready to spend money on RAM. I noticed my paltry 2GB was immediately sucked up by Cinelerra when I was doing these various test videos. I'm going to get another 4GB and will let you know if that helps.

more to come.
The Mule

converting 1080p video, part I

2008-10-23T23:17:00.027-04:00

I was interested in buying the new Canon EOS 5D Mark II, a really sweet bit of kit:
Amazon: Canon EOS 5D Mark II
Canon Product Page
Canon Learning Center
Rob Galbraith Review
Manual

I was excited at the possibility of stellar high quality video at a somewhat reasonable price. See Vincent Laforet's great demo video here:
http://blog.vincentlaforet.com/2008/10/10/without-further-ado-reverie/

So I downloaded test video output from a review of the preproduction cam here:
http://www.dpreview.com/previews/canoneos5dmarkII/page15.asp

Disclaimer
DPReview stated that these videos are direct from the cam, though according to Canon, the production model uses MPEG4 video compression. This does not jibe with my results, as I found by reviewing the output of mplayer and Quicktime on my MacBook that these test videos actually use H264 video compression. Strange. Of course, we'll see what the real deal is once the camera is available for purchase. Regardless, my testing procedures below maybe helpful for people using Linux and/or Cinelerra that need to work around similar problems.

Update 10/25/2008
I downloaded a couple longer clips from the review here:
http://www.dpreview.com/news/0809/08091705canon_5dmarkII.asp

My results were consistent with the original post. Interestingly, it took six minutes to convert one minute of 1080P video on my dual, quad core Dell SC1430. Oh Momma, 1080P is a resource hog!
End Update

Linux Media Player Results
Not so good. I was able to replay the video in mplayer fine, but vlc and avidemux2 hung half way, and xine played, though very choppily. Most of the above showed output errors of various kinds.

Next, I thought I'd see if its 1080P video output was usable at all in Cinelerra.

Cinelerra Results
Putting the original 1080P video into Cinelerra gave me a bunch of ugly errors, like so:
[h264 @ 0x2aaaaaf7e1b0]concealing 8160 DC, 8160 AC, 8160 MV errors [h264 @ 0x2aaaaaf7e1b0]AVC: Consumed only 161417 bytes instead of 161420 [h264 @ 0x2aaaaaf7e1b0]Unknown NAL code: 22

And the Cinelerra timeline and compositor windows weren't very promising either:

Convert!
So, I did what all good Cinelerra users do:
Convert the video to a usable format!

This command seems to produce very good output from a 1080P, H264 encoded video:
ffmpeg -i Video1.MOV -b 3000k -vcodec h264 -ab 256k -ar 44100 -acodec mpeg4aac -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -me hex -subq 5 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 test.mp4

Let's take the command options apart:
-i Video1.MOV: my input file
-b 3000k: bitrate of 3000K
-vcodec h264: use the h264 output video compression algorithm
-ab 256k: use an audio bitrate of 256kbps
-ar 44100: use an audio sampling rate of 44.1Khz
-acodec mpeg4aac: use the Apple Audio Compression codec

Next set of options related specifically to x264
-coder 1: enables CABAC entropy encoder used by x264 (better compression)
-flags +loop: enables loop filter
-cmp +chroma
-partitions +parti4x4+partp8x8+partb8x8: improves quality by looking at inter/intra partitions (i b p)
-me hex: set motion estimation method to hex (range-2 search of six surrounding points)
-me_range 16: max range of motion search (hex is limited to 16), higher useful on HD
-subq 5: good medium for higher speed encoding
-g 250: group of pictures size
-keyint_min 25: set minimum length between IDR frames (keyframes)
-sc_threshold 40: adjusts sensitivity of x264's scenecut detection
-i_qfactor 0.71: qscale (quality) difference between I-frames and P-frames

Finally, the output:
test.mp4: my output file

I don't know much about those switches. Here are two good pages explaining at least the words, if not their meaning, of these cryptic options:
FFmpeg x264 mapping
x264 (H264) options

Update 10/25/2008
However, I did see a number of these errors again while doing the conversion:
[h264 @ 0x3c2d71ab30]AVC: Consumed only 197265 bytes instead of 197268ts/s
[h264 @ 0x3c2d71ab30]AVC: nal size 0

Searching the web, it seems that they may have to do with an old version of ffmpeg:
http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2007-October/012075.html

I am currently running the following: =============================================================================
Package Arch Version Repository Size
=============================================================================
Removing:
ffmpeg x86_64 0.4.9-0.37.20070503.lvn7 installed 527 k
ffmpeg-libs x86_64 0.4.9-0.37.20070503.lvn7 installed 3.8 M

And it's going to be a pain to compile with external ffmpeg libraries. I think I will hold off on that for now.
End Update

The original (Video1.MOV) and converted (test.mp4) files were marketedly different sizes:
-rw-r--r-- 1 root root 4214234 2008-10-23 23:15 test.mp4 -rw-r--r-- 1 root root 23690277 2008-10-23 22:55 Video1.MOV

As read by mplayer with -identify option, diffing the original and converted file's properties showed no differences. Here is what mplayer thinks both files :
[mov] Video stream found, -vid 0
VIDEO: [avc1] 1920x1080 24bpp 30.000 fps 0.0 kbps ( 0.0 kbyte/s)
ID_DEMUXER=mov
ID_VIDEO_FORMAT=avc1
ID_VIDEO_BITRATE=0
ID_VIDEO_WIDTH=1920
ID_VIDEO_HEIGHT=1080
ID_VIDEO_FPS=30.000
ID_VIDEO_ASPECT=0.0000
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
ID_VIDEO_CODEC=ffh264
Audio: no sound
Starting playback...
VDec: vo config request - 1920 x 1080 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
VO: [xv] 1920x1080 => 1920x1080 Planar YV12

This was odd, as mplayer spat out errors like this while playing the original:
[h264 @ 0xcfa780]AVC: Consumed only 197265 bytes instead of 197268 [h264 @ 0xcfa780]AVC: nal size 0

Once the file was converted, mplayer showed none of these errors.

Linux Media Player Results
I'm happy to say that the converted file replayed well in all the Linux media players, xine, mplayer and vlc, with the notable exception that playback in avidemux2 was slow.

In mplayer, the converted file did not show any errors, outside of a minor ASPECT warning error:
[ASPECT] Warning: No suitable new res found!

From a still, you can't really tell much of a difference..at least I couldn't. Note that the below images have been cropped for easier comparison, so they are not the full 1080P (1920x1280) resolution.

Original

Converted

The big test was bringing the converted file into Cinelerra. Since the OS level media players didn't have a problem, I was hopeful that Cinelerra wouldn't have any issues. Loading the file, I received no errors. However, playback was horrendous. I'd say that I got about 1fps in the compositor, though Preferences (Shift-P) showed that I was getting 32fps. Hmmm. Something definetly wrong here.

Final shot before I go to sleep
While in Cinelerra, I rendered the already converted 1080P content into one of the formats Cinelerra is happiest using, Quicktime using JPEG Photo compression. Rendering that video took no time at all (there was no audio track). Reloading the video back into Cinelerra, the file play more smoothly than the original conversion, but still had problems. I got 6fps. CPU on my dual, quad core was about 20% across all CPUs during playback (see below image). But memory use went through the roof! Swap was up too:

Woah! What's up with that? Well, looks like I have more testing to do. The possibility of gorgeous 1080P HD video has me slavering. Perhaps my eyes are too big for my stomach? As in everything Linux, this will take time.

to be continued..
the mule

Reference
http://bbs.archlinux.org/viewtopic.php?id=35836
thanks Skottish!

iTunes/iPod video workflow, scripted

2008-10-04T11:37:00.012-04:00

I am going to revisit my conversation about workflow. Here's what we briefly discussed:
- the transformation of an idea (video) into reality and distributing it (in this case, using iTunes)

With today's internet, the steps involved are broad-based:
- idea creation, storyboard, distribution, production, archiving, marketing

Update 2008/11/22
I've added a few more details to my workflow in a new post here.
end update

I shall give you an example and how I reduced the amount of time spent creating and distributing my content.

When not working, my world is playing music with a band of itinerant musicians called the StormPigs. We gather together once every couple of months to play freeform music. No prior thought involved, just play. The joy of this is being together and having a good time. Otherwise, we are all busy professionals with full-time jobs and families. In remembrance of that good time, I produce videos of the event, distributed via iTunes and YouTube.

As time seems compressed these days, I want to spend as little time as possible behind the keyboard (though I am a technologist by trade). And as readers of this blog know, I am avid proponent of Linux. The beauty of Linux is that the system is completely configurable and flexible. But with this power comes a price. You have to invest the time to learn the shell, some bits of scripting and other Linux arcana. Consequently, it is daunting to the newcomer. But the benefits return to you many times over, as time you once spent on minutiae can now be spent thinking of new ideas for shows and creating new content, rather than simply focusing on the details of getting a file up to the server or copy and pasting content from one application to the other.

I am not a programmer of fanciful GUI front ends. I am a guy who just needs to get work done. So I try to solve my problems in the simplest way possible using the Linux programs and bash shell scripts to tie multiple programs together.

Here is the latest problem I needed to solve:
- how to I get my videos onto the web and in an iTunes ready form as quickly as possible?

In that light, I have come up with some scripts to help me on my way:
- the first encodes my editing video project into various formats (HDV, DVD, podcast)
- the second creates the list of songs from the video that will go into the podcast
- the third merges that songlist information into the podcast
- the fourth creates a new iTunes RSS feed (XML file) from the songlist information
- the fifth uploads the new podcast to my webserver
- the last is a wrapper that starts the other five

The encoding script is most useful and is the basis for the others. This script takes 720P video and 48Khz MPEG, Layer II stereo audio output rendered from a Cinelerra project and converts it to various formats: MPEG2 Program Stream, HDV, DVD and iTunes/iPod compatible formats. You will need the following programs installed for this script to work:
-mplex
-vlc
-ffmpeg

I've found the quality of each output file to be very good to excellent.

You can wrap some validation and input around this script, but the guts of the script look like this, where the arguments enclosed in curly braces will be replaced by the names of your input and output files:
#!/bin/bash
echo "Input: M2A audio and MPEG2 720P video streams"
echo "Output: program stream"
mplex -f 3 -b 2000 ${AUDIO} ${VIDEO} -o ${PS}

echo "Input: program stream"
echo "Output: MPEG2-TS, HDV"
vlc ${PS} --sout '#duplicate{dst=std{access=file,mux=ts,dst="'${HDV}'"}}' vlc:quit

echo "Input: MPEG2-TS, HDV"
echo "Output: MPEG2 DVD"
ffmpeg -i ${HDV} -target dvd -threads 8 ${DVD}

echo "Input: MPEG2 DVD"
echo "Output: iTunes/iPod compatible MP4"
ffmpeg -y -i ${DVD} -an -v 1 -threads 8 -vcodec h264 -b 250k -bt 175k -refs 1 -loop 1 -deblockalpha 0 -deblockbeta 0 -parti4x4 1 -partp8x8 1 -me full -subq 1 -me_range 21 -chroma 1 -slice 2 -bf 0 -level 30 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -maxrate 450k -bufsize 2M -cmp 1 -s 720x480 -f mp4 -pass 1 /dev/null

ffmpeg -y -i ${DVD} -v 1 -threads 8 -vcodec h264 -b 250k -bt 175k -refs 1 -loop 1 -deblockalpha 0 -deblockbeta 0 -parti4x4 1 -partp8x8 1 -me full -subq 6 -me_range 21 -chroma 1 -slice 2 -bf 0 -level 30 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -maxrate 450k -bufsize 2M -cmp 1 -s 720x480 -acodec aac -ab 160k -ar 48000 -ac 2 -f mp4 -pass 2 -threads 8 ${MP4}

Stay tuned for discussions of the remaining scripts to make your life easier,
CM