Showing posts with label rendering. Show all posts
Showing posts with label rendering. Show all posts

Wednesday, January 27, 2010

batch render redux

As a follow up to this original post, I thought I'd give a few hints on working with the batch render function in Cinelerra. I've been using the batch render to prepare me for my new Fedora 12, x86-64 system. Specifically, I am using batch render to profile the capacity and speed of my current Fedora 10 system. After I install the new Fedora 12 system, I can then use the Fedora 10 performance baseline to tell me how much faster (or slower) the new system is in relation to the old system.

Selecting a Cinelerra Project
The first thing I did was use a short (~1 min) clip of a project that I had been working on:


I then used this project to output a short clip as the basis for the batch render:


Batch render is accessed by typing Shift-B within Cinelerra:


You can save a batch render list to XML format. This format is similar to the XML of the edit decision list (EDL) that Cinelerra stores when a project is saved. You can then load that XML to use later.

Batch Render Gotchas
I used a previous batch list to render out that short clip to about twenty different file formats. The batch render blew up a few times, so I had to get over a few obstacles:
1) the batch list I had saved months ago was out of date and the directory pointers in the XML were incorrect. I fixed the incorrect pointers by going into the vi text editor and doing a wholesale conversion with a sed construct:
:1,$ s/videos\/oldpath/videos\/newpath/g

1,$ says look for and make replacements on all lines. s means "search for.." The matching expression looks for the string "videos/oldpath" in the file and replaces it with "videos/newpath". g means "do the replacement globally"

2) my project had an improperly formatted Quicktime video track on the timeline. I kept getting Quicktime errors when the batch ran, which would crash Cinelerra. Once I removed that errant track, the batch render worked correctly.

3) once I got the batch running, my disk would fill up quickly as I was rendering to a few uncompressed formats. I deleted some very large, extraneous files and the batch was able to complete.

So you can see that you need to prepare both the base project and your system if you expect your batch render to run properly.

Command Line Batching
Once you get your batch working, another nice feature of batch rendering you can take advantage of is the ability of Cinelerra to do this at a command line. I just kicked off a batch job at the command line and see that it does work on a box with X installed. Nicely, it also give you an ETA:

[sodo@tbear ~]$ cinelerra -r /mnt/videos/cinelerra/batch/batchList.xml
/mnt/videos/cinelerra/batch/renderCompatibility.xml
Cinelerra 2.1CV (C) 2006 Heroine Virtual Ltd.
Compiled on Sat Jan 23 01:32:17 EST 2010

Cinelerra is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. There is absolutely no warranty for Cinelerra.
Render::run: /mnt/videos/cinelerra/batch/renderCompatibility.xml
Render::render: starting render farm
[mpeg4 @ 0x7ff313d3ba00]warning: first frame is no keyframe
[mpeg4 @ 0x7ff313d3ba00]concealing 1 DC, 1 AC, 1 MV errors
12% ETA: 0:07:45



Batch Results
So my goal was to profile my current system's capacity by capturing the system's cpu and disk utilization while the files rendered. To really see what is going on though, I thought it might be nice to have a graphical representation of the render as it occurs over time. So I spent some time writing a gnuplot script to plot the system utilization as the files rendered:

A bit of explanation may be required. I captured the output of vmstat to a file. VMstat has CPU load and wait i/o (disk utilization) statistics. While capturing that output, I kicked off the batch render.

In the graphic, you can see that different types of renders have different utilization profiles. For example, the mpeg4 renders were generally lower in CPU utilization (red line), while h264 renders used a lot of CPU. Similarly, the uncompressed formats like rgb/rgba/yuv420planar stress out the disk quite a bit (green line). Please excuse the fact that the filenames aren't perfectly lined up with each file's render profile..this was my first effort at graphing render times.

It will be interesting to see how the new Fedora 12 install affects the CPU. Also, I am planning on installing a new hardware RAID set, so I expect those green lines to go to zero (hopefully)!

ciao,
the mule

Saturday, January 16, 2010

best practices to alleviate audio sync problems in Cinelerra

Audio synchronization problems are the bane of video editors everywhere. Here's what I do in Cinelerra to try to prevent them.

The first thing to understand is that playback in Cinelerra is a separate process from rendering (exporting) your project to a final format. So it is a good idea to calibrate the audio-video synchronization of your files when they are played back in the Cinelerra compositor as well as the a/v sync of rendered output. More specifically:
1) You need to calibrate the audio you see being played back in the compositor. Do this by setting Audio Offset in the Preferences -> Playback -> Audio Out so that your playback audio is in sync with the video. I generally use ALSA as my audio driver under Preferences -> Playback. (You might also want to try to use OSS or ESound to see if those audio drivers help your playback sync issues.) For reference, my offset is .1 seconds.

2) You'll need to calibrate the audio and video once it is rendered out of Cinelerra. This doesn't have to be the absolute final format of the file. Just an intermediate file format to determine that audio is not drifting and in sync. You'll do this by setting Nudge on your audio tracks so that your rendered audio and video are in sync. Here's an article on nudge:
http://crazedmuleproductions.blogspot.com/2007/05/nudge-avidemux2-and-reminder-about.html

Let me give you an example.

My projects usually run about an hour on the timeline. When I start a project, I will concatenate a bunch of clips or raw videos on the timeline. I will then render a short segment of video, about 15 seconds long, from about 45 minutes into the timeline. The segment I take should have key features like someone speaking or someone hitting a drum that I can use to determine audio synchronization. I then render the file to a format that works well in the various Linux media players:
-Quicktime for Linux using MPEG4 video compression and MP4 or twos complement (pcm) audio compression
-Quicktime for Linux container using JPEG video compression and MP4 or twos complement

The side benefit of using MPEG4 video compression is that it renders damn fast.

The good thing about these steps is that if you work with the same format of video over and over, you won't need to change #1, the Audio Offset.

Here are notes regarding specific source formats and output formats.

MPEG SOURCE FILES to MPEG RENDERED OUTPUT
After much study and pain, I've found that when working with MPEG-TS HDV files as my source (and MPEG formats in general), the best pipe to render from Cinelerra in order to alleviate sync headaches is mpeg2enc. I'm not five channel yet, so I just export my 48.1Khz stereo audio as MPEG Layer II audio MP3s @ 384kbps. I then use mplex to combine my audio and video streams into a program stream. Further on, I use VLC to convert that PS into MPEG-TS (HDV) and then use FFMPEG to convert the HDV into DVD and iPod/iPhone compatible formats.

