1
\$\begingroup\$

I am looking to use an FPGA in line with a non-encrypted HDMI stream in order to inject an overlay to the display. The minimum resolution and frame rate I would like to support is 1080p at 60Hz.

My idea to make this work would be to load a fully encoded 1080p frame of the overlay in memory with everything 0's except for the pixel data that I want. Assuming my overlay only uses solid colors (ie pure R, G, or B) I can have the compressed frame saved with only 1 bit depth (about 2.5Mb in memory per channel). Then as the TMDS data for each channel is clocked into the FPGA, and assuming I can detect the start of a frame and synchronize the incoming data with the overlay being read from RAM, I should be able to just OR the two data streams bit by bit as they are being clocked into the FPGA and output the result the very next clock cycle...

Hopefully I am not being too naive with this plan as I am not too familiar with HDMI. Can anyone tell me if there are flaws with this?

\$\endgroup\$
  • 2
    \$\begingroup\$ Sounds fine to me. Should work with either external HDMI receiver and transmitter chips, or HDMI IP internal to the FPGA itself. You'll just need to have counters to keep track of your X-Y position within the frame. \$\endgroup\$ – Dave Tweed Dec 30 '17 at 2:06
  • 3
    \$\begingroup\$ You may want to take a look at bunnie's NeTV project, which did something very similar -- except without buffering, and it can overlay on HDMI content. \$\endgroup\$ – duskwuff -inactive- Dec 30 '17 at 3:54
  • 1
    \$\begingroup\$ If you do it right way, it's a relatively simple process. Be sure not to introduce very long delays. \$\endgroup\$ – Gregory Kornblum Dec 30 '17 at 7:49
1
\$\begingroup\$

Seems like a reasonable idea. However, the data will not enter the FPGA bit-serial, it will be deserialized and decoded in parallel; the FPGA fabric can't go fast enough to deal with bit-serial 1920x1080 HDMI. You'll need to decode the TMDS encoding in order to mess with the pixel data anyway. And you'll also have to re-encode and re-serialize the signal to send it out the door again. The data path should run on the order of one pixel per clock cycle, so you can trivially swap out colors as necessary. I would recommend using an indexed color configuration - one 2D array of small numbers, perhaps 3 or 4 bits, that indexes into an array of RGB values. One of the values could then correspond to 'passing through' the original color. Or you could combine colors by adding, or even use one bit as a 'mask' bit to select whether or not to consider the original color.

\$\endgroup\$
  • 1
    \$\begingroup\$ By an 'indexed color configuration', you mean what's normally called a Palette RAM or Colour Look-Up Table. \$\endgroup\$ – TonyM Dec 30 '17 at 9:38
  • \$\begingroup\$ Yeah, wasn't sure what the proper technical term was. "indexed color" may be more of an image file format term. \$\endgroup\$ – alex.forencich Dec 31 '17 at 4:28
0
\$\begingroup\$

You should dig into NeTV and NeTV2 https://www.adafruit.com/product/609

Creator: https://kosagi.com/w/index.php?title=NeTV_Main_Page

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.