Extrems wrote:Unseen wrote:That's not a bug, that's a design decision.
Then it should be made very clear the digital isn't lossless.
Fortunately the word "lossless" does not appear in the manual.
This is going off user reports, I'm not sure what the exact mechanism is.
Apparent swap of Cb and Cr channels, usually diagnosed as "red and blue are swapped"? Completely different mechanism. If you feed RGB into something that expects YCbCr you usually get a picture that is mostly green or purple.
Obviously I meant a high-quality solution, although I wonder what the overlap between those and those that support 96kHz+ is.
You appear to be fond of making unstated assumptions and I get the impression that you become condescending when other people do not acknowledge them or argue based on a different set of assumptions that conflict with yours. Your calls for YCbCr 422 output seem to be a case of that, from what I can tell you want the exact pixel values on the HDMI output that are in the Gamecube's frame buffer(*) for some purpose. Most people do not care about that, they just want a better quality picture than the GC's analog output, without spending lots of money for the original component cable. In this case, RGB is the must-have-feature (DVI requires it), "lossless" YCbCr 422 is the "almost nobody really needs it, unclear if it makes any quality difference, but it requires lots of extra resources" feature that just isn't worth the effort.
(and by the way: fixing the Cube's audio by resampling isn't lossless either ;) )
(*) An actual implementation would need to face another complication: The Cube outputs 8 bit YCbCr 422, the pixel format on the wire to the display is wider than that. Filling the additional bits with a constant means that at least one of the extreme levels cannot be reached anymore, filling them with a copy of the top bits of the input value means that the step size from one input value to the next varies over the whole range of values.