Monday, October 30, 2006

motion experiment, part III

Update 2009/03/17
I finally put together a motion stabilization tutorial. Hopefully, it helps folks who are as confused as I using the thing.
*** end update ***

The motion stabilizer is one of the most difficult effects to use in Cinelerra, as it has so many knobs and switches to figure out. It is very frustrating.

I had more luck this time with the motion effect, but it was still very hard to get working correctly. I kept playing around with different settings, but ended up using these:
- translation block around 1/6 of entire screen
- translation block more wide than high (400x150)
- track single frame
- stabilize subpixel
- zoom set to auto in compositor

Once I did get it working, I thought I did have a better feel for how the different parts interact. But the motion effect seems to be is something you have to spend a LOT of time with to get working correctly. It is still frustrating, though.

Here is the fruit of my labor:
Here was the original:
both about 3MB

I definetly think the motion is better stabilized.

I will try to post a more detailed description of the steps I went through. Perhaps even a video, as motion stabilization is a real art. I wish it could be simplified in the software.

the mule

Sunday, October 29, 2006

rendering cam-compatible HDV MPEGTS files

I have been successful in exporting HDV back out to my cam. I haven't posted detailed output from the individual steps before, so here it is:

General Steps
1) export video from Cinelerra as mpeg2 using mpeg2enc
2) export audio from Cinelerra as mp3
3) mux in mplex
4) open MPEGPS in VLC and convert to TS.

1) export video from Cinelerra as mpeg2 using mpeg2enc:
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 /mnt/videos/20050721/20050721.m2v

2) export audio from Cinelerra as mp3:
Input File : 'stdin' 48.0 kHz
Output File: '/mnt/videos/20050721/test.mp3'
384 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 = 1152.000; b/smp = 8.00; bitrate = 384.000 kbps

3) mux in mplex
[root@computer 20050721]# mplex -f 3 -b 2000 -o test.mp3 20050721.m2v
INFO: [mplex] mplex version 1.8.0 (2.2.4 $Date: 2005/08/28 17:50:54 $)
INFO: [mplex] File test.mp3 looks like an MPEG Audio stream.
INFO: [mplex] File 20050721.m2v looks like an MPEG Video stream.
INFO: [mplex] Found 1 audio streams and 1 video streams
INFO: [mplex] Selecting generic MPEG2 output profile
INFO: [mplex] Multiplexing video program stream!
INFO: [mplex] Scanning for header info: Audio stream c0 (test.mp3)
INFO: [mplex] Audio version : 1.0
INFO: [mplex] Layer : 2
INFO: [mplex] CRC checksums : no
INFO: [mplex] Bit rate : 49152 bytes/sec (384 kbit/sec)
INFO: [mplex] Frequency : 48000 Hz
INFO: [mplex] Mode : 0 stereo
INFO: [mplex] Mode extension : 0
INFO: [mplex] Copyright bit : 0 no copyright
INFO: [mplex] Original/Copy : 0 copy
INFO: [mplex] Emphasis : 0 none
INFO: [mplex] Scanning for header info: Video stream e0 (20050721.m2v)
INFO: [mplex] VIDEO STREAM: e0
INFO: [mplex] Frame width : 1280
INFO: [mplex] Frame height : 720
INFO: [mplex] Aspect ratio : 16:9 display
INFO: [mplex] Picture rate : 29.970 frames/sec
INFO: [mplex] Bit rate : 18300000 bits/sec
INFO: [mplex] Vbv buffer size : 229376 bytes
INFO: [mplex] CSPF : 0
INFO: [mplex] SYSTEMS/PROGRAM stream:
INFO: [mplex] rough-guess multiplexed stream data rate : 19077648
INFO: [mplex] Setting best-guess data rate.
INFO: [mplex] Run-in Sectors = 752 Video delay = 58123 Audio delay = 61126
INFO: [mplex] New sequence commences...
INFO: [mplex] Audio c0: buf= 0 frame=000000 sector=00000000
INFO: [mplex] Video e0: buf= 0 frame=000000 sector=00000000
INFO: [mplex] Scanned to end AU 39469
INFO: [mplex] STREAM e0 completed @ frame 39469.
INFO: [mplex] STREAM c0 completed @ frame 54874.
INFO: [mplex] Multiplex completion at SCR=118584775.
INFO: [mplex] Audio c0: buf= 2304 frame=054874 sector=00031342
INFO: [mplex] Video e0: buf= 0 frame=054843 sector=00509538
INFO: [mplex] Audio stream length 63216000 bytes.
INFO: [mplex] Syncwords : 54875
INFO: [mplex] Frames : 54875 padded
INFO: [mplex] Frames : 0 unpadded
INFO: [mplex] BUFFERING min 18 Buf max 1169
INFO: [mplex] Video Stream length: 1031417371 bytes
INFO: [mplex] Sequence headers: 6579
INFO: [mplex] Sequence ends : 1
INFO: [mplex] No. Pictures : 39470
INFO: [mplex] No. Groups : 6579
INFO: [mplex] No. I Frames : 6579 avg. size 58215 bytes
INFO: [mplex] No. P Frames : 32891 avg. size 19714 bytes
INFO: [mplex] No. B Frames : 0 avg. size 0 bytes
INFO: [mplex] Average bit-rate : 6264800 bits/sec
INFO: [mplex] Peak bit-rate : 9203600 bits/sec
INFO: [mplex] BUFFERING min 943996 Buf max 1944874
INFO: [mplex] MUX STATUS: no under-runs detected.
[root@computer 20050721]#

