My (mis)understanding on first reading the OP was that the needed data transformation was q_m = f(q_m, D), whereas BrowserUk understood it to be q_m = f(D).

Looking at Re^9: encoding hdmi video byte, it is clear that BrowserUk had the right idea, and a quick check of the output of this implementation and BrowserUk's (after the  "@Q" bit is fixed, and ignoring those pesky high bits) shows they are functionally the same.

All the rest is as BrowserUk wrote. Just use the info in  %map to create a  tr/// translator. This you can do by hand or, as I think BrowserUk wrote somewhere, create a translator function on the fly with eval. This will zip through the input data pretty quickly (either in one big Gig or in several smaller chunks). Then, the only problem remaining is the pesky high-order constant bit(s?), bit-8 (and -9?), which, again as BrowserUk wrote, it would be simplest and quickest just to spit out alternately with the transformed input bytes. Happy hdmi-ing!