I volunteered to digitize a set of old VHS tapes for ADF. I’d say “recently” but it took much more effort than I expected. Resources I thought I had access to disappeared, and hardware failures and quirks were the order of the day.

In the end I wound up using a DVC-100 I picked up at a garage sale along with mencoder. To save people time in the future, here’s what I had to do to make it work under Ubuntu 12.04.

First off, it turned out I needed to set up a loopback device in a ~/.asoundrc to get good audio capture while doing this.

The loopback device looks like this — this can be placed in your .asoundrc as the whole contents of the file:

1
2
3
4
5
6
7

pcm.copy {
    type plug
        slave {
            pcm hw:2
        }
    route_policy copy
}

Then I had to work out an mencoder commandline. This is what I found to work; some of the encoder parameters can be changed of course, particularly the bitrate. I was surprised that the input audio rate had to be dictated to mencoder — I would have expected autodetection.

1

mencoder tv:// -tv driver=v4l2:device=/dev/video0:input=0:norm=ntsc:alsa:audiorate=48000:adevice=copy:forceaudio:immediatemode=0 -of mpeg -mpegopts format=dvd -ofps 30000/1001 -vf scale=720:480,harddup -ovc lavc -oac lavc -lavcopts acodec=ac3:abitrate=192:keyint=25:vcodec=mpeg2video:vbitrate=4000:aspect=4/3 -o druidismnew.mpg

This can be previewed by using mplayer in lieu of mencoder and removing all of the output aspects.

In the long run I used ffmpeg to trim things down using the -t option after previewing the clips. I did find that using -ss to trim off the front was a problem; apparently dvdauthor expects that the video stream appears first. I was unable to come up with a solution for this, and in the end I re-recorded the one clip where trimmingat the start was required.

1

ffmpeg -i infile.mpg -target ntsc-dvd -t [duration] -acodec copy -vcodec copy

I hope this helps someone else, since it was quite a bit of digging on my part, and that after the failure of several other options to do it on a shoestring.

So, having run Octopress for a few days, I suppose it’s time I comment on it.

My interest was initially piqued by the static site speed and resistance to heavy traffic. The former, in particular, caught my eye after I noticed how long it took me, on a fat pipe, to load any pages. Even with WP-Supercache I found that pages tended to expire before anyone saw them.

My webhost, along with logging for bandwidth or similar restrictions, logged CPU usage. Though they are pro-Wordpress, I noticed a few times a day I’d peg things at 100% CPU. Not for very long, but it would happen. Playing with themes and plugins reduced the frequency but did not eliminate it.

All of this, though, falls aside to something else. I’ve noticed needing to upgrade plugins and Wordpress regularly for a site that I do not do a lot of active blogging on. One day I came upon this, relative to Octopress and its ilk:

It’s as if every developer woke up on the same day and asked “why am I responding to security alerts for a blog I barely ever update”?

I realized that with the occasional disconnect from the net that I like to indulge in, it’s entirely possible that my site could be hacked while I’m having a calm weekend. I do recall a Wordpress update coming in right around the holidays once, as well. Now, I’m more secure since there is no PHP.

Sadly, though, I think I’ll have to poke at the contact form. Using cgiemail seems to mean I’ll get weirdly-formatted spam that is hoping my installation isn’t secure.

Are comments going to appear? I’m not sure. The old Wordpress site, with comments enabled, only got a single real comment on a main page praising the site design (thanks, I downloaded the theme myself). Depending on what I get into, I’ll see…

My work laptop is a Dell D820.  When I got it, I installed x86_64 Gentoo on it. I kept it up to date every week, switched to newer profiles as I came upon them, and was fairly happy.

After some annoying issues with a cross-build system for work, and finding it worked under a Ubuntu VM, I switched to 64-bit Ubuntu 10.10. I prefer to have my builds as fast as possible, and this was grating on me.

I figured any general slowdown was worth it. Not only would the lack of VM delay speed up me, but I wouldn’t be constantly needing to recompile anymore. I get paid to write code, not to administer a system after all.

So I took the plunge and I’m stunned at how fast it is. It boots significantly faster (and I had taken pains to enable only a minimum of boot-time scripts and have parallel startup on), everything moves more quickly, and longstanding mild annoyances are gone.

All this time I figured switching would be slower. Why didn’t I do this sooner?

As has been seen, the LOST numbers came up partially in last night’s Mega Millions drawing. Damon Lindelof says that 9,078 people won.

Someone will point out, I’m sure, that if the $380 million jackpot was divided among that many people — if the LOST numbers had come up — that it wouldn’t even get to a hundred thousand apiece.

However, what if they’d had the first five numbers, and then the mega ball wasn’t 42? The payout for that is a flat $250k.

It would total $2.3B payout. I’d hate to be in charge of Mega Millions when that happened. Powerball would have it easier, at only $1.8B.

Something to think about, public lotteries!

I found myself in need of a cross-compiled Python 2.6 to run some hardware test code on an MPC8315ERDB evaluation board. I found Paul Gibson’s guide and patches for cross-compiling Python useful, but they didn’t support the ctypes module, which was needed for the hardware interface code, based around a C shared library. In fact, further searching turned up that one should not expect ctypes to be available for cross-compilation.