QUICKTIME (QT) SOURCE FILES to QT RENDERED OUTPUT
If my source video format is Quicktime for Linux (like from a screen capture), then I have no sync problems rendering out to QT for Linux.

MPEG SOURCE FILES to QT RENDERED OUTPUT
If I render my MPEG-TS, HDV projects using Quicktime for Linux as an output format (MPEG4 or JPEG video w/twos complement or MP4 audio compression), then I will get sync problems in the rendered output. I then follow the above best practices to alleviate the problem.

TEST YOUR OUTPUT
In Fedora, I've found that the best media players to test final output are mplayer, vlc and ffmpeg.

Finally, there are options to mplex and ffmpeg to offset audio and video sync problems:
mplex -O ; eg, mplex -O 350
ffmpeg -itsoffset ; eg, ffmpeg -itsoffset 0.35

Hope this helps,
the mule

Reference
My Article on Cinelerra's "nudge" parameter
FFMPEG HowTo
http://man-wiki.net/index.php/1:mplex

Friday, January 30, 2009

high quality h264 output

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 that no longer exists.

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 (again, no longer exists) 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 was something useful I stumbled up while researching this post.

-- the Mule --

 
PS 2023/04/16 - Sven from videoproc.com was kind enough to point out that Kino has been discontinued and not actively maintained since 2009, and its official website - Kinodv.org, was also completely shut down and out of service since April, 2021.

Sven recently published a guide talking about what happened to Kino and its official website, and you can check it here,
https://www.videoproc.com/resource/what-happened-to-kinodv.htm
 
Thanks again, Sven!

PS 2021/05/31 - Sven from videoproc.org wrote a fantastic piece on H.264 and H.265/HEVC encoding, I learned a lot from it.  Here's the link:

Monday, January 12, 2009

Water, a new Canon 5D video

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

Saturday, January 03, 2009

Canon 5D Mark II video: Cinelerra edit

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

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.

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. Here is my latest effort at making the batch render feature part of the Cinelerra testing process:
http://crazedmuleproductions.blogspot.com/2010/01/batch-render-redux.html

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

Tuesday, October 28, 2008

converting 1080p video, part II

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

Sunday, September 28, 2008

H264 encoding for video iPod

The below commands will use FFMPEG to create a video suitable for playback within both iTunes and on a video iPod.

You will need a source file as input and a filename for the resulting output. My source file came from the rendered output of a Cinelerra project that I had just completed. The output was a DVD resolution MPEG program stream, created from directions in my Beginner's Guide to Exporting Video from Cinelerra.

A Two-Step Process
Below are two sets of FFMPEG commands. These two commands encapsulate a "two pass" encoding method. On the first pass, FFMPEG examines the file to be encoded and creates an optimization index. On the second pass, FFMPEG renders the output file based on the optimizations present in the index file.

In the below example, I am encoding a typical DVD resolution (720x480, 1.5 aspect ratio) to the following container format, using the following codecs:
- MPEG4 container
- H264 video codec
- AAC audio codec

For HDV fans, if you wish to reduce your videos to an iPod compatible size, you may use a resolution of 720x400 in order to keep the aspect ratio similar to that of 720P content (1.78 aspect ratio). Though the 720x400 resolution exceeds Apples' recommendations, I've found that iTunes and the iPod will still accept videos encoded to this size.

1) First pass (create index of optimizations)
ffmpeg -y -i sourceFileName.ext -an -v 1 -threads 8 -vcodec h264 -b 500k -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 768k -bufsize 2M -cmp 1 -s 720x480 -f mp4 -pass 1 /dev/null

This first pass will create a file called x264_2pass.log that will be used as an implicit input to the second pass.

2) Second pass (render the output file)
ffmpeg -y -i sourceFileName.ext -v 1 -threads 8 -vcodec h264 -b 500k -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 768k -bufsize 2M -cmp 1 -s 720x480 -acodec aac -ab 160k -ar 48000 -ac 2 -f mp4 -pass 2 -threads 8 outputFileName.ext

I found that the file resulting from the above commands was a bit large, so I lowered the bitrate (-b) from 500 to 250. Also, I lowered the maximum instantaneous bitrate spike (-maxrate) from 768 to 450. As this was a music video and I am a bit of an audiofile, I kept the audio bitrate (-ab) at 160k. Doing this, my file size dropped by 33%, from 450MB to 300MB. This is for a video with a duration of 1hr and 39min. Impressive! Replaying both files in mplayer and xine, I noticed that there was very little appreciable loss in video quality with the lowered bitrates. Go H264!!

Here are the final two commands I used to get that 300MB file:
ffmpeg -y -i sourceFileName.ext -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 sourceFileName.ext -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 outputFileName.ext

Results
As this encoding work was completed on my Fedora editing box, I SCP'd the file over to my MacBook Pro. I dragged the file over onto the Movies section within iTunes and iTunes accepted it without error. In order to verify that the file played correctly, I double-clicked on it and Quicktime played the file back. Hooray!

The moment of truth came when I plugged in my iPod and sync'd it to my iTunes Library. Normally, iTunes will immediately display an error if it doesn't like the new file. Thankfully, iTunes didn't show any errors and uploaded the file to my iTouch. As the file was about 300MB, this took about two minutes. I then started playback and was very happy to see my video on the beautiful, but small iTouch screen.

If you'd like to see the end result, load up one of these videos and don't mind a bit of loud rock musicians doing their thing, you could try loading my band's video podcast:
http://www.stormpigs.com/vodcast.xml

One anomaly I noticed was that when you fast forward to a different section within the movie on the iPod, the video will speed up for a second until the timeline catches up to the requested moment. Not a big deal, just something I didn't expect.

Hope this helps intrepid open source folks looking for a way into the walled garden of Apple's iTunes.

The Mule

Reference
https://help.ubuntu.com/community/iPodVideoEncoding#H.264%20Encoding

Saturday, May 26, 2007

Cinelerra on FC6 working well and more YouTube-ness

I spent all day yesterday editing and rendering video using the Cinelerra install on my Fedora Core 6 box. I am happy to report that after about 10 hours, 15 projects and two or three times as many renders, Cinelerra did not crash once! Now, the types of activities I performed did not vary that much:
- open hour long DVD resolution video
- select five or ten minute long sections of video
- compensate for audio sync problems using nudge
- render out to YouTube compatible format (ala my previous post)

