Briefly, it appears that the Roku improperly parses EDIDs from the downstream HDMI sink device and sends color-difference pixel formats (YCC-444 or YCC-420) despite the HDMI sink not supporting these pixel formats. The result is incorrect color (YCC-444) or incorrect color and quadrupled frames (YCC-420), because the sink is not capable of receiving YCC formats and interprets the pixel data as RGB.
After testing with a series of EDIDs, it appears that the Roku uses the presence of a CTA extension block in the EDID to determine whether or not a device supports YCC pixel formats: a single-block (DVI) EDID with only 1920x1080p60 present in the EDID resulted in 1080p60 without audio (compliant behaviour). However, using both v1.3 and v1.4 EDIDs with only 1080p60 and no support indicated for YCC pixel formats resulted in YCC-444 (non-compliant). EDIDs of both v1.3 and v1.4 for 4k60 and 4k30 with a CTA extension block indicating RGB-only support also showed similar behaviour (YCC-420 video, and in some cases the AVI infoframe indicated RGB while the Roku was sending color difference formats).
Additionally, I cannot find any details regarding RGB support online. While the HDMI 1.4b spec (section 6.2.3) says "All HDMI Sources and Sinks shall be capable of supporting RGB 4:4:4 pixel encoding." it's not clear how this relates to the maximum video format the device is capable of i.e. whether the spec requires the largest/highest frame rate mode to support RGB 4:4:4 or if only some intermediate modes must support RGB 4:4:4.
Regardless, this is causing issues with Roku's in installation environments where the downstream HDMI sink does not support color-difference pixel formats. Ideally, RGB would be supported at 4k60/4k30/1080p60, but at a bare minimum, support for RGB with audio at 1080p60 would be nice. Does anyone know of a way to get the Roku to follow the HDMI specification? Or is there something in the specifications that I'm missing?
Additionally, I tried all the above testing with HDCP disabled, 1.4 enabled, and 2.3 enabled, with no change in results.
I'm experiencing basically the same issue, trying to use a Streaming Stick with a non-commercial-use projector, via an HDMI splitter with audio extraction.
When I start everything up it's a crapshoot whether I get proper color and no audio, or audio and the wrong colorspace (purple tinted everything). Usually it's the latter. One time and one time only I started it up and got both audio and the correct colorspace, but I couldn't replicate that at all. I dumped the EDID from the splitter and confirmed that it is appending an extension block - for some reason the colors are actually *worse* when the Roku is plugged directly into the projector with no interposer, so perhaps something in the appended block is necessary.
One thing you may want to check out is the secret HDMI debug menu. It looks like it's had functionality removed since the linked post was made, but it does allow you to check whether the Roku OS 'thinks' it is outputting YCC or RGB. No guarantee that agrees with what the GPU is actually doing though, it's probably just printing out the parsed EDID values. You can also disable 'auto recovery', which I imagine has to do with the flawed heuristic the device uses to choose video modes.
I have edit access to the projector EDID and have tried flipping YCC color support as well as some other things (polarities, timing, etc), to no avail, but if there's a permanent solution that involves a hacked EDID I'm very interested.