4) open MPEGPS in VLC and convert to MPEGTS.

Update 3/14/2008
Once the video is converted, you may then output to the camera using test-mpeg2 from libiec61883:


Also, take note of a possible 2GB limit in libiec61883 uploading your content to the cam:

Saturday, October 28, 2006

libiec61883 now exports files greater than 2GB to cam!

As you may know, I've been successful in rendering HDV MPEGTS that works being output back to my cam. However, I stumbled upon the fact that libiec61883 cannot output files greater than 2GB. Well, I rolled back my operating system to an earlier image, rebuild libiec61883 with the -D_FILE_OFFSET_BITS=64 DEPS param in examples/Makefile and now I can send data greater than 2GB using the command
[scf@localhost ~]# test-mpeg2 -t 0 file.m2t
where 0 is the physical id of the cam as specified by gscanbus

I have found that using the incorrect physical id will result in the following error message:
[scf@localhost ~]# test-mpeg2 -t 1 file.m2t libiec61883 warning: No plugs exist on either node; using default broadcast channel 63.

However, the camera will still display the incoming video. If the physical id is correctly specified, you should see no errors and the "Starting to transmit.." message only:
[scf@localhost ~]# test-mpeg2 -t 0 file.m2t
Starting to transmit

I have no idea why this fixed the problem, because I used the same steps as before. Just glad it works.

Saturday, October 21, 2006

basic OpenGL vs XV performance stats

Thought I'd share some Cinelerra performance stats using OpenGL versus non-OpenGL (XV) display drivers. I used two tracks of identical length (32s), but different content.

one 32s 720P track: 20fps
two 32s 720P tracks, both play enabled, no fade on top track: 2.97fps
two 32s 720P tracks, both play enabled, 50% fade on top track: 3.04fps

Stopped then restarted Cinelerra and performed next test.

one 32s 720P track: 10.6fps
two 32s 720P tracks, both play enabled, no fade on top track: 2.2fps
two 32s 720P tracks, both play enabled, 50% fade on top track: 2.18fps

Not fabulous performance for using > 1 track, but still slight improvement over XV.

Thursday, October 19, 2006

motion experiment, part II

Update 2009/03/17
I finally put together a motion stabilization tutorial. Hopefully, it helps folks who are as confused as I using the thing.
*** end update ***

I was able to get a better result from the video I made a while back. I realized I did not use the "Previous Frame Same Block" option originally. This made a huge difference. As I didn't have much time to fuss with it, I lowered the translation search steps to 128 as you suggest.

Here are my results with comparison of before, after and zoom. The video is very compressed, but you can see that the zoom doesn't degrade too badly, as my source is HDV, which is something you'd be interested in seeing:

Here's the next in the series:

HDV MPEG2 transport stream file sizes/render rates

The data rate of the 720P MPEG2-TS files output from my cam is about 108.95MB/min or 1.82MB/s. Here is a table of video length-to-size conversions.

duration size

12m 1.32GB
15m 1.65GB
18m35s 2.07GB
19m12s 2.12GB
20m01s 2.18GB
34m 3.70GB
Exporting 720P HDV from Cinelerra takes two processes:
1) render the video
2) render the audio

Here are some rendering times using mpeg2enc and mpeg layer 2 audio compression:

duration mpeg2enc render rate
63m 310m 4.92min per min of video

duration mp2 render rate
63m 6m 0.09min per min of audio

Mplex takes about 7 minutes to mux about an hour of audio and video.

Monday, October 16, 2006

hard work is paying off / HDV workflow

OK! I've got the latest video up on iTunes and now I just need to edit the XML for it. Editing the damn XML always takes too long. And of course, I want to get the track list right with the correct track times and witty comments. Ufff. OK! So the track list is done and now to send the boys the email for the latest video! Hurrah!

More for my benefit than anyone elses, here is my HDV workflow using Cinelerra:
1) import video
2) edit video
3) for multiple segments, make sure you set "align to frames" and audio and video segments end at the exact same time.
4) for HD output, render using mpeg2enc settings
5) for DVD output, render using ffmpeg -target DVD from Cinelerra, something like this:
ffmpeg -f yuv4mpegpipe -i - -y -i /mnt/videos/20050721/20050721.wav -target dvd %
6) for iPod output, render using ffmpeg -target DVD, then output to mpeg4 video/aac audio mov container:
ffmpeg -i inputdvd.mpg -f mov -vcodec mpeg4 -qscale 7 -s 320x180 -r 29.97 -aspect 16:9 -acodec aac -ac 2 -ab 128
7) import .mov to XP iTunes
8) upload .mov to website
9) edit RSS XML
10) final test in iTunes

trials of Cinelerra rendering, deja vu all over again

Well, four hours of overnight rendering yields a video I can't playback. I get this error:
int YUVStream::read_header(): y4m_read_stream_header() failed: bad header magic
int YUVStream::open_read(char*): Bad YUV4MPEG2 header: parameter out of range

Now what the F is wrong? Is it a problem with:
- my rendering options I chose?
- this version of ffmpeg in general?
- my project?

I wasted a number of hours on the first two possibilities. I finally saw two issues in my project:
1) for some reason, probably my big fat fingers, an audio transition was placed right at the beginning of the project (Timecode 00:00:00). I deleted this.
2) I noticed that for joins between separate videos on the same a/v tracks, the joins between the audio and video segments did not end at the exact same place:

To stop this, I went to the end of each segment, zoomed in all the way, and made sure that each video and audio segment ended at the exact same time. If they didn't end at the exact same time, I clipped off a bit of whatever audio or video track is dangling by using the mark in/mark out indicators and doing a "cut". After doing the cut, the segments aligned perfectly.
Even with these changes, however, I still get a similar version of my original error when I load the project:
int YUVStream::read_header(): y4m_read_stream_header() failed: bad stream or frame header
int YUVStream::open_read(char*): Bad YUV4MPEG2 header: parameter out of range
However, I can output it to a usable format, so I don't mind the rather ugly error messages. You'd thought I would have known better by now. ARGH!

Along the way tonight, I've been trying to help the Cinelerra CVS community debug a couple of errors:
1) the intermittent project hangs
2) MS MPEG4 render crashes

I synchronized my hvirtual directory twice and recompiled, once for v932 for the project hang problem and then v940 for the MS MPEG4 render crashes. Both took a couple interations, but it seems like the programmers have the problems licked. That's good. We've been pushing them pretty hard lately.

