two-pass encoding in Cinelerra

So I was creating a video to showcase my cousin's ambient/electroacoustic music and needed the best output possible. I put together the project with scraps of 1080P video from my Canon 5D that I had lying around.

Normally, I would do my edits and then post an MPEG-TS to Vimeo. However, as Florian had called out recently, I found that portions of the final video were slightly underwhelming in quality. Specifically, some timelapses in the video looked grainy. This was because the MPEG2 render parameters I had been using in the above link were giving me less than best quality. So my solution was to use a two pass encode from Cinelerra via the YUV4MPEG stream capability into an MPEG4.

Easier said then done.

There are three steps:
1) export the audio
2) perform the first pass encoding into /dev/null
3) perform the second pass encoding with the audio file into the final file

Export the Audio
As I was having some sync issues, I pushed the audio a little further down the timeline using a negative nudge value.

First Pass Encode
Cinelerra seems to be very sensitive to any garbage in the command line sent to the YUV4MPEG stream. Look at this output:

Render::run 10
trying popen(ffmpeg -threads 8 -y -i - -an -v 1 -vcodec libx264 -aspect 1.7777 -b 9000k -bt 7775k -refs 1 -deblockalpha 0 -deblockbeta 0 -subq 1 -me_range 21 -bf 0 -level 30 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -maxrate 10000k -bufsize 2M -cmp 1 -f mp4 -pass 1 /dev/null� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ���)
FFmpeg version 0.6-rpmfusion, Copyright (c) 2000-2010 the FFmpeg developers
  built on Sep 23 2010 18:55:52 with gcc 4.4.4 20100630 (Red Hat 4.4.4-10)
  configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --extra-cflags='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --extra-version=rpmfusion --enable-bzlib --enable-libdc1394 --enable-libdirac --enable-libfaac --enable-nonfree --enable-libfaad --enable-libgsm --enable-libmp3lame --enable-libopenjpeg --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --enable-x11grab --enable-avfilter --enable-avfilter-lavf --enable-postproc --enable-pthreads --disable-static --enable-shared --enable-gpl --disable-debug --disable-stripping --shlibdir=/usr/lib64 --enable-runtime-cpudetect
  libavutil     50.15. 1 / 50.15. 1
  libavcodec    52.72. 2 / 52.72. 2
  libavformat   52.64. 2 / 52.64. 2
  libavdevice   52. 2. 0 / 52. 2. 0
  libavfilter    1.19. 0 /  1.19. 0
  libswscale     0.11. 0 /  0.11. 0
  libpostproc   51. 2. 0 / 51. 2. 0
[yuv4mpegpipe @ 0xf0a5f0]Estimating duration from bitrate, this may be inaccurate
Input #0, yuv4mpegpipe, from 'pipe:':
  Duration: N/A, bitrate: N/A
    Stream #0.0: Video: rawvideo, yuv420p, 1920x1088, PAR 1:1 DAR 30:17, 30 tbr, 30 tbn, 30 tbc
/dev/null� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ���: File name too long
Received sigpipe
Received sigpipe
Render::run: Session finished.

That is just damn ugly. It looks like some crap got pasted into the command string. Even though I couldn't see anything at the end of the line in the YUV4MPEG stream, I hit the delete key a few times. The method cleaned out whatever invisible control characters got into the command.

My first pass encoding string was this:

ffmpeg -threads 8 -y -i - -an -v 1 -vcodec libx264 -aspect 1.7777 -b 9000k -bt 7775k -refs 1 -deblockalpha 0 -deblockbeta 0 -subq 1 -me_range 21 -bf 0 -level 30 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -maxrate 10000k -bufsize 2M -cmp 1 -f mp4 -pass 1 /dev/null

Note that
1) the audio file is not merged at this first pass step.
2) there is no output file in the first pass encode, the output goes directly to /dev/null

Second Pass Encode
The second pass encode string is where I add my audio file and my output. In the second pass encode string below, note the appearance of the audio file path and the % at the end of the YUV4MPEG stream indicating the output file:

ffmpeg -threads 8 -y -i - -i /mnt/videos/projects/rickr/final.mp3 -v 1 -vcodec libx264 -aspect 1.7777 -b 9000k -bt 7775k -refs 1 -deblockalpha 0 -deblockbeta 0 -subq 1 -me_range 21 -bf 0 -level 30 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -maxrate 10000k -bufsize 2M -acodec libfaac -ab 256k -ar 44000 -ac 2 -cmp 1 -f mp4 -pass 2 %

Note that I could have done these commands outside of Cinelerra if I had output the video to some intermediate file format, usually Quicktime for Linux with JPEG or MJPEG compression for best results.

Every project I do leads me to find some bit of minutiae that sticks in my brain. This time, the minutiae is an FFMPEG bug wherein the parameter to make adjustments to the audio sync does not work for MPEG4 files:
https://roundup.ffmpeg.org/issue359

Final Result
All-in-all, I think this pain gave some very nice results. Let me know what you think:

A Little Time Away from crazed mule on Vimeo.

Music By Rick Rascati from his album Cinemusica
http://myspace.com/​rickrmusic
Shot with a Canon 5D (90%), other JVC HD10U

Another one bites the dust. Have a good one, folks.
the mule

Reference
http://howto-pages.org/ffmpeg/

MPEG4 - H264 comparison

