That was it! I would have liked a solution that doesn't involve reconfiguring the source,
If you wanted to attempt to make something to allow it to process HDMI signals.
(this will only work for 24-bpp, 444 RGB, full range modes, which has the same signal timing and channel colour encoding as 24-bpp DVI-D)
1. The 'data islands' are inserted in the SYNC periods. You can see these are coming in the data stream because of a guard band (a special preamble). When in the 'data island' only sixteen different bytes are sent to represent four bits on each channel. One of the three channels carries the HSYNC and VSYNC signals, so you will need to decode this channel to recover the HSYNC and VSYNC. You have to do this (rather than streching the current SYNC values over the data island) because if VSYNC changes state while in a data island it will not be seen, and the monitor will fall out of sync at what looks to be random times.
2. The active video pixels are prefixed with a different guard band to the data islands, and this needs to be stripped and replaced with SYNC periods.
With both of these done the resulting signal / coding will be identical to DVI-D
Have a look for the "HDMI specification filetype:pdj" on Google to find the full documentation you will need (e.g. guard band and TERC4 byte values)
I also wonder if it's better to not use the DDR at first and get to it if/when I have to or just get it working (with an existing library) in the beginning and take advantage of it right away.
Don't - wait until you are a bit more skilled. DDR has latency that you need to solve, complicating the design quite a bit. (you need to read ahead and hold data in a FIFO that can never be allowed to empty out)