My previous Cinelerra install on Core 4 had crash problems as well as strange audio synchronization problems. One major difference between the systems is that my FC4 Cinelerra system had OpenGL enabled. My new FC6 system does not have OpenGL enabled. On FC4, I noticed that enabling OpenGL seemed to cause the instabilities mentioned above, though I was never able to prove it. Also, the more unstable projects tended to be projects that I had previously created. So as a test, I am recompiling Cinelerra on FC6 using OpenGL and will perform some edits on both old and newly created projects to see if the OpenGL version of Cinelerra is as stable as the non-OpenGL, X11 XV version on FC6. I am hoping that the latest NVidia drivers for my 7600GS 512MB card in combination with various bug fixes in FC6 will allow me to run Cinelerra on FC6 without crashes.

I have uploaded the results of yesterday's rendering session to my new YouTube account here:
http://www.youtube.com/profile?user=snufflerstormpig

I'm learning more about YouTube. It is a really rich environment for social interaction. Everybody has seen a YouTube video and peoples comments beneath it. But depending on how the content producer has configured the video, people can comment upon it by using a video response. Pretty cool. Also, most people know that you can embed a YouTube video into any web page simply by selecting the Embed code that appears on every page that displays a YouTube video and integrate that code into your web site. It looks like this:
<object width="425" height="350"><param name="movie" value="http://www.youtube.com/v/cW8EL2RgAEg"></param><param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/v/cW8EL2RgAEg" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350"></embed></object>

Some of the more interesting stuff is not as evident. For example, if you are a content producer, you can create a "Channel", basically a home page of your profile like in the above link so that people can see your accumulated work. As a member (content producer or regular viewer), you can create playlists of your favorite videos and share them with your friends. When someone gets one of your playlists, they can play all the videos in that playlist simply by clicking once. Here is a playlist I created from the videos I rendered yesterday:
http://www.youtube.com/view_play_list?p=021BB1E61A3BFD19

Also, people can subscribe to your Channel (Subscribers) or you can make Friends who also like your videos. The difference between the two seems to be that Subscribers are more passive viewers of your content and Friends are content producers themselves, or at least have a more well defined profile created on YouTube. YouTube can automatically alert both of these two different types of people when you've uploaded new videos.

Anyway, granted I am a little late to the YouTube game, but I think a lot of other content producers are too. They should take advantage of this great experiment in social networking and get their hard work up on YouTube to show the rest of the world.

Sunday, May 20, 2007

using labels to split rendered video into multiple files

Now that I have my YouTube account, I can go ahead and load it up with a bunch of music videos from the band of miscreants I occasionally play music with. Now, 2006 was a fairly good year for jamming and we had a few stellar sessions at Smash Studios in NYC. The output of these jams usually results in a big video file distributed to my friends. Using Cinelerra, I edit down these three hour sessions into about an hour long video and then distribute that video to my friends via iTunes.

The distributed videos are lower resolution, usually 320x180 MOV files (MPEG4 audio/MPEG4 video) and get pretty big, around 320MB. If you're interested and you have iTunes, you can see some of these monster downloads at itpc://www.stormpigs.com/vodcast.xml.That's really too much to download for any sane person, so my task today was to break up those large videos into small, individual chunks of only the best material from 2006 that I can then upload to YouTube. And hopefully by the end of this post, I'll have some individual songs worth listening to that I can direct you to. With the caveat that the songs were created live, then and there, no rehearsal.

To get back on track, the task is to break up a Cinelerra project into bite size chunks that can then be uploaded to YouTube. This should be fairly simple.

I start with the project that I used to create the one large video. This project has all the audio and video fades and effects that I originally used to create the hour long iTunes video. The good thing about it is that the project has the breaks between video clips delineated clearly. In between the breaks are the actual songs that I'd like to divide up and render out to individual files:


The insertion point will select these breaks very easily, allowing me to set my labels for the render:


This source project is in HDV format. As I've discussed in previous posts, I edit the high resolution source and then output one final as a DVD resolution file, and then convert that DVD to an iTunes-ready format. This does impose some generational loss in quality, but the source material is not that visually stimulating (a bunch of guys in a dark room), so we're not missing much in the two steps down from HDV to iTunes. So now, I have an HDV source project and an output file rendered to DVD. In my previous post (/2007/05/how-to-upload-video-to-youtube.html, I discuss that YouTube allows me to upload up to 100MB or 10 minutes of video. In that post, I also discovered that YouTube recommends this format file:
- MPEG container
- 320x240 resolution
- MP3 audio
- MPEG I/II video

But can also accept files of this format that I can output directly from Cinelerra:
- MOV container (Quicktime for Linux)
- 720x480 resolution
- MPEG4 audio compression (256,000 constant bitrate, stereo)
- MPEG4 video compression (500,000 constant bitrate)

If I break up my project (the recording session) into videos that are less than 100MB each, I will be able to upload the best parts to YouTube. Now, I'm a pretty lazy person in general, so if I don't have to perform an extra step to convert the files from DVD resolution to the preferred 320x240 resolution, I sure as hell won't bother. The test video that I outputted in the last post (specs above) ended up being about a minute and took up about 6.6MB of space at DVD resolution. Theoretically then, I should be OK as long as my songs are less than 10 minutes long (the YouTube limit). Most are, so we should be good to go.

With the constraints understood, I should now have rougly four steps to perform:
1) append my rendered video to a new track in the original source project
2) create labels at the break points between the songs
3) delete the project's original tracks
4) reduce the project size to 720x480
5) render using labels to indicate the start of a new output file

Let's go through these steps.

1) append my rendered video to a new track in the original source project
First, I make sure to move the Insertion Point to the beginning of the timeline. This is where I want my video to be placed. I then select "o" to load my DVD resolution video. This was the original output I rendered from this HDV resolution project. I make sure to select "Append in New Tracks" as my insertion strategy:


2) create labels at the break points between the songs
Now that I have the source video showing the breaks between songs and the outputting video in another track, I can then move the insertion point to each break between songs and set a label by pressing the "l" key:


3) delete the project's original tracks
In order to avoid confusion, I go ahead and delete the original project tracks by scrolling over the tracks in the timeline and pressing the "d" key or right-clicking on a particular track and select "Delete Track." Deleting the older HDV tracks makes sure that I don't accidentally end up re-rendering the HDV video and wasting hours of CPU cycles.

4) reduce the project size to 720x480
To restate, since my original project was in high definition but my newly appended track is at DVD resolution (720x480), I will need to reduce the size of the output video. So I select Shift-F for the formatting menu and change the project format to 720x480:


