Saturday, December 20, 2008

Cinelerra render compatibility on Fedora 10, x86-64

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.

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 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. Here is my latest effort at making the batch render feature part of the Cinelerra testing process:

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.

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

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.

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.

The Mule


josephcmiller2 said...

Cinelerra hasn't been very compatible with a wide range of formats. There is a tutorial for exporting PNG files and rendering with mencoder at so that one could convert to many different formats.

Cacasodo said...

That's for sure. In my four years of using Cinelerra, I've learned that if you need to find good formats to import and export to. For me, I use MPEG2-TS, in both 720P and 1080P forms to import into Cinelerra.

If I'm reimporting into Cinelerra, I'll generally use QT for Linux, JPEG or MPEG4 video compression with an MP3 or MP2 audio container.

If I'm exporting, I'll use mpeg2enc to export out a 720P or 1080P compliant video stream and MP3/MP2 audio. I'll further combine those into an MPEG-PS, HDV, DVD and iPod formats for a wide distribution.

Only took me about four years to figure this out.