Transcoding mpeg2 to mp4 with avconv

I'm using mediatomb to share my media files across my home LAN and then I found stream-chan which would stream live TV from my HDHomeRun via DLNA. Way cool! Except that the main endpoints in my network are phones and tablets which are none too happy about trying to play mpeg2 streams, to say nothing of my poor gasping wifi network which ends up crippled due to the 30+ Mbps that a single stream wants to sustain. So clearly some transcoding was called for.  I chose mp4 as most devices have hardware assist when decoding x264+mp3, so even the oldest and slowest would have at least a chance to play it.

The incantations for this were gleaned from all over the net and also avconv manpages.  This being so, and with many non-obvious problems along the way, I figured sharing it here might be helpful to the world at large.

avconv -i - -codec:v libx264 -s vga -preset ultrafast -f mpegts -codec:a libmp3lame -ac 2  -y OUTFILE

So now, an explanation:

-i - means 'input from stdin'
-codec:v libx264 means use the libx264 codec for video output
-s vga means make vga-sized output (in a bid to lower computation cost)
-preset ultrafast is an argument to the libx264 codec to tell it to be fast rather than accurate
-f mpegts means output format of mpegts
-codec:a libmp3lame means transcode to mp3 output
-ac 2 means use the first two channels and drop the rest because x264 doesn't handle >2 audio channels
-y means overwrite

After all that, it seems my ancient little NAS is too slow a machine to do realtime A/V transcoding. Ah well, at least I know *how* now - new hardware is a different issue. And maybe this will help someone!

Migrating MoinMoin 1.5.3 -> 1.9.3

How to migrate from moinmoin 1.5.3 (ie. old debian) to 1.9.3 (ie. new debian).

1) If you're using a farmconfig, in your wikis section if you have

"wikiname", "^wikiname.example.com/.*"

change it to

"wikiname", "^(http://)?wikiname.example.com/.*"

This makes the upgrade code match correctly (it incorrectly adds an http prefix to the url, despite saying it's not going to do so).

2) Update your underlay by going to your wiki's dir and doing:

rm -rf underlay
(cd /usr/share/moin ; tar cf - underlay | (cd /your/wiki/dir ; tar xf - ))

3) Provide metadata so the migration system can work. Go into your wiki's data/ dir and do

echo "data_format_revision: 1050300" >meta

4) Finally, run the migration by doing:

python2.5 /var/lib/python-support/python2.5/MoinMoin/script/moin.py --config-dir=/etc/moin --wiki-url=http://wikiname.example.com/ migration data

and then follow the directions it gives you. Note that after you rename rename1.txt to rename2.txt, the next step can take several minutes.

Worked for me, but YMMV.

How to explain Git's Index to a Subversion/CVS/Mercurial/etc user

One thing about git that consistently seems to puzzle or scare off new users is the index. I, in turn, am puzzled at this puzzlement, because every version control system I've ever heard of has something similar... it's just implicit and therefore not as easy to deal with. In CVS or Subversion, when you do an 'add'... what are you adding that new file to? It's not checked in yet (you haven't done a commit). The answer is the implicit index I was talking about. Take that minor little feature and expand it. Note the minor inconsistency that if you were to add a file and then change or delete it, the state gets.. inconsistent. To solve this, and add more functionality in the bargain, what if when you do an add, the system were to store the file _at the time you did the add_ and be ready to commit *that* version when you did the commit? That way it's always exactly clear what is going to happen when you do a commit, and also since all modifications have to be re-added, you've got a nice way to separate out changes in the working copy you want committed from those you don't.

Python debugging trick

A personal project of mine is in python and littered with some heavy debugging statements. 'Heavy' as in there are many of them, and even more so in that they're costly to execute. My debugging method was:

def noop(*args):
pass

def debug(string):
print("##DEBUG >>> {0}".format(string))

debug=noop

def foo(...):
...
debug("blah blah " + repr(baz))
...