5) render using labels to indicate the start of a new output file
To render a project into separate files with different names, all I need to do is go into the rendering menu (Shift-R) and check the little box that says "Create new file at each label:"


What this useful little option does is given the output file name that you choose, Cinelerra will create a new file at each label with the format <filename>.<extension>##

where the hash marks indicate a sequence of numbers incremented from 01 to NN, the number of your last label. In other words, if you have 40 labels in your project and the file you're creating is called test.mov, Cinelerra will output the following files:
test.mov01
test.mov02
test.mov03
..
all the way to..
..
test.mov40

Pretty neat, huh?

Of course, you'd probably want to rename those files to something more explanatory. But you get the idea.

To make sure I output a small enough file to upload to YouTube, I augment the video compression bitrate to 500,000 and the audio compression to 256,000 as shown below:




And because I didn't want the first few minutes of introduction to be output, I selected "Selection" for the rendering scope and clicked OK:


The render process is off and running!

To give you an idea how long this particular video took to render, here are some specs:
Video Length: 1hr 4min
Number of Lables: 7
Resolution: DVD (720x480)
Time to Render: 2hr 10min
Computer: Dell 400SC, 3.2Ghz, 800Mhz FSB, 2GB PC3200RAM, Fedora Core 4 SMP kernel

Post Mortem


Here's a link to a few more I've uploaded since my original post yesterday:
http://www.youtube.com/results?search_query=snufflerstormpig

I hope you enjoyed this discussion of multiple file creation using labels. It is one of the many features of Cinelerra and can be very useful in your editing life.

Be good.
The Crazed Video Mule

Sunday, April 29, 2007

Beginner's Guide to Exporting Video from Cinelerra

In past versions of Cinelerra (pre-2.0), the process of creating content readable by media players across all platforms was cumbersome at best and maddeningly frustrating at worst. Cinelerra 2.0 seems to be much better in this regard, and can produce high-quality video in a variety of formats. However, the newcomer to Cinelerra may still find it difficult to output a simple DVD or web-ready video. This guide addresses this audience by explaining how to get usable content out of Cinelerra quickly and easily.

Disclaimer
This guide doesn't intend to support one particular format or compression method over another, but serves to give the reader a methodology to produce video content that displays properly in as many media players for as many viewers as possible.

Assumptions
The steps described below assume a properly installed version of Cinelerra 2.0. Also, the steps below were tested successfully with NTSC formatted video (thanks to Graham Evans for the clarification).

Test System
The procedures below were tested and certified by a non-independent, first party on the following machine:
Dell SC400, 3.2Ghz Pentium IV, 800Mhz FSB,
1GB PC3200 RAM, 80GB (x2) working drives
Fedora Core 4
FreshRPMs Cinelerra build 2.0-0.3.20051210.2.fc4.i386
http://rpmfind.net/linux/RPM/freshrpms/fedora/4/cinelerra/cinelerra-2.0-0.3.20051210.2.fc4.i386.html

Who is your Audience?
So! You've edited your masterpiece in Cinelerra and now it is time to export or "render" it to a final format. Congratulations! However, you first must consider your audience before you decide how you want to distribute the video. Who is going to watch your video and how are they going to watch it? Are you going to give them a DVD, submit a video feed to iTunes, send them a link to a website or just load the video into your iPod? Given that you have a destination for your video, this document will show you how to produce content ready for all of those options:
* HDV 720P
* a DVD
* a vodcast
* a webpage or web download
* Video iPod

Here is a chart comparing the different distribution methods and file formats:

Distribution File Format         Video Compression Audio Format
HDV720P      MPEG2               YUV4MPEG          MPEG, Layer II (384Kbps)
DVD          MPEG2               YUV4MPEG          Twos Comp'mnt
Vodcast      Quicktime for Linux H.264             MPEG-4 Audio
Web Download Quicktime for Linux MPEG-4 Video      Twos Comp'mnt
Video iPod   Quicktime for Linux MPEG-4 Video      MPEG-4 Audio

Distribution Test Video          Size   Render Time
HDV720P      no example yet
DVD          test.mpg            11.5MB      15 sec
Vodcast      test.h264.mov        5.5MB      50 sec
Web Download test.mpeg4.mov       7.8MB      30 sec
Video iPod   test.mpeg4.ipod.mov  1.4MB      30 sec
Note: the dimensions of the test videos were reduced from DVD resolution (720x480) to a lower resolution (320x180) in order to make it easier for readers to download. Also, the only way to reduce the resolution of your video is to render it to a different resolution (described in advanced techniques below). You can resize or crop your video, but in doing so, you would lose some part of the viewable picture.

Once you've rendered your video, don't forget to verify that your video is correctly formatted! And there are sections on advanced techniques for those people who would like to learn more and troubleshooting for folks who may be having problems.

What Operating System Does Your Audience Use?
As in all things Linux, there are a hundred different ways of accomplishing a single task. After much trial and error with file format and compression settings in Cinelerra, I've have had some success using the above formats across operating systems and players. Surprisingly, the QuickTime 7 player on XP is the most consistent media player. As well, MPEG2 is the most compatible format across players of different operating systems.

Here is a chart describing the compatibility of the above test files in major Linux and XP players:


Update 2008/12/24
I've put together a new compatibility chart of Cinelerra export container formats and codecs for Fedora 10, x86-64:
http://crazedmuleproductions.blogspot.com/2008/12/fedora-10-x86-64-compability-chart.html

The chart was created using a 720P resolution Cinelerra project. It is not yet complete.

In a perfect world, this chart should represent the compatibility for all distributions. In reality, your mileage may vary.
end update



Now that we've put some thought into who our audience is and what operating systems and players they use, let's export some video!

Exporting HDV Video
No example yet

For a HDV720P formatted file, we will save the audio and video streams separately. The audio will be saved as MPEG Layer II (384Kbps) and the video will be encoded using mpeg2enc. Once we are done saving the audio and video streams separately, we will then combine (or "mux") the streams together using mplex into a program stream. Finally, we will use VLC to convert the program stream into a MP@HL compliant MPEG transport stream (MPEG-TS).

The general specifications of the combined file are:
File Format: MPEG
Compression Type: MPEG-2
Audio: MPEG Layer II, 384Kbps


Here are the steps. First, render the audio:
* in Cinelerra, press Shift-R for the Render menu.
* under Select a file to render to, choose a destination directory and filename
* under File Format, choose "MPEG Audio"
* under Audio, check the "Render audio tracks" checkbox

