MPEG-2 rendering artifacts in Bunnings Warehouse ads

31 January 2010

The past week I’ve been watching the Australian Open. It’s been really awesome to watch, and that’s coming from someone who is normally bored stiff of just about any form of sport.

But one thing struck me over and over again: the Bunnings ads had horrible MPEG rendering artifacts at the end of each one. At first I thought it was due to poor reception, but this weekend we completely re-wired our house’s coax connections with quad-shielded cabling to our TV antenna and bought a new masthead amplifier, which greatly increased our signal quality.

(And no, we didn’t replace it just to watch the Bunnings ads.)

But this remained:

Bunnings ad with rendering artifacts

Yuck. That is definitely not signal loss — that’s crappy encoding. I can give people a (non-reencoded) AVI file of the original if they want proof.

I think it’s mainly a result of the fact that the ad is being rendered at 1080i with the outdated MPEG-2 codec. We desperately need an upgrade to H.264, or even better, Dirac.

Source IP weirdities with irssi and IPv6

28 January 2010

I’m having a weird problem with irssi and IPv6. The long and the short of it is that irssi is trying to connect to an IRC server on the Internet with a source IP address of ::1, which is incorrect, as ::1 is the loopback address.

My server, glenstorm, is the IPv6 router, which contains the ppp0 interface that connects it to the IPv6 Internet. I am also running irssi on the same machine. It’s a router, so /proc/sys/net/ipv6/conf/all/forwarding is 1.

So, basically, when I fire up irssi, and type “/connect irc.ipv6.freenode.net“, it hangs when connecting. And for good reason: here’s the (edited for clarity) tcpdump output:

IP6 ::1.34823 > 2001:19f0:feee::dead:beef:cafe.6667
IP6 ::1.34823 > 2001:19f0:feee::dead:beef:cafe.6667
IP6 ::1.34823 > 2001:19f0:feee::dead:beef:cafe.6667

So obviously that’s wrong. And in violation of RFC 4291, I might add (“The loopback address must not be used as the source address in IPv6 packets that are sent outside of a single node.”).

I can hack around it by typing “/connect -host 2001:44b8:7df3:b970::14 irc.ipv6.freenode.net” into irssi, which forces it to use the source IP that I specified. But that’s just a hack — I’d like to get to the bottom of what actually causes it.

Update: Finally solved this. It’s because in my irssi config, I had the following directive:

core = {
    real_name = "Jeremy Visser";
    user_name = "jeremy";
    nick = "jayvee_zzZZ";
    resolve_prefer_ipv6 = "yes";
    host = "glenstorm";
};

It was being told to use “glenstorm” as the “host”, which translates to “resolve the IP address of glenstorm and use that as the source IP address” (I think I misunderstood the meaning of the directive when I put that configuration flag in).

Of course, in /etc/hosts, I had the following entry:

::1 glenstorm

So, naturally, irssi decided to use ::1 as the source IP address. So removing the “host” line from the irssi config fixed the problem. While I’m sure that because of the aforementioned RFC, that shouldn’t have resulted in the subsequent symptoms, at the end of the day, it was simply Unix allowing me to shoot myself in the foot.

MP4 (for real this time) and Akamai support in Python-iView

17 January 2010

You may have seen the workaround I presented to Python-iView users who wanted MP4 support, and wanted it now.

Also, (this has probably got to be the biggest duh moment for me in a year) I discovered Python-iView actually didn’t support those of you who use Akamai-based servers with iView. This includes all users who don’t have iView unmetered, as well as iiNet users. Sorry about that!

Well, now, if you type bzr pull, both MP4 and Akamai support work beautifully.

One thing to keep in mind is that the iview-cli programme has been changed to print out .flv and .mp4 extensions, which you mustn’t strip off when you paste it on to iview-cli --download. This is so it knows which version to ask for. No, they are not interchangeable — keep it what it prints out. (iview-gtk users don’t have to worry about any of this.)

Now all I need is Save dialog support for iview-gtk, and to package it up in .deb and .rpm formats, and it’ll take over the world! Oh, category support would be nice too.