Debugging is then enabled by commenting out the debug=noop line, or disabled by uncommenting it.
The downside is that the repr() is executed whether or not debugging is enabled; so if they turn out to be large or expensive to calculate, they hurt performance in all cases.

In the car on the way to lunch today with a colleague, I was bemoaning this state of affairs and wishing python had some kind of macros. His suggested solution was to eval a string; my mildly better counterproposal was to use python's excuse for a closure:

def noop(*args):
pass

def debug(stringfunc):
for line in stringfunc():
print("##DEBUG >>> {0}".format(line))

debug=noop

def foo(...):
...
debug(lambda : "blah blah " + repr(baz))
...

This saves the evaluation of the repr() until the lambda is eval'd... which may be never. The more conventional way of doing this is:

DEBUG=false

def debug(string):
print("##DEBUG >>> {0}".format(string))

def foo(...):
...
if DEBUG: debug("blah blah" + repr(baz))
...

which always seemed much more... redundant, I guess... to me. Either one is a solution to the problem of extra debug overhead, however.

Must-have Thunderbird Addons

Since I've got a G1 that syncs between it and Google Contacts, I figured I should have Thunderbird sync too, which apparently means Zindus.

And IWBNI more messaging was in one place, so SamePlace means I don't need to fire up Pidgin as well as Thunderbird.

And finally, most of what I do is file stuff as 'done', so Archive This will save me a bunch of mouse-time.

Dear Lazyweb, here's an idea:

Talking to some friends about wanting safer logins, it seems that a cellphone with a camera could be a good challenge/response device, like so:

1) sit down to log into your desktop as normal
2) enter your username
- the response is a 2D barcode 'challenge' with an entry field for the response
3) use your cellphone to take a picture or 'scan' in the barcode.
- cellphone generates the correct response (presumably your key is in the cellphone software already)
4) type in the code that your cellphone generates as the response

Kind of like OPIE stuff or those RSA keyfobs, but slightly more general since the above is mostly an I/O method and says nothing about the encryption used.

Free of the FreeRunner

I've given up on trying to use the FreeRunner as an "every-day phone". There aren't enough buttons to support Android properly. Suspect/Resume support (vital on a power-limited device like a cellphone!) was always touchy. It was just all a bit too unfriendly.

So I bought a G1 from a friend-of-a-friend for cheap and unlocked it to work on my current provider. It's been fun! ConnectBot gives me an 80x22 ssh session anywhere - that's only 3 lines from the size of the standard PC text console that I spent so many of my teenage years in front of. The dev environment is open enough that I experimented with writing my own game - a falling-blocks game called Polyfallminoes. Contacts sync with google, the browser is fine to read ebooks on (I read html ebooks that I buy from webscriptions.net and host on my own server), and in general it acts like a nice polished platform. Not that things aren't missing, because they are... but I'm going to see what I can do about fixing that :)

Android

I've gotten more and more interested in Android lately. My FreeRunner is running it thanks to a guy named panicking. I've got an app in the App Store... er, pardon me, 'Android Market' for it. And I think in general it's a Good Thing.

Silence...

should not be construed as satisfaction. Okay, well not as Complete satisfaction. My current Qtopia 4.3.2 install has been working fairly well for the past few months (modulo the re-registration bug), but there's still a ways to go before I'm truly ecstatic with the phone. I'm much heartened by Android's release and rapid progress on the GTA02 platform, as well as by Openmoko's new dedication to working on fixing the fundamental functionality first.

But my old 4.3.2 distro is getting a bit long in the tooth, so I'm likely going to try 4.4.1, and maybe FDOM, soon.

Corruption details

fso and qtopia are both showing microSD (ext2) corruption:
fso while running a kernel with build date of 'Thu Aug 7 15:57:11 CST 2008'.
qtopia while running one built 'Sun Aug 3 16:16:27 CDT 2008'
'
Upgraded fso to one with built 'Sat Aug 16 16:34:47 CEST 2008' and I couldn't repro the corruption. Yay! Fixed for now.