I dug into the code, though, and discovered the issue is that _ctypes has its own configure call in setup.py. Pass in the right parameters, and all is well. In my case, my patch (atop of the pre-existing one) looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

--- Python/setup.py 2010-04-07 15:00:28.183555632 -0400
+++ Python-xcompile/setup.py    2010-04-07 15:33:35.443567686 -0400
@@ -17,7 +17,7 @@
from distutils.command.install_lib import install_lib

# This global variable is used to hold the list of modules to be disabled.
-disabled_module_list = ['_ctypes']
+disabled_module_list = []

def add_dir_to_list(dirlist, dir):
"""Add the directory 'dir' to the list 'dirlist' (at the front) if
@@ -1705,7 +1705,7 @@
ffi_configfile):
from distutils.dir_util import mkpath
mkpath(ffi_builddir)
-                config_args = []
+                config_args =  sysconfig.get_config_var("CONFIG_ARGS").split(" ")

# Pass empty CFLAGS because we'll just append the resulting
# CFLAGS to Python's; -g or -O2 is to be avoided.

For the curious, below are the key steps for cross-compilation of Python outside LTIB (since it was for test, there was no need to incorporate it) for the MPC8315ERDB — it may work for MPC8313-based setups as well. You probably want to look at the original post for slimming the tree down once the build is done, and if you have modules for which support isn’t found, change the add_dir_to_list lines to point at your build system’s library and include directories rather than /usr/local.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

tar xzf Python-2.6.4.tgz
cd Python-2.6.4
./configure
make python Parser/pgen
mv python hostpython
mv Parser/pgen Parser/hostpgen
make distclean
patch -p1 < ~/Python-2.6.4-xcompile.patch
#
# Insert my patch here
vim setup.py
#
# Put LTIB tools in $PATH
PATH=$PATH:/opt/freescale/usr/local/gcc-4.1.78-eglibc-2.5.78-1/powerpc-e300c3-linux-gnu/bin/
CROSS=powerpc-e300c3-linux-gnu- CC=${CROSS}gcc CXX=${CROSS}g++ AR=${CROSS}ar RANLIB=${CROSS}ranlib ./configure --host=powerpc-e300c3-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/python
make HOSTPYTHON=./hostpython HOSTPGEN=./Parser/hostpgen BLDSHARED="powerpc-e300c3-linux-gnu-gcc -shared" CROSS_COMPILE=${CROSS} CROSS_COMPILE_TARGET=yes
make install HOSTPYTHON=./hostpython BLDSHARED="powerpc-e300c3-linux-gnu-gcc -shared" CROSS_COMPILE=${CROSS} CROSS_COMPILE_TARGET=yes prefix=~/Downloads/Python-2.6.4/_install

It often surprises me, the conceptions those outside the embedded software world have of it.

At the one end is the old, hardcoded view; a good example, if a bit old, would be Joel Spolsky’s view of the Embedded Software World.

At the other end, prompted by the increasing presence of Java and other applications for cell phones, there is the idea that it’s all Java and that it’s every bit as easy as desktop development.

Neither of these views is entirely true, but they aren’t entirely false, either.  Joel is correct about limited programming capability in many cases, but as I bet even he is realizing there are flash updates these days even for consumer electronics like Blu-ray players. Others are correct about the increasing availability of tools that make it just like home in some embedded systems.

Where do I find myself in all this? Well, only recently did I find myself working on the first project for my employer where C++ can be used in a fairly embedded environment; previous projects had broken libraries, a lack of space for the generated code, or both. Of course, there’s still bootloader work in C, sometimes with a dab of assembler, too.

The biggest thing I’ve noticed about embedded software is that often it’s solving known-to-be-solved problems without the benefits of a full-up system. Perhaps you don’t have a shell capable of scripting — or the ability to just run Perl or Python, meaning you have to write C code that grovels over I/O that would be trivial in either. Sometimes it’s bringing up a board from scratch, and trying to get a bootloader to work — or writing your own (though, these days, it’s preferable to grab one of the pre-written ones, as you’ll get much more functionality once you get it running).

So what do I think of it? It can be frustrating when you’re writing many lines of code for what you know would be trivial in another language, but it’s also fun to squeeze every last drop out of a hardware solution.

I recently updated my MSI Wind U123’s BIOS for various reasons, and I ran into an problem whose solution I’m offering up in case of issues from out there. Per the instructions from MSI, I flashed the BIOS, powered down, and removed the battery. MSI’s site didn’t specify how long to remove the battery, so I removed it for a 10-count (a slow 10 count).

I put the battery back in, and Windows XP refused to finish booting, instead sitting in the XP startup animation forever. Safe mode booting stopped at Mup.sys. I attempted to boot via CD to use the recovery console, but even that hung up. Frustrated, I made a USB stick with Ubuntu Netbook Remix. That also refused to go far beyond the bootloader.

The solution turned out to be to remove the battery for a good few minutes, then put it back in. Once that was done, all was well again.