So, finally around 11pm, I've rendered the video to a usable DVD mpg. Now it's time to render once more; this time to iPod format. It looks like FFMPEG has removed the "-b" bitrate switch in favor of some quality scale switch, "-qscale". The higher the qscale, the lower the quality. To create videos with the same quality as the original, you can use the "-sameq" switch. Otherwise, a qscale of 4 will yield a decent quality video with some significant compression. I'd use h264, but I haven't been able to install it successfully. I may try VLC..

Update 2009/06/09
My understanding of the "-sameq" switch was a little naive. Robert Swain enlightens here:

You'll probably need to read it a couple of times like I did.
*** end update ***

Saturday, October 14, 2006

outstanding bugs/foul ups/frustration

There were a number of outstanding bugs that some of the programmers addressed. One of them was that Cinelerra keeps hanging when I open up projects. It seems to happen on projects I've built before 2.1 that I've saved as 2.1. So I've told the programmers I will test their work once they apply the patches. I drank too much coffee in the afternoon and deleted a number of files that I wish I hadn't off of my FAT partition. Stupid ass. Luckily, I have those on a second drive, so I should be OK. Another thing to do: MAKE DVD BACKUPs OF PARTITION IMAGES, PRONTO!! Ugh. What a hassle. This new rig is NOT making my life any easier!!

Tonight, I finally got to edit some video..the last band video. Amazing! It has been about a month and a half since I started the whole OpenGL/export HDV to tape excursion and while I've learned a lot, it has just been frustrating as hell. The state of HDV on Linux is pretty rough. I'm lucky I've made it this far and I wouldn't have without the help of the community, both and I'd like to finish this edit job so that I can spend some time with my girlfriend before she leaves me. As I'm editing this video, I'm a little upset by the quality: the crappy automatic gain control on the cam makes dark shots look grainy and grey and the focus fades in and out. How good of a video production will I make if the camera work sucks? Yarg. At least I've finished the edits. Off to render!

Friday, October 13, 2006

editing rig is 95% there

My editing rig is 95% there, outside of not having the ability to render using h264. Also, I'm only able to export files greater than 2GB to tape. Apparently, this is a typical problem that should be resolved by using some compiler flags (-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE). However, the compiler flags did not work, so I was just reading up on this thread:

that states that my system needs to support the following calls: mmap64, sendfile64, sendfilev64, mkstemp64. I will also try to pass --enable-lfs to configure.

Thursday, October 12, 2006

VLC install

If cinelerra source dependencies are already installed, VLC requires the following files to be compiled:
- ffmpeg-devel
- fribidi
- libdvbpsi
- libiec61883/libraw1394
- libmad
- libtheora
- mpeg2dec
- twolame
- wxGTK (special build: buildgtk)
- gettext-devel

And then of course, VLC itself (special build: ./bootstrap)

Download the 77MB source files from

Wednesday, October 11, 2006

exporting HD content to the cam: IT IS ALIIIIVE!! ALIVE!!

After a month of testing and experimentation with many inter-OS softwares, exporting HD content to my camera is working! YAHOO!! The greatest part is..I am Microsoft FREE!

Most of my work was based off of this original thread:

But a number of steps (ffmpeg/DVHSCap) did not work for me.

Here are the steps I used to get HD content from Cinelerra back to my cam in full resolution, HD 720P format:

1) install the latest 2.6.18 kernel according to specs on
2) you'll need the latest libiec61883 and libraw1394 libraries from the same place . I needed to manually tweak the ./configure procedure for libiec61883 with the following environment variable:
Another caveat to this step is that I needed to remove libraw1394 first, which was a nightmare because of all its dependencies. I created a yum install script to reinstall everything after this was complete.
3) you'll need to make a change to tsbuffer.c and recompile libiec61883 (don't have it me if you need it).
4) you'll need to recompile mpeg2enc to allow for bitrates larger than 14000. This is referenced in the thread from way back when:
A kludgy hack allowed me to get bit rates higher than 15Mbs in mpeg2enc

I removed the following lines from
if (bit_rate> 1.0e6 * maxval->bit_rate)
mjpeg_error_exit1("Bit rate is greater than permitted in specified Level");
5) here are the mpeg2enc switches that were successful for me:
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 mpeg2.mpv
6) mplex params:
mplex -f 3 -b 2000 -o audio.mp2 mpeg2.mpv
7) Use VLC to convert the file to a transport stream. By the way, the VLC is a hellish snake pit of install dependencies. Go to to download the latest source.

