I sometimes think of a distinction between the engineering way and the hacker way. Both are good, and the two are related, but they aren't the same. If HN has a purpose in the world it surely is to champion the latter, whose mottos are "gratifying curiosity" and "just because". By "the engineering way" I mean creativity operating under economic or organizational constraints that demand justification and exclude the whimsical. You end up with different projects and products that way.

But I don't think matmann2001 was being critical—just eager to share the cool details of their own ambient lighting setup, which is an excellent thing to do and squarely on the hacker side of this distinction.

It's much easier to sidestep HDCP altogether, which can be done with a simple AV converter.

There's a balance that every hacker has to find. Sometimes it's good to just get something out the door, sometimes you've invented an excuse to learn technology X. :)

That's the "analog hole", and it closed January 1, 2014. No Blu-Ray player manufactured after that date offers analog video output.[1]

Of course, if your source is a Blu-Ray player, the HDMI output will have HDCP encryption, so the approach from the article won't work either. There are some "HDMI splitters" which don't encrypt on the output side, but most splitters now do re-encrypt.

[1] http://forum.blu-ray.com/showthread.php?t=230112

You can download the verilog for a HDCP "overlay" (which, for obvious legal reasons only encrypts HDCP so that a video overlay can be put on a digital image) from: http://kosagi.com/netv_hardware/

This has been presented at http://events.ccc.de/congress/2011/Fahrplan/events/4686.en.h... .

From this code you could create your personal HDCP removing HDMI-splitters using the FPGA module used by the original article.

Too many single components for my taste.

Having an all-inclusive solution like this one with a dedicated FPGA makes much more sense to me. Unfortunately it seems that a high res solution is never going to work for all use cases due to HDCP, processort speed etc, and it will probably never launch commercially because of Philips' ambilight patents like EP 1379082.

I've been looking for an in-between all-in-one solution which takes HDMI as an input for the past years, but there's no real reasonable solution which I would take.

The best I saw to this date is this: http://www.keiang.de/Content-pid-32.html, but unfortunately it's not publicly available (he didn't release the circuit diagram and the list of electrical components needed, at least the last time I researched the site).

Also, an HD signal as input to the ambient light setup just isn't necessary. The software (or FPGA) is going to average pixel colors around the border to effectively reduce the resolution to match your LED spacing. With an HD signal, you're just spending more processing power/time to filter out and throw away more information.

It makes color and brightness transitions smoother, which makes the overall effect less distracting, and likely less seizure inducing.

I believe these simple lights add a lot, particularly to the experience if you're watching a movie. Thanks for sharing your solution :)

Cheaper? Definitely not

Lower latency? Likely, but the difference in latency would be undetectable

Way Cooler? Yeah, I'll give him that one.

Taking that into account, the difference in power drain for our respective computing resources would be dwarfed by the power requirements for the LEDs, such that the difference is near negligable.

If you have to write a driver, you might want to reconsider your definition of "overkill."

2) SPI is a ridiculously simple protocol. I have a background in embedded systems, so it's really not a lot of effort. Particularly compared to the OP, who deconstructed and intercepted the entire HDMI protocol on an FPGA. I'd consider the effort required for that task as quite a bit more.

For low performance applications, it works perfectly.