* click the wrench icon next to Audio
* select "II" from the Layer dropdown
* select "384" from the Kbits per second dropdown

* accept the changes by clicking the checkbox in the lower left hand corner of the dialog box

* under Video, uncheck the "Render video tracks" checkbox
* accept the changes by clicking the checkbox in the lower left hand corner of the dialog box
* make sure that "Create new file at each label" is not checked
* make sure that "Insertion strategy" is set to "Create new resources only"
* To start rendering, click the checkbox in the lower left hand of the dialog.

Audio does not take very long to render. On my machine, a 3.2Ghz Pentium IV with 1GB of PC3200 memory, a 5 minute stream of MPEG Layer II audio takes about a minute to render.

Secondly, render the video:
* in Cinelerra, press Shift-R for the Render menu.
* under Select a file to render to, choose a destination directory and filename for the video (ending in .m2v). This file should go in the same directory as the audio file. This is not a necessity, but will make it easier when we mux (combine) the audio and video in the next and final step.
* under File Format, select "YUV4MPEG Stream"
* under Audio, uncheck the "Render audio tracks" checkbox
* under Video, check the "Render video tracks" checkbox


* click the wrench icon next to Video. Choose the following options:
* "Output Path" should have the filename and location you selected in the previous steps with a new extension, .m2v
* "Use Pipe" should be selected. If not, select "Use Pipe"
* enter or cut and paste the following render information into the Use Pipe textbox:
mpeg2enc --verbose 0 --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 %
* under "Stream Header, Interlacing" will be left as "Unknown"

* accept the changes by clicking the checkbox in the lower left hand corner of the dialog box

* make sure that "Create new file at each label" is not checked
* make sure that the "Insertion strategy" is set to "Create new resources only"
* To start rendering, click the checkbox in the lower left hand of the dialog. MPEG2 video at HDV resolution takes a long time to render. If you have a dual, dual core machine, HDV video at 720P resolution takes about two minutes to render per minute of video.

After rendering the audio and video streams, mux (combine) them together into an MPEG program stream (PS) file using mplex. This step should not take that long, perhaps one minute for every 10 minutes of HDV video:
* Go to a terminal/shell prompt
* Navigate to the directory where you put both the separate audio and video files
Use this command:
mplex -f 3 -b 2000 video.m2v audio.m2a -o output.ps
The final step in creating an HDV 720P file is to convert it to a transport stream. Do this using VLC.
(screen shots to come)

Once the MPEG-TS file is output, you should have a proper HDV 720P that matches the MP@HL spec. This file can then be copied to a media player that accepts HDV content or output to an HDV camera that accepts 720P (MP@HL) formatted video.


Exporting Video for a DVD
See example: test.mpg (11.5MB)
For a DVD formatted file, we will save the audio and video streams separately. The audio will be saved as a Microsoft WAV file and the video will be encoded using YUV4MPEG compression. Luckily, as of Cinelerra version 1.2.2, Heroine Warrior replaced the much slower mpeg2enc encoding with fast YUV4MPEG. Hooray! Once we are done saving the audio and video, we will then combine (or "mux") the streams together for the final product using ffmpeg.

The general specifications of the combined file are:
File Format: MPEG
Compression Type: MPEG-2
Audio: Twos complement


Here are the steps. First, render the audio:
* in Cinelerra, press Shift-R for the Render menu.
* under Select a file to render to, choose a destination directory and filename (ending in .wav)
* under File Format, choose "Microsoft WAV"
* under Audio, check the "Render audio tracks" checkbox

* click the wrench icon next to Audio
* Accept the Compression default of "16 Bit Linear"
* Leave "Dither" unselected
* Accept the changes by clicking the checkbox in the lower left hand corner of the dialog box

* under Video, uncheck the "Render video tracks" checkbox
* accept the changes by clicking the checkbox in the lower left hand corner of the dialog box

* make sure that "Create new file at each label" is not checked
* make sure that "Insertion strategy" is set to "Create new resources only"
* To start rendering, click the checkbox in the lower left hand of the dialog.

Audio does not take very long to render. On my machine, a 3.2Ghz Pentium IV with 1GB of PC3200 memory, a 5 minute stream of audio takes about thirty seconds to render.

Secondly, render the video:
* in Cinelerra, press Shift-R for the Render menu.
* under Select a file to render to, choose a destination directory and filename for the video (ending in .m2v). This file should go in the same directory as the audio file. This is not a necessity, but will make it easier when we mux (combine) the audio and video in the next and final step.
* under File Format, select "YUV4MPEG Stream"
* under Audio, uncheck the "Render audio tracks" checkbox
* under Video, check the "Render video tracks" checkbox

* click the wrench icon next to Video. Choose the following options:
* "Output Path" should have the filename and location you selected in the previous steps
* skip "Use Pipe" for now
* go down to the "Pipe Presets" section and click ffmpeg. There will be two choices here. Select the DVD format. Depending on the version of Cinelerra that you've downloaded or compiled, you may see one of two versions of the ffmpeg DVD pipe:

1) The first should be used for progressive content
ffmpeg -f yuv4mpegpipe -i - -y -target ntsc-dvd %

2) The second should be used for interlaced content:
ffmpeg -f yuv4mpegpipe -i - -y -target ntsc-dvd -ilme -ildct -hq -f mpeg2video %

Note that if you have problems rendering, the -ilme -ildct -hq arguments or just the -hq argument alone should be removed. In addition, some versions of FFMPEG do not support the -hq option and you will get the below error if you try to render video using this pipe:
ffmpeg: unrecognized option '-hq'
Received sigpipe
write_frame() failed: system error (failed read/write)


Unfortunately, FFMPEG is a moving target, as the tool is in a state of continuous development. That is good, as new features and functionality are being implemented, but distressing when the new features or command line switches change and break scripts that previously worked.

* At this point, the "Use Pipe" checkbox above should be checked and the ffmpeg command pipe should populate the text input field. You should not need to edit this command, as the default pipes' output settings yield high quality video.
* under "Stream Header, Interlacing" will be left as "Unknown"
* accept the changes by clicking the checkbox in the lower left hand corner of the dialog box

