Sorry if you’ve ever experienced the problem here where the contents of the Home Page would disappear.  It was a weird WordPress thing that I just repaired.  It should be working fine now.

OK, so I love CNN Money’s Prioritizer for prioritizing things (anything really, from decisions on what to save my money for, to helping a client determine what they truly find important with regards to their Website’s purpose, to finding out what makes, for me, a good book cover for a children’s graphic novel).  Now, there’s a Web 2.0 Ajax Social Networky way of doing the same thing: the Idea Sandbox Prioritizer.  It’s a lot quicker to run through than the CNN Money one, too!  Only one downside: no numeric scoring in the Idea Sandbox version, just the straight prioritizing of items, so if you need the numbers for justification, stick with CNN Money’s version (for now).

Not since LGM2 have I put a video up on YouTube — I was just waiting for a good one to post, that’s all, and here it is!

Myself, Rafer Roberts, and Rebecca Simms (and Evan Keeling, but I left before he arrived) were all at Beyond Comics in Frederick for Free Comic Book Day. For the two or so hours I was up there it was pretty sweet. I gave away a lot of minicomics, and I know the other DCC members did well for themselves. I also had the opportunity to talk with the very cool owner of Beyond Comics, Jon Cohen. Watch and enjoy.

Thanks to Alex for running the videocamera, and, of course, the entire movie (except for the music which was from Garageband) was edited using Open Source software.

I’m joining the party…

 I was also going to draw my older self, but then I got lazy.

A faster Paint Bucket in Inkscape means that I make my comics faster, which means I can finish “Candynomics” before I turn 30. The first version of Paint Bucket was pretty much just a proof-of-concept, and was very slow (but faster than the alternative of coloring using the Pen tool, which drove me batty). The second version got a little more clever at analyzing the area to be painted, which brought out a modest speed improvement. For the most recent change, which involved hooking deeper into the potrace bitmap tracing engine, I used Valgrind and KCachegrind to analyze all the steps of a fill operation and to find any potential bottlenecks.

Inkscape uses libgc to handle garbage collection, which is a good thing, except for when you want to profile Inkscape using Valgrind. Valgrind and libgc don’t get along too well, but luckily you can disable the use of libgc in Inkscape with an environment variable.

Additionally, profiling all of Inkscape in Valgrind, and more specifically callgrind, is an excruciating process. Valgrind allows you to disable instrumentation — the gathering of function call statistics, a very slow operation — at the start of the application’s execution, and then turn instrumentation on later in the life of the application, say when you’re about to paint an area of the drawing.

To profile a development build of Inkscape with Valgrind, with instrumentation disabled by default, cd to your build directory and execute the following from a bash shell:

_INKSCAPE_GC=disable valgrind --tool=callgrind --instr-atstart=no src/inkscape

Inkscape will start up…very, very slowly. When you’re ready to profile, run in another shell:

callgrind_control -i on

And callgrind will start recording function calls. Perform the operations you want to profile (the more the better if your machine is fast enough — I performed about 3-4 bucket fills in my testing, which was enough for this purpose), then in your second shell:

callgrind_control -i off

You can kill the valgrind process with [Ctrl]-C once callgrind_control reports that instrumentation is off.

When you’re done profiling, you’ll get a callgrind.out file in the build directory, with a number at the end that is the PID of the valgrind/inkscape process. Move this file somewhere else (I like ~/Desktop) and fire up KCachegrind.

I’ve done a lot of profiling of PHP applications (using Xdebug, a very very useful PHP extension), but essentially nothing of desktop applications. Luckily, the same general process applies to desktop apps:

• Sort functions by number of calls. See if any function is being called more than it should be.
• Sort functions by call time. See if any function is taking a very very long time.
• Check the call graph of the bigger functions. Look for anything suspicious.
• Tackle the biggest offenders first. Don’t waste time squeezing an extra 1% out of the app if it takes you 20 hours to get it (unless you really want to )

In my case, #3 was what tipped me off to what was going on: after calling Inkscape’s potrace engine to trace the fill bitmap, the engine was calling a function called filter() which seemed to be taking a while to execute. I took a look at what was going on, and saw that filter() was generating a grayscale version of the bitmap fill to be traced, and then passing this along to the tracing engine.

The filter that was being applied was geared more toward generic image filtering, where the input could be anything. My input from Paint Bucket is quite specific, so I decided to try an end-run around the filtering system.  After about 20 minutes of refactoring and new coding, I re-ran Inkscape in Valgrind, did some fills, and after comparing the costs of the removed filter function and the new costs of my own filtering, the process was faster!

So in conclusion: if you have spots in your code that are CPU-intensive, or just plain slow, running them through a profiler like Valgrind (or for PHP, Xdebug) can help you determine if it’s a problem in your code and where that problem may be.

(this post is part of the Linux Video Production Experience series, which chronicles my experiences with creating a high-quality home movie almost entirely in open source software.)

For my past movie-making adventures, I used mencoder or ffmpeg to encode my noisy, low-motion, un-color corrected video for DVD, which it happily did. There were never any huge spikes in the data, since all of the scenes were equally poor in quality.

And now that I’ve properly cleaned everything up and made it pretty, mencoder did not work out too well for this project, due to its not-so-good MPEG-2 rate control. ffmpeg apparently has the same problem. The issue came up with rapid scene changes or high motion video areas. Several areas in the video caused a friend’s DVD player to skip horribly, which has never happened with any of my videos before.

I needed one additional feature in my encoder this time, and that’s 2:3 pulldown. 24p footage needs to be yanked back up to 29.97fps footage so that it’s playable on most DVD players. And as far as I can tell, you can’t enable soft pulldown in ffmpeg, so that encoder’s out for this job.

Now, in my research, I’ve come across four possible open source solutions that might work:

• Use mencoder, but specify a very low bit rate tolerance (vratetol in the lavcopts options).
• Use mencoder with experimental Xvid rate control compiled in and enable with with vrc_strategy=1 in the lavcopts options. Xvid rate control seems to be more aggressive against the high bitrate spikes than mencoder’s libavcodec rate control.
• Use AviSynth with QuEnc (both running in Wine), which reportedly has extremely good rate control.
• Use Avidemux, which uses its own flavor of the Xvid rate control mechanism. Avidemux will automatically enable the soft pulldown flag if you’re encoding an MPEG-2 file at ~23.976FPS.

mencoder + a low vratetol (somewhere between 100 and 1000) still produced some very high spikes. mplex reported that the max bitrate of the stream was well over the DVD spec. mencoder also has experimental Xvid rate control, which required compiling a new mencoder. With that enabled, however, the output video stream still spikes too high.

AviSynth + QuEnc would have taken some additional work to get the AVI files I output from Cinelerra (in Motion JPEG format) to load with AviSynth. I couldn’t find a free way to get AviSynth to read MJPEG frames. Maybe I’ll have to dust off my old registered copy of the PICVideo MJPEG codec if I want to go down that road…

Avidemux, however, got the job done. The DVD preset gets you 90% of the settings you need for DVD MPEG-2 files. Be sure to enable Xvid rate control in the DVD (lavc) settings and you should be fine. The only tricky part was joining all of the 21 movie files. If all of your final videos are alphabetically sequential in a directory, let’s say “FinalRender,” you can use this bash one-liner to open all of the files into Avidemux (which is in your path) in the right order:

cmd=”"; for i in FinalRender/*; do if [ “$cmd” == “” ]; then cmd=”–load $i”; else cmd=”${cmd} –append $i”; fi; done; `avidemux ${cmd}`

Avidemux appears to be the best way for me to encode my final, cleaned up, 24p Cinelerra AVI files to MPEG-2 DVD format to avoid skipping during playback on standalone DVD players. As usual, if I missed something in my writeup, please leave a commenton the story!

And that’s it! Please let me know if you have any comments or questions about the series. If you want to see some additional part of the process I went through for this production, let me know and I’ll find the time to post another article.

(this post is part of the Linux Video Production Experience series, which chronicles my experiences with creating a high-quality home movie almost entirely in open source software.)

To be honest, I’ve always had no end of trouble getting my final audio and video to come out of Cinelerra. I’ve tried rendering DV files, MPEG files, and AVI & QuickTime files with various codecs, trying to happen upon the best combination of container & codec that my final encoding tool of choice, Avidemux, can easily handle, and that doesn’t take up 100s of gigabytes of disk space and days of rendering time.

After several Cinelerra projects, I decided to start using the following formats for exporting my final audio/video:

• For video: an AVI container with Motion JPEG A video codec at 100% quality
• For audio: a 16 bit WAV

Now, one thing about exporting AVIs: Cinelerra will fail when trying to write an AVI file that’s greater than 2GB in size (2GB being a magic file size for AVI files). To get around this, I will insert labels at every 2 minute mark along the timeline. I had written a small Ruby script to create the XML to do this before, but I found it’s just as easy to use the Selection Start Time field and the [L] key to enter labels every two minutes:

Be sure that all of your effects that you want enabled are, um, enabled, especially the RGB-601 effect if this render is destined for DVD encoding. Save your project and open the Render window ([Shift]-[R]). Let’s set up the AVI video export first:

(Note: I’m working on creating a Tango theme for Cinelerra 2.1, hence the Tango-y buttons and color scheme in some of the dialogs. It’s not done yet.)

And now set up the video export settings for AVI files:

When naming the file, be sure to place two 00s (zero zero) toward the end of the filename, maybe right before the extension:

FinalRender/FamilyVideo-00.avi

With the “Create new file at each label” option checked, the 00 will be replaced with the index of the current segment:

FinalRender/FamilyVideo-01.avi
FinalRender/ FamilyVideo-02.avi
…
FinalRender/ FamilyVideo-24.avi
FinalRender/ FamilyVideo-25.avi

Click the Go button and go to work or sleep. When you return to your computer, it might be done, or it might not. Just be patient.

Now do the same for audio. Set up the export settings as such:

And for the codec:

Choose a new filename with the right extension (.wav) and click Go. This one won’t take nearly as long. Once this is done, you have your audio and video ready to be encoded to DVD or whatever format you want. I’ll talk next time about using Avidemux to do this.

Another reason you might want to export video is to preview your video with all of its edits, and not have to worry about Background Render rendering each frame. For this, I’ll use Ogg Vorbis/Theora with a fairly high video bitrate. The resulting file plays fine in VLC or Kaffeine.

OK, here’s a dumb one I just ran across: In Flash 8, If you’re reading the Stage.height property in your ActionScript code, and you’re previewing with Bandwidth Profiling enabled, Stage.height is computed incorrectly.  Sheesh…

Tags: flash, actionscript

I just finished putting the finishing touches on Planet DC Conspiracy, an aggregation of DC Conspiracy member blogs, the artdc.org forum, and the DC Conspiracy home page.  It’s updated once every four hours.  Check it out!

Tags: planet, dc conspiracy, comics

As with the recent Inkscape release, I’m probably the only one on Planet Inkscape that hasn’t posted about the current campaign to raise enough funds to get Libre Graphics Meeting 3 off of the ground. They were kind enough to pay my way to the meeting in Montreal last year, and since I can’t make it out to Poland for this year’s meeting, I pitched in to help make sure this one is successful. If you want to see open source design software get even better than it already is, throw a few bucks their way so all the developers and users of these projects can actually talk face to face for once.

Tags: lgm2008