What SoC should i use for this project?

I have considerable experience with video processing up to around 1080p60 (not 4k). I can suggest you two ways to do this if 1080p60 is enough for you:

1. You can use a HDMI-to-USB3 frame grabber (~10-15$ supporting ~1080p60), connected to something like a RPi or any other SBC which supports USB3. Then you can write the image processing code inside the RPi. I would say this would be the easier approach.

2. You can use Zybo Z7-20 board, which has a HDMI input (as well as an output), and you can build your system inside the Zybo's Zynq FPGA to extract the info you need from each frame. You can also drive the LEDs by building some logic inside the FPGA fabric. 

In both cases you will need a HDMI splitter on your original source so that one output goes to the TV and the other comes to your system of choice (above). The first way will be easier but the performance might be limited (but probably still acceptable for what you need for). The second system will be blazing fast but I wouldn't recommend it if you you haven't worked with FPGAs before (or not willing to put in quite a bit of effort )

Hope that helps!

p.s When you do complete it, please do share your project here on element14! ;)

I have considerable experience with video processing up to around 1080p60 (not 4k). I can suggest you two ways to do this if 1080p60 is enough for you:

1. You can use a HDMI-to-USB3 frame grabber (~10-15$ supporting ~1080p60), connected to something like a RPi or any other SBC which supports USB3. Then you can write the image processing code inside the RPi. I would say this would be the easier approach.

2. You can use Zybo Z7-20 board, which has a HDMI input (as well as an output), and you can build your system inside the Zybo's Zynq FPGA to extract the info you need from each frame. You can also drive the LEDs by building some logic inside the FPGA fabric. 

In both cases you will need a HDMI splitter on your original source so that one output goes to the TV and the other comes to your system of choice (above). The first way will be easier but the performance might be limited (but probably still acceptable for what you need for). The second system will be blazing fast but I wouldn't recommend it if you you haven't worked with FPGAs before (or not willing to put in quite a bit of effort )

Hope that helps!

p.s When you do complete it, please do share your project here on element14! ;)

Thanks everyone for the responses i have learned so much more. I have a qeustion, is there a real difference between a frame grabber and a capture card? Or is it just the name? And i will defenitly share my project one's its done!

Historically a frame grabber used to be a large external standalone box that could capture one or more frames into its own memory. It also often had various electronics such as GPIO for triggering options. A computer connected to it could then be used to access any part of the stored data.

Over time, the technology started to become smaller and available as plug-in cards for computers, often requiring the host to support its operation.

Some manufactures tend to use the names interchangeably when referring to the same device.

I recall Adam Taylor doing some Zybo Z7 projects in that area

https://www.hackster.io/adam-taylor/creating-a-zynq-or-fpga-based-image-processing-platform-e79394

https://www.hackster.io/adam-taylor/using-hls-on-an-fpga-based-image-processing-platform-8f029f

Doesn't it struggle with handling 1080p video though ?

I'd not heard of the Zybo board but just saw the price.. one may as well buy the cheaper Philips Hue box (which supports multiple 4K HDMI inputs). 

Looks like the Philips Hue Sync box it is limited to 10 lamps though ?

https://www.philips-hue.com/en-hk/p/hue-play-hdmi-sync-box-/8718699707248

You can get a lot more than 10x WS2812B pixel LEDs around a typical large screen display. 

Do you think it would be feasible trying to do it 'old school' by building a custom frame grabber ?

Decode the TMDS data channels, write the video frame data into RAM, then then just access the actual pixel data needed to drive the pixel LEDs rather than trying to chew on all the data ?

'Old old school' and you would probably just pick the required data out of the video signal and skip the rest.

I'm guessing there will already be some video-centric ICs available off-the-shelf to do some of the heavy lifting.

You raise a very good point. So if it's 1080p30 then it's very well within the "supported" fabric frequencies. However, if you move to 1080p60  (60fps) then it moves into the gray area where the frequencies encountered are not supported but actually they do work. I did try receiving 1080p60 video on a zybo z7-20 board earlier this year and was surprised myself too that it worked. But it seemed solid at least in my testing, granted I didn't test this at different temperatures (timing can change). 

Hi shabaz  you're right about the price comparison. This was not clear (to me at least) from the question, but I assumed that the person wanted to try something himself instead of buying something. 

I too thought he wanted to DIY, but DIY doesn't have to mean to design a capture card from scratch. He does mention cost.

I was merely pointing out that a Hue system is much cheaper (and can still involve DIY, just not on the capture portion).

I'm not recommending it if (say) the person wanting to try something wishes to learn how to use an FPGA of course; in which case a Zynq board would be excellent!

People tend to recommend the tools they are familiar with, and I'm no different. If it were me, (and I'm glad it's not, I don't wish to design the solution) I'd consider a framebuffer approach before considering anything else. Turn it into a Linux task by reading a framebuffer. There is still the issue of 4k and HDCP, I know nothing about how that can be resolved, at least not at a DIY level.

But, beyond that, it would not be longer than a 24-hour task to get the majority of a audio/video pipeline (google Gstreamer) working from any off-the-shelf capture card (e.g. there are HDMI-to-CSI cards for the Pi, that seem pretty low-cost, but not 4k from a brief Google search), with a framebuffer being a sink for it (after say splitting the pipeline). Then, it's a matter of spending the time on the end application, i.e. reading the framebuffer in C (for instance), that's a fun and simple exercise. The OP would get to spend the time on the end algorithm/application, and the LED-interfacing hardware, since the rest is already supported stuff.

The above would then also be adaptable for any streamed video too, i.e. 4k is a possibility as well as other sources of information (like the Microsoft solution you mention). HDMI isn't ideal anyway - HDMI is a compromise (even Philips's Hue advert for their HDMI solution shows that the result doesn't look too attractive always). 

By relying on standard interfaces, upgrading to a different capture card would be a possibility as well, e.g. if the new Pi 5 has decent throughput on USB. And the output could be streamed to a TV (or use the HDMI output from a Pi). Plus, it's easy to add a delay if needed (e.g. if the code controlling the lights takes a bit of time), since these are all features supported on day 1 simply by inserting a buffer. In terms of performance, I believe a Pi could be more than capable of supporting all this, it might actually excel at it (I've not tried this on a Pi).