* You will notice that underneath "Select a file to render to", the ffmpeg command is represented as a pipe command.
* make sure that "Create new file at each label" is not checked
* make sure that the "Insertion strategy" is set to "Create new resources only"
* To start rendering, click the checkbox in the lower left hand of the dialog. Heroine Warrior has done an excellent job of enhancing the performance of the MPEG streamer, but it still takes quite a while if you've got more than 10 minutes of video. Again, on my machine (described above), it should take about 10 minutes to render 10 minutes of video as an MPEG stream.

Finally, we will mux (combine) the audio and video streams together into a DVD-ready product. Here's what you do:
* Go to a terminal/shell prompt
* Navigate to the directory where you put both the separate audio and video files
Use this command:
ffmpeg -i filename.wav -i filename.m2v -target dvd destinationFilename.mpg

Here is a description of what the switches I chose for ffmpeg mean:
-i = input (either sound or video file)
-target dvd = specifies standard DVD dimensions for the video (720x480) and default bitrate quality levels of ~7Mbps (other targets: "vcd", "svcd", "dvd", "dv", "pal-vcd", "ntsc-svcd" (see -formats switch below))


When not using -target switch, other useful arguments apply:
-aspect = aspect ratio: choose 4:3, 16:9, 1.3333, 1.7777
-b = bitrate in kbps (default = 200 kbps)
-r = frame rate (default = 25)
-s = size (default 160x128)
-ab = audio bitrate (default = 64 kbps)
-ac = audio channels (default = 1)
-formats = file formats, codecs and protocols that ffmpeg supports


Of course, running "man ffmpeg" in a terminal will tell you more than you ever wanted to know about ffmpeg, but here's a nice tutorial on getting started with ffmpeg:
http://howto-pages.org/ffmpeg/

References:
FFMPEG documentation: http://ffmpeg.org/documentation.html
FFMPEG command line options: http://ffmpeg.mplayerhq.hu/ffmpeg-doc.html

In general, using ffmpeg may take quite a while based upon the resolution and length of your video. And if you haven't guessed it already, we are rendering the file for a second time. Video purists would frown upon such a transgression, but for the sake of simplicity, please excuse. By the way, ffmpeg is a very powerful program and there are many more switches you can use to slice and dice your video in any way possible before or after you get it into Cinelerra. Let it be known that the procedure just described will give you a file that will work well with any DVD authoring software.

Don't forget to verify that your video is correctly formatted!

Exporting Video for a Vodcast
See example: test.h264.mov (5.5MB)
To put your video up as a video podcast or vodcast, we will format the video using H.264 compression, as Heroine Warrior terms "one of the highest quality video codecs around, making HDTV distribution over the Internet almost practical." That may be, but users of lowered powered PCs may have difficulty viewing files of this format. Stuttered playback may occur on Intel P4 systems less than 1.8Ghz. I have not yet tested on Apples.

The general specifications of the file are:
File Format: Quicktime for Linux
Compression Type: H.264
Audio: MPEG-4 Audio


Once you've prepared your video in Cinelerra, follow these instructions to prepare it as a podcast:
* in Cinelerra, press Shift-R for the Render menu.
* under Select a file to render to, choose a destination directory and filename (ending in .mov)
* under File Format, select "Quicktime for Linux"
* under Audio, check the "Render audio tracks" checkbox
* click the wrench icon next to Audio

* change the default Compression default from "Twos complement" to MPEG-4 Audio.
* If you want your video to have very high quality sound, accept the default Bitrate of 256000. Otherwise, change this value to something lower to save space. 128000 is sufficient for stereo music. 64000 or lower for voice.

* leave the Quantization Quality at 100%.
* accept the changes by clicking the checkbox in the lower left hand corner of the dialog box.

* under Video, check the "Render video tracks" checkbox
* click the wrench icon next to Video. Choose the following options:
* use H.264 compression. This is Apple's preferred format for iTunes, so let's all bow down to Mr.Jobs. Kidding aside, this format does do an excellent job of saving space with limited reduction in quality.
* keep the default bitrate of 1000000. I've noticed that changing the default bitrate does not change the file size or quality of the output file.
* change the quantization from 5 to 20. This level of quantization will reduce the size of the file by a factor of 66%!
* leave "Fix quantization" checked
* accept the changes by clicking the checkbox in the lower left hand corner of the dialog box

* make sure that Create new file at each label is not checked
* make sure that the Insertion strategy is set to "Create new resources only"
* To start rendering, click the checkbox in the lower left hand of the dialog. If you're video is less than 15 minutes long, read your mail or do some research on that new iPod you're lusting after. If your video is longer than a half hour, go out and paint the town red, because it's gonna take a long time.

Don't forget to verify that your video is correctly formatted!

Exporting Video for a Web Page or a Web Download
See example: test.mpeg4.mov (7.8MB)
Lastly, to prep your video for a web audience, we will format the video using MPEG-4 compression. Using this format results in the smallest file of the three options chosen.

The general specifications of this file are:
File Format: Quicktime for Linux
Compression Type: MPEG-4 Video
Audio: Twos complement


Once your video is set to be put on a webpage, follow these instructions:
* in Cinelerra, press Shift-R for the Render menu.
* under Select a file to render to, choose a destination directory and filename (ending in .mov)
* under File Format, select "Quicktime for Linux"
* under Audio, check the "Render audio tracks" checkbox
* click the wrench icon next to Audio

* accept the Compression default of "Twos complement" and Bits per channel of "16 Bit Linear".
* leave "Dither" unselected
* accept the changes by clicking the checkbox in the lower left hand corner of the dialog box

* under Video, check the "Render video tracks" checkbox
* click the wrench icon next to Video. Choose the following options:
* use MPEG-4 Video compression. This saves quite a bit of space, with limited reduction in quality
* keep the default bitrate of 1000000, bitrate tolerance of 500000, quantization of 10 and interlaced keyframe interval of 45.
* leave "Fix bitrate" checked
* accept the changes by clicking the checkbox in the lower left hand corner of the dialog box

* make sure that "Create new file at each label" is not checked
* make sure that the "Insertion strategy" is set to "Create new resources only"
* To start rendering, click the checkbox in the lower left hand of the dialog. Go get a cup of coffee if you're video is less than 15 minutes long or take a nice long nap if the video is longer than 30 minutes.

Rendering takes mucho processing power, but Cinelerra can handle it! Now if I only had that Dual Opteron box..
:)
Don't forget to verify that your video is correctly formatted!

Exporting Video for a Video iPod
See example: test.mpeg4.ipod.mov (1.4MB)