Here are the instructions for VLC from Paul St. Denis' original steps (
Start VLC, from the "file" menu select "open file", click on the "Browse..." button and find "", check on the "advanced output" check box and then click on the "Settings.." button. Make sure the "file" radio button is picked click on the "Browse..." button save the file on your desktop as "transport.ts".

Make sure that the "Encapsulation Method" is MPEG TS, leave everything else blank. Click OK, which brings you back to the other screen click OK again.

Yes, it's a lot of work. But to be Microsoft free is a great feeling.

Update: as of this writing (10/17), I'm only able to upload less than 2GB of video. For my 720P video cam, this is about 19.7 minutes of video. I am working with the linux1394 community to resolve this.

Saturday, October 07, 2006

success and failure exporting/importing video to/from camera

I should say that those notes are for HDV content, but some of them are
applicable for regular DV.

Today I spent some time with folks on the Cinelerra IRC channel trying to hook up my HDV cam for import and export functions. I used a combination of three programs: dvgrab to import/export DV content and test-mpeg2 (from libiec61883 source) or mpg1394grab for HDV export/import.

"mpg1394grab" (sorry for the typo) is used to capture IEC61883 streams to MPEG2TS format. Here is some more detail about it:

The results were as following:

            import tape  import live stream  export file to cam
dvgrab not tested works does not work
test-mpeg2 works works sometimes does not work
mpg1394grab works works n/a

mpg1394grab works better for grabbing HDV.
test-mpeg2 import command is "test-mpeg2 -r [node] [file]"
test-mpeg2 export command is "test-mpeg2 -t [node] [file]"

On my Fedora Core 4 system, I have a /dev/raw/raw1394 instead of a /dev/raw1394. I don't know why.

Make sure there is a symbolic link to /dev/raw1394:
ln -s /dev/raw/raw1394 /dev/raw1394

Make sure the driver is chmod 666:
chmod 666 /dev/raw/raw1394

To compile mpg1394grab, execute this:
gcc -lraw1394 mpg1394grab.c -o mpg1394grab

My camera is the JVCHD10U. In the onboard menu system of the camera, you can change the iLink Out setting to either SW (software) or AUTO (automatic). The JVC must be set to AUTO for Linux to recognize the cam. This is different than XP, which requires the camera setting to be SW.

For dvgrab, the camera must be set to DV/DV
For mpg1394grab and test-mpeg2, the camera must be set to MPEG2/HD

seeing my cam in Linux

The troubleshooting steps here helped me out quite a bit. In short:
1) make sure you have libraw1394
2) make sure there is a link to /dev/raw1394
3) download the latest kernel (
4) make sure to select Code Maturity Options (Prompt for developement drivers) and enable IEEE 1394, OHCI 1394, and Raw 1394 support options
5) make sure new kernel sees firewire interfaces (dmesg grep 1394)
5) load the modules (modprobe ohci1394 (the firewire card)/modprobe raw1394 (interface to it))
6) check that the modoules are there (lsmod)
7) use testlibraw
8) use gscanbus

This should do it!

Wednesday, October 04, 2006

trying to get HDV content back out to my cam..

Lest ye think I have been sitting on my very small, small laurels, I want all the open source, JVC HD10U fans out there know that I am still working the problem. However, I have almost given up as a result of my many trials and tribulations over the past five days with MPEGTS file formats and the JVC cam.

My journey started here:

I replicated all of the steps; however, the last step I cannot reproduce because I don't have an Apple Mac. I've tried exporting the .ts file to the cam using DVHSTool, CapDVHS and the utility that comes with the cam, but all of them give me errors. I've tested against many different versions of outputted files with little success. My last hope is that I can get a virtual Mac going using Xen, download DVHSCap to it and then try DVHSCap on the file.

say a prayer..cross your fingers..

Sunday, October 01, 2006

JVC HD10U specs

Really good doc on the MPEG format utilized by the JVC HD10U: