IANARS, but if I had to guess, I would say that when the fueling probe disconnected, the fuel that was in the arm poured out and was ignited by the rocket as it went by. When the arm disconnects, there's a plume of white that spews out and it appears to be that which ignites a second or two later.

All you really need for this is an HDMI receiver with HDCP support but no keys and an HDMI or DVI transmitter. Wire the two chips together, add in a small microcontroller (msp430/cypress psoc class should be sufficient) to manage the link. Keyless receiver/transmitter chips use a simple I2C eeprom to store the keys externally on the assumption that you've paid the HDCP consortium for the keys (chips with built in keys require you to sign a license deal in order to purchase them). Use your pc to generate a valid sink key, program that into the eeprom, write some relatively simple code to manage the receiver/transmitter and your done. Analog Devices used to sell a dev board that would be perfect for this purpose - it contained all the necessary parts, save the microcontroller, so would need to build that part of the system. A bit of overkill for this kind of project, but it would work.

He's got an unused decimal point on each digit. That says he can get to 1,279,999,999 (use the decimal points as a 7 bit binary number). That should be more than enough. I think the writeup even mentioned using them for something.

And the number of embedded Linux systems with ludicrous boot times that could be improved by something like this is quite high. Think of that BluRay player that takes 90 seconds to open the tray from power off, or your new LCD TV that takes 30 seconds to produce a picture, or your Tivo that takes minutes to be ready to do anything. The vast majority of these devices run embedded linux and getting the boot times down to sub 10 seconds would go a long way to making customers much happier. I know I'd be much happier with consumer electronics if I didn't have to wait so much for things to boot (and sadly, since I've been doing embedded Linux for the last 8 years, I'm probably responsible for some of it...) Yeah, this demo is certainly a contrived example - I'd guess that they've stripped the kernel and u-boot to the bare minimum, loading from parallel flash instead of serial, no arbitrary delays anywhere and init is probably the application they're demoing.

Disclaimer: I work for LifeSize Communications, so I might be biased...

Anyway, in the dedicated hardware area, you've got HP and Cisco at the high end (100k++++), Polycom and Tandberg (merging with Cisco) in the middle end (10k++) and LifeSize and a host of other smaller players at the low end (<20k). If you want HD (720p30 minimum), you're not really going to find it on PC based implementations, most are limited to 640x480p15 - 30 due to the compute required to encode the stream efficiently. Polycom and Tandberg offer a mix of SD and HD products with the SD products generally being cheaper than the HD ones. Everyone in the "professional" video conferencing space is moving to HD. LifeSize offers products from 2.5k (passport - 720p30 only, point to point only) to about 17k (room 220, 1080p30/720p60, 8 way multipoint, H.323) with a variety of products in between. We pride ourselves on needing the least bandwidth to achieve certain levels of performance (e.g., we'll do 720p30 in 768kbps, 720p60 in 1mbps and 1080p30 in < 2mbps). Polycom and Tandberg offerings are generally 2x the bandwidth at the same resolution/frame rate. Cisco's telepresence stuff needs (I could be wrong here, but I think I'm in the right ball park) something like 18mbps for the 3 screen solution you've seen on 24 and a couple of other shows (that's 6mbps/screen).

There are plenty of pc clients, but truth be told, they look like a** compared to the (HD) professional ones in my opinion. Of course, I'm starting to realize that HD TV looks like crap too, so it might just be me.

Oddly, while the 8300HD does spin down the drive (though it does not spin down an ESATA connected drive), it doesn't ever turn off the video output - it just changes the video data to black (at least on the HDMI port).

Most of the CEC enabled players allow you to selectively enable or disable CEC support. And if the software is written correctly (and the path to the TV is not too deep), the source can tell if the sink is on or off, regardless of the connection topology. Of course, most of the CEC and HDMI implementations I've come across are half baked at best.

If I remember correctly, my ancient Sun 3/75 diskless workstation used to state: le0: no carrier when the (AUI -> fiber) ethernet dongle fell off the back of the box (the network is the connector was the old slam against Sun's flaky AUI network connectors of that time). Of course that was before 10baseT was popular, so I suppose it's possible that that form doesn't use a carrier.