Update 09/29/2008
Due to updates in FFMPEG and iTunes, the directions herein will only allow you to encode a video that can be replayed in iTunes. However, the file will NOT play in your iPod. I have found a workaround:
http://crazedmuleproductions.blogspot.com/2008/09/h264-encoding-for-video-ipod.html
end update

Update 10/16/2008
Making a Podcast, by Apple

The test file from the above Web Download portion of this document (test.mpeg4.mov) loads and plays in iTunes. However, when I went to upload it, iTunes gave me the message:

"Some of the songs in the iTunes music library, including the song "(Video name)", were not copied to your iPod because they cannot be played on this iPod."

Luckily, Apple provides a feature called "Convert Selection for iPod" when you right-click on the file. But geez! I already rendered this thing. I've have to re-render it? Ugh. OK then. But, oh no, the conversion utility takes too much time! Even on a very fast machine like mine, a 3.2Ghz P4 with 1GB of PC3200 memory, the conversion speed is roughly 1.5 minutes per minute of video. That is way TOO slow. But I went ahead and did the conversion with my short test video. On the bright side, once the video was converted, I could then update my iPod and the video was on my iPod. Yes!

I continued playing around and loading many different videos into iTunes. In my travels, I stumbled upon one that did not require a conversion. I was shocked! I then reasoned that I'd save much time if I just produced the videos in the format that iTunes expects in the first place. But how to do that? So, my next course of action was to research why that one file worked in iTunes without a conversion and why mine needed the conversion.

To do this, I analyzed the output of MPlayer to determine the differences between files. I learned quite a bit about audio and video formats by reviewing the output of MPlayer. It helps to have the text of both files displayed in two windows next to each other in order to more easily compare the files line by line. I've done this for you in the image below. On the left appears the file that is in the correct format; on the right, my file not in the correct iTunes format:

Reviewing the diffences, I noticed the following:
* iTunes compatible file had the audio track as the first track in the MOV container; my file had the video as the first track
* iTunes compatible file was 44.1Khz audio; my file was 48000Khz
* iTunes compatible file included an extra audio header; my file did not have the extra header
* iTunes compatible file audio compression method was MPEG-4; my file was twos complement
* iTunes compatible file FPS rate was 15; my file was 59.97

After way too many hours of trial and error, I found that it was the audio sampling rate and compression type that broke my file in iTunes. Here are the settings in Cinelerra that will make an MPEG-4 video totally compatible with iTunes so that iTunes does not need to re-render (the "Convert Selection for iPod" feature) the video! These settings are a slight variation on the Web Download procedures (MPEG-4 format).

Here are the specs I used:



For the project:
Set Format
Sample Rate to 44100khz
Number of Channels to two
FPS can be the FPS of your source video
Width 320
Height 240My video happened to be 320x180 because my source video was 16x9 hidef, which worked fine as well.

For the render:
Audio
MPEG-4 Audio
Bitrate 128000
Quantization of 100
Video
MPEG-4 Video
The rest of the parameters are Cinelerra's defaults, but I will reiterate here:
Bitrate 7000000
Tolerance 500000
Fixed Quantization selected
Quantization 10
Keyframe Interval 45
You need to abide by this format because iTunes is VERY STRICT when it comes to these settings! Also, the value for bitrate should be calculated based on the height, width, frames per second and quality requirements of your video product. More on this later. Here are Apple's specifications for iPod compliant videos (from http://www.apple.com/ipod/specs.html):
H.264 video:
* up to 768 Kbps, 320 x 240, 30 frames per sec., Baseline Profile up to Level 1.3 with AAC-LC up to 160 Kbps, 48 Khz, stereo audio in .m4v, .mp4 and .mov file formats

MPEG-4 video:
* up to 2.5 mbps, 480 x 480, 30 frames per sec., Simple Profile with AAC-LC up to 160 Kbps, 48 Khz, stereo audio in .m4v, .mp4 and .mov file formats


If you expect to upload into iTunes without needing a re-render, DO NOT deviate from ANY of these settings.

iTunes Specific Information
When you drag and drop a video into the iTunes Library, the software will first evaluate the video to see if it can read the video file. If you drag and drop your newly created video onto iTunes, right-click and select "Convert Selection for iPod". If you have followed my directions, you should receive the following message:

"One or more videos were not converted because they are already in the correct format."

Once you see this message, you know you've been successful in creating a video file in compliance with the iTunes format specifications. Wonderful!!

Don't forget to verify that your video is correctly formatted!

References:
http://www.apple.com/ipod/specs.html
http://www.ipodwizard.net/showthread.php?t=4413
http://members.shaw.ca/Kyle-Rogers/


Verifying Your Settings Are Correct
Once your render is complete for any of the formats above, use your favorite media player to view your masterpiece. After doing this though, you probably want to double-check that the bitrates and compression settings you've chosen for your rendered file are indeed correct. Below, I've listed the following switches of popular players that will display the audio and video settings of your video:
mplayer -identify
ffplay -stats
xine: ALT-i for detailed info, CTRL-i for a brief summary of video stats
qtinfo: displays the settings of any QuickTime video


Advanced Techniques
Reducing the resolution of your source video
I own a high definition video cam, the JVC HD10U. This camera outputs some beautiful HDV footage in MPEG2-TS (transport stream) format; however, the native 720P format is overkill for most applications, especially the three listed at the top of this document. Often then, I will need to decrease the resolution of my videos from 720P to a more manageable dimension. Normally, you'd need to reduce your videos' resolution outside of Cinelerra. This advanced technique will show you that you can save time by doing the resize within Cinelerra!

For example, I will reduce my source video to 480P in order to produce a good looking DVD. Therefore, this advanced technique begins from where we left off earlier in the document, Exporting Video for a DVD, so please refresh your memory before we start.

To reduce the resolution of your source video, you can remove the "-target dvd" switch from the YUV4MPEG Stream settings and replace it with the following switches to FFMPEG:
-aspect = aspect ratio: choose 4:3, 16:9, 1.3333, 1.7777
-b = bitrate in kbps (default = 200 kbps)
-r = frame rate (default = 25)
-s = size (default 160x128)


For example, when I reduced the resolution of the original video used earlier in this tutorial from 720x480 to 320x180, I used these FFMPEG switches when exporting the YUV4MPEG Stream:
-aspect 16:9 -b 7000 -r 29.97 -s 320x180

Here's what the YUV4MPEG Stream dialog looked like while I made these changes:

Here's what the Render dialog looked like after I made my changes:

Notice the absence of the "-target dvd" switch after the "-y". Now you've resized your video all within Cinelerra. Awesome!

