I've been playing around with the mythproto code recently, not so much implementing protocol commands, but building applications on top of the basic ones that have already been implemented. Anybody that has taken a look at the source repository has probably seen the frontend.py module. This was not ever meant to be a usable piece of code, but more of a way for me to test new commands without having to constantly rewrite a test method.

However, I found that the frontend module has been extremely useful in playing back HD content that the official MythFrontend has problems with. For instance, when frames are dropped from the MPEG source, MythFrontend tends to lose audio sync. Usually, this isn't very noticable but it can accumulate over the course of a show and become unbearable. The official frontend also, until a recent patch, didn't support digital audio output on OS X, a major annoyance for someone like me with an external DTS decoder connected to my Mac Pro. These problems can be avoided by using VLC as a video player instead of the builtin MythFrontend one. VLC keeps the audio synced surprisingly well and it takes a lot more pushing to make it loose sync than anything else I've seen (I also tested mplayer for this purpose). VLC also supports digital audio output right out of the dmg, no configuration needed.

Over the weekend, I moved my Mac mini and one of the 20" displays into my bedroom to replace ye olde TV with something a bit more... hackable. To my dismay, I found that the PowerPC mac mini just doesn't have the CPU power needed to decode a 18 Mbps MPEG-2 stream in realtime. After a few days of thinking on the problem, I decided that I could transcode the video to a less CPU intensive format and stream it from there. I didn't want to keep two copies of everything on the backend, as that would be a waste of disk space (and causes the CPU on the myth box to spend all of it's time transcoding). Instead, I'm running mythproto's myth.frontend module on the Mac Pro, that feeds the stream into VLC with these obscure options --sout "#transcode{vcodec=mp2v, vb=1500, venc=ffmpeg, scale=0.5, acodec=mp3, ab=192, aenc=ffmpeg, threads=2 }:standard{access=udp, mux=ts, dst=10.1.2.100 }" - 2>&1 >>/tmp/mythproto.log in order to transcode the video to MPEG-2 at half the resolution and stream it to the mini. The key here is that the video is scaled to half resolution, the rest of the options are just tweaks for quality. The end result is that I fire up VLC in UDP listener mode on the mac mini and pop it into fullscreen with fairly impressive results. While I can tell the difference between the transcoded video and full resolution HD up close, it's nearly impossible to tell them apart from across the room. VLC chews up about 120% of the CPU (out of a possible 400% due to four cores) on the Mac Pro to decode and repack the video in realtime, not bad considering that it takes about 110% of the CPU just to decode and view HD locally on the Mac Pro. On the Mac mini side of things, it takes a mere 30% of it's CPU to decode and play the stream in realtime, leaving plenty of room to add more interesting functionality.

In the course of making this hack work, I started to think that it would be a good idea to write a MythTV plugin for VLC. This would offer easy setup and good integration without having to write a new video player. Expect to see more in this direction soon.

Also worth noting... I added auto commercial skip support to the frontend module shortly after I got the mac mini stream going. Without an easy way to skip around the stream, I found this to be a very useful feature. Commercial skip hasn't been tested much yet, so it may not work completely. Worst case: You end up sitting through a few commercials for poorly targeted products (Who puts tampon commercials on Spike's TV for men?).

I was perusing a friend's website to find that he had a page listing all of his computers, their origins, intended purpose, etc and realized that my pages of that nature have long past. Once upon a time I maintained a thorough inventory of all the random boxes in my basement, but my interest in most of them has waned and I found less and less of a need to keep track of them. However, I've made some interesting acquisitions of hardware over the last few years and thought that it might be a good idea to post some info on some of the more obscure ones.

That being said, I'm going to start this series with neko, an SGI O2 with a 200 MHz R5000 processor. A few years ago, I was visiting SUNY Geneseo's Distributed Systems lab with a group of students from one of my classes and noticed that there were quite a few of these odd shaped, strangely sexy looking boxes sitting around the lab. I inquired as to their status and was told that nobody would really mind if one of them went to a good home. We finished the tour and moved on, leaving the small pile of O2s behind.

Some time passed, and I got involved with more of Matt's classes in order to quench my thirst for technical knowledge. At some point, an O2 was handed to me complete with a hard drive. I took it home and attempted to boot the shiny new O2. But, as luck would have it, the O2 lacked any form of RAM and would serve only as a peculiar looking box in the corner of the basement for the time being. To make a long story short, I eventually found another O2 on eBay for $10, complete with RAM. The new O2's casing was nearly destroyed, but the internals still worked.

After a bit of swapping parts around and testing, I determined that the first O2 had a non-functional backplane and only a 180 MHz processor, whereas the new one sports a 200 MHz R5000 processor. I ended up transplanting the casing and hard drive from the original O2 to the new one. Once I had everything together, I booted into the SGI diagnostic console (a very peculiar BIOS, akin to OpenFirmware) and started to figure out what the system had in it with the 'hinv' command. I came to find that it only had 128 MB of RAM, not the 256 the eBay seller had advertised, but it did have a DVD-ROM drive that the seller had let slip by. After a bit of research, I found that DVD-ROM drives that work in an O2 without a BIOS patch were somewhat rare and I felt that this was a reasonable tradeoff for 128 MB less RAM.

I've attempted to install IRIX on the O2 twice now without success. I now know what people mean when they say that IRIX is... different. I did get NetBSD running on it at one point and found that it is extremely slow for most of the types of things I was trying to do with it (namely, compiling stuff out of ports). I eventually got tired of the constant chatter of its hard drive and pulled the plug. It sits in this state now.

At some point, I will attempt another install of IRIX on it, perhaps with the help of someone who has done it before. Eventually, I'd like to play with some of it's graphics capabilities. I think it'll make an excellent platform for playing with OpenGL code and possibly acting as an extremely lightweight MythTV frontend (I'll post more about this later).

This SGI O2, associated with the hostname 'neko' isn't exactly a very useful machine anymore, but it does have an aesthetic appeal that I enjoy, so it will remain in my basement for some time. As far as the spare parts from the other O2, I have this funny idea that it's about the right size to hold a six pack of soda cans...

Naturally, the big story today is Apple's unveiling of the much anticipated iPhone. It's a very sexy and functional looking piece of hardware. Sadly, there has been little talk about it's technical specifications and internals. Apple has only said that "It runs OSX" and "It's Intel based." Beyond that, there's just pure speculation. So, I'm going to speculate.

For the processor, I'd imagine it's probably one of Intel's XScale (ARM) chips, now manufactured and supported by Marvell. Depending on Apple's architecture choices, it's probably a PXA270 or PXA900. If they go with a PXA270, then the audio/video decoding will have to come from an external chip, but the PXA900 has multimedia logic in the processor, making it a much better candidate, especially with all of the compositing effects that Apple will be doing.

For WiFi/Bluetooth interfacing, they could go with either Broadcom or Marvell. Apple has used Broadcom chips in all of their desktop/laptop offerings for the last few years, so it would make sense to see them continue that business partnership. On the other hand, Marvell is building all of the XScale hardware now, and would be more likely to work with Apple to come up with a more integrated solution, possibly built-in to the processor.

A GSM/GPRS/EDGE chip is unlikely considering that Broadcom and Marvell both produce complete cellular hardware. Broadcom already has chips that support Cellular/WiFi/Bluetooth all on the same chip and it's not beyond Marvell's abilities to build such a device.

If my many assumptions about the iPhone's design are correct, the block diagram should look something like the image on the right.

We'll know for sure when Apple starts releasing developer documentation for the iPhone... I know that there are plenty of people really excited to start writing apps for it.

I've begun documenting the MythTV protocol in detail in a wiki. It's far from complete, and is probably more incomplete than some of the other protocol references on the internet. However, I do have about 70% of the protocol figured out and documented in comments in the library. If you know a little bit of Python, you can probably figure out everything you need from the code.

Note that this is not the final protocol API, only the initial structure. I am planning to write some object oriented wrappers around the protocol after I've got all of the commands implemented.

Protocol reference - Wiki Protocol implementation - Repository

If you've got questions or comments, send me an email: synack <at> csh.rit.edu.