Overlay support tends to be very limited - it's effectively blitting to the final framebuffer after compositing, which means no transparency and a limited number of surfaces. The desire is for the compositor or any other shaders to be able to read YCbCr surfaces natively, converting to RGB as a part of the sample.
Namely, VK_KHR_sampler_ycbcr_conversion. I'm actually not sure if other APIs provide the equivalent yet, the HW capability is pretty recent...
Android has had ColorMatrixColorFilter[1] since the beginning and YUV -> RGB conversion is actually an example use case they specify. Problem is, however, that many YUV formats do chroma subsampling, and you can't exactly put that into a regular bitmap without shuffling a lot of bytes around, which kinda defeats the purpose.
There’s GL_MESA_ycbcr_texture for vanilla GL and GL_EXT_YUV_target for GLES, but I’ve no idea how well-supported these are. (Notably, the Mesa extension is ancient—the changelog says it’s been published in 2003.)
IIRC GL_MESA_ycbcr_texture is basically GL_APPLE_ycbcr_422, only supports packed 422, and was primarily intended for letting a compositor pass a 2vuy/yuvs surface to the overlay HW without actually converting it in GL.
GL_EXT_YUV_target is close, but it doesn't transparently include the specific step of YUV -> RGB conversion, just the sampling multiple planes + upsampling for chroma (and convenience functions for shader conversion.) (I think? actually not certain, since I can't find definition of how chroma is upsampled)
Well, I guess Vulkan's isn't completely transparent, since the conversion sampler has additional restrictions as to how it can be used. But at least with it shaders can be written to not care whether the source is RGB or not.
Namely, VK_KHR_sampler_ycbcr_conversion. I'm actually not sure if other APIs provide the equivalent yet, the HW capability is pretty recent...