Combining a pre-existing audio file with a new video stream
In the previous example, I wanted to reduce the resolution of my video. In like fashion, I want to reduce the resolution, but I also want to keep the same audio stream. To do this, you'd normally have to combine the audio and video streams outside of Cinelerra. But again, we can save time by doing the mux within Cinelerra using this advanced technique!

In my case, I have a pre-existing audio file that I will combine with a newly rendered video stream. Because the duration of the audio matched the larger resolution version, the audio file will be the same length as my video track. In practice, this does not necessarily have to be so, but if your goal is to reduce the resolution of a specific video, most likely you will have an audio file that is the same length as the video. So, just like the previous advanced technique, I edited the commands after the pipe symbol to include the full path of the audio file. I added the following directly before the last character, a "%", in the FFMPEG pipe command:
-ab 320 -ac 2 -i "audio file path/audio file name"

Here's what the YUV4MPEG Stream dialog looked like while I made these changes:

It bears repeating that the full path MUST be specified in the -i switch. If you see errors such as these:
test2.wav: I/O error occured
Usually that means that input file is truncated and/or corrupted.

Received sigpipe
write_frame() failed: system error (failed read/write)

This usually means that your path to the file is incorrect and you'll need to fix it.

Finally, you'll notice two other switches in the pipe command I gave you. Recall these switches to FFMPEG:
-aspect = aspect ratio: choose 4:3, 16:9, 1.3333, 1.7777
-b = bitrate in kbps (default = 200 kbps)
-r = frame rate (default = 25)
-s = size (default 160x128)
-ab = audio bitrate (default = 64 kbps)
-ac = audio channels (default = 1)


As the audio was a high quality stereo mix, I opted for an audio bitrate of 320kbps and a two channel mix. The very nice thing about this advanced technique is that you don't have to mux the video outside of Cinelerra. You can do it within the program itself!

A word about bitrates
A detailed discussion on selecting an appropriate bitrate for your video is out of the scope of this article. So, in the spirit of my guide, I just let Cinelerra's bitrate defaults stand for the beginner who would rather not worry about the details just yet and render something that works the first time out of the box. That being said, I do use a quick-and-dirty method of determining bitrates for my videos.

To determine the bitrate for a video with high quality output, I use the following calculation:
bitrate in kbps = FPS * WIDTH * HEIGHT * QUALITY FACTOR
So, if I have a 320x240 video at 30FPS ready for iTunes, I would substitute in the following values:
= 30 * 320 * 240 * .255
= 587kbps

The final "Quality Factor" varies, but a value of .255 would yield good quality output. The higher the factor, the higher the bitrate and thus, better quality. Experiment with this quality factor to see if it works for you.

Here are some reference links to help you get an idea of what is involved in order to calculate the right bitrate for your video:
Understanding Bit Rates
DVD bitrate calculator
http://www.videohelp.com/calc
http://www.signvideo.com/bt-rts.htm
http://dvd-hq.info/Calculator.html
http://neuron2.net/LVG/ratesandsizes.html
http://www.cs.unc.edu/~hensley/zaurus/encode.html


Troubleshooting
Improper Audio Synchronization
I've had trouble with audio synchronization in a case where I rendered a file from a video track that did not start at zero on the timeline, but started a couple hundred frames after the audio. When I combined the rendered video and audio outside of Cinelerra in FFMPEG, the audio synchronization was off. To make your life easier, keep the start and end of your video and audio tracks perfectly aligned. Make sure to zoom in to less than five frames to verify this.

Types of Rendering Problems
First, confirm if the crash is a result of a problem in the timeline or your rendering parameters.

Crashes Due to Timeline Problems
I've had crashes due to problems in the timeline when rendering hour plus video out of Cinelerra for the following reasons:
-a bug while stacking video effects (specifically, when the Sharpen effect was at the bottom of a stack of six other effects on a video track)
-there were frames of no video between clips on a video track that was being rendered out (if you zoom in all the way on a track, make sure the clips are aligned next to each other)
- I've gotten crashes if I have a transition that overlaps a very short bit of empty space between two adjacent segments of audio or video. To stop this, I will go to the end of a segment, zoom in all the way, and make sure that the video and audio tracks end at the exact same time. If they don't end at the exact same time, I clip off a bit of whatever track is dangling by using the mark in/mark out indicators and doing a "cut". I can then be assured that when I paste a new segment to the end of this recently snipped one that the segments will align perfectly. Once the segments are aligned, I then apply the transition.

Crashes Due to Bad Rendering Parameters
As well, renders sometime bomb out due to parameters I've selected for the render.  For instance, when I added the -ilme -ildct -hq arguments to the DVD render in the above example.

Troubleshooting Render Problems
Try to find the exact moment in the timeline where the render breaks.  I found the Sharpen effect problem by rendering the first half of the video in the timeline and then successively rendering smaller sections of the timeline until I found the exact place in the timeline where the render is breaking.  At which point, it is a matter of either finding a hole in the video or turning off effects/transitions until your render tests work without crashing.

This time consuming; however, if you've spend a lot of time editing, it is the only way to salvage all your hard editing work.

Truncated Video Track
Also, another difficulty I've had is when I open a just-rendered YUV4MPEG stream (.M2V video file) back into a project, the video is truncated and is shorter than the companion audio track. You can read about my troubles here: https://init.linpro.no/pipermail/skolelinux.no/cinelerra/2006-March/005760.html.

I resolved this using two methods:
Don't re-import a YUV4MPEG video after rendering it. In other words, do all of your editing within Cinelerra and then render ONE TIME ONLY when you are done with all of your edits. This may not be feasible on large projects, though.
Use QuickTime for Linux container format to render to and re-import back into Cinelerra. This container does not have the same strange behavior as YUV4MPEG. In other words, when bringing a recently rendered video back into Cinelerra, the audio and video tracks are of the same length and perfectly in sync.
--------------------------------------------------------------------------------
I hope you enjoyed this evolving document. The developers of Cinelerra were kind enough to provide us with a very powerful product that would normally cost thousands of dollars. So I'd like to thank the folks at Heroine Warrior for doing such a fine job programming and all the people at http://cvs.cinelerra.org/ who commit countless hours of their free time and energy on the software. As such, I felt it necessary to give back something to this community who has given us such a gift.

Please let me know of any new topics or improvements you'd like to see in this doc or maybe a new doc! Thanks!

***the mule***
Appendix
Inspecting Your Video File

3/3/2012