Background
I've been wanting to produce some high quality, H.264 content for my bands' music for some time, but x264 had been broken on my Fedora system. Since I've finally fixed the problem, I can now render a proper H.264 file. Without H.264, I would choose MPEG4 video compression and an AAC audio codec.

MPEG4 file
I use ffmpeg to reduce a DVD sized mpeg down to a file that I could upload to iTunes, like so:
ffmpeg -i ${NAME}.m2t -f mov -vcodec mpeg4 -qscale 7 -s 320x180 -r 29.97 -aspect 16:9 -acodec aac -ac 2 -ab 128 ${NAME}.mov

The variable in this render string is "qscale" (good explanation of which at the bottom of this post) which varies quite a bit depending on the content of your video. The final resolution of the MPEG4 video was 320x180.

H.264 file
I used AVIdemux2 to output the H.264 video. I selected the defaults with a Single Pass - Quality Quantizer (Average) encoding and a similar AAC audio encoding of the MPEG4 of 128K.

The final resolution of the H.264 video was 720x400.

I'll translate the following output into a command line x264 statement at some point, but right now, here were the detailed options to avidemux2:
vui.i_sar_width = 1, vui.i_sar_height = 1, rc.f_qcompress = 0.60, analyse.i_direct_mv_pred = 1, rc.i_qp_min = 10, rc.i_qp_max = 51, rc.i_qp_step = 4, i_frame_reference = 1, i_scenecut_threshold = 40, i_keyint_min = 25, i_keyint_max = 250, i_bframe = 2, i_bframe_bias = 0, b_bframe_pyramid = 0, analyse. b_bidir_me = 0, b_bframe_adaptive = 1, analyse.b_weighted_bipred = 1, b_cabac = 1, analyse.i_trellis = 1, analyse.i_subpel_refine = 5, analyse.b_chroma_me = 1, b_deblocking_filter = 1, i_deblocking_filter_alphac0 = 0, i_deblocking_filter_beta = 0, analyse.i_me_method = 1, analyse.i_me_range = 16, analyse.b_transform_8x8 = 1, analyse.b_mixed_references = 0, analyse.i_noise_reduction = 0, _8x8P is on, _8x8B is on, _8x8I is on, _4x4I is on

Comparing the Output
The MPEG4 file from FFMPEG was 312MB.
The H264 file from AVIdemux2 was 438MB.

Here is how a couple of snips from each file look side by side:







Conclusions
I probably haven't experimented enough with FFMPEG to get the most out of the MPEG4 compression. But the quality and compression rate of H.264 is most impressive. Even though the resolution of the H.264 encoding video was twice that of than the MPEG4, the file size was only 33% greater. That speaks to the efficiency of the H.264 encoding scheme.

I'd say that the H264 output was well worth the extra 120MB, eh?

In case you wish to see the whole hour long shebang in either format, here are the two feeds:
The StormPigs 1/11/2007 jam in MPEG4 format, courtesy of FFMPEG (312MB)
The StormPigs 1/11/2007 jam in H264 format, courtesy of AVIdemux2 (438MB)

And if you are truly insane and wish to subscribe to the StormPigs iTunes feed, here it is:
http://www.stormpigs.com/vodcast.xml

:)
The Mule

title sequence for birthday video complete..

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

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

Exporting Video from Cinelerra for a Video iPod

So. I really, REALLY wanted MPEG-4 output from Cinelerra to go directly into iTunes and my brother's iPod. I had output a test file:
http://content.serveftp.net/video/renderTest/test.mpeg4.mov (7.8MB)
that loaded and played 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.
But GEEZ! I already rendered this thing. I've got to do it again? Ugh. OK. And OH NO! The conversion utility takes a RIDICULOUS amount of 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. Argh!! 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. Hooray!!

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 a helluva lot of 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 over the past couple of days 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 (click this link with SHIFT-click to open a second browser window):
http://content.serveftp.net/video/renderTest/cinItunesConversion.jpg

Reviewing the diffences, I noticed the following:
1) iTunes compatible file had the audio track as the first track in the MOV container, my file had the video as the first track
2) iTunes compatible file was 44.1Khz audio, my file was 48000Khz
3) iTunes compatible file included an extra audio header, my file didn't have the extra header
4) iTunes compatible file audio compression method was MPEG-4, my file was twos complement
5) iTunes compatible file FPS rate was 15, my file was 59.97

After way too many hours of trial and error (and scowls from my girlfriend and dog), I am proud to say that I have found 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!

Here are the specs:

    For the project:
             Set Format
                         Sample Rate to 44100khz
                         Number of Channels to two
                         FPS can be the FPS of your source video
                         (try lower to 25 or less if problems)
  Width 320
  Height 240 (320x180 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

I don't care how you do it, but you have to get your videos in that format
because iTunes is COMPLETELY STRICT when it comes to these settings! If you expect your video to upload into iTunes without needing a re-render, you
CANNOT deviate from ANY of these settings!!

Caveat: with the possible exception of the MPEG-4 Video defaults. But I
would only deviate from the settings after you've got the file uploaded into
iTunes without any issues first.

Please let me know how this works for everybody,
scott

References:
http://www.apple.com/ipod/specs.html
http://www.ipodwizard.net/showthread.php?t=4413
http://members.shaw.ca/Kyle-Rogers/
Beginner's Guide to Exporting Video from Cinelerra

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