GNOME Bugzilla – Bug 752842
gloverlaycompositor: Wrong color format
Last modified: 2015-08-16 13:39:00 UTC
When rendering overlay compotion in glimagesink the color are wrong. I supposed we have picked the wrong color format. It needs to be checked and fixed. This is probably trivial (but I don't want to forget). Here's a pipeline with blue text, that show as red. gst-launch-1.0 videotestsrc ! textoverlay text="COLOR or COLOUR, is that a question ?" color=0xFF0000FF ! glimagesink
I've given a quick look, it's in fact a bit of work. The compositor assumes the colors are RGBA, but they are BGRA. The R and G need to be swapped. Not sure how expensive that would be with the uploader/convert stuff, may just adding this to the compsitor shader is whiser. Note that on big endian the compsition buffer will be in ARGB.
Ping ?
Created attachment 308961 [details] [review] gloverlaycompositor: Add shader to convert BGRA/ARGB -> RGBA Depending on the bytes order we will get BGRA (little) and ARGB (big) from the composition overlay buffer while our GL code expects RGBA. Add a fragment shader that do this conversion.
Attachment 308961 [details] pushed as d6baf8d - gloverlaycompositor: Add shader to convert BGRA/ARGB -> RGBA
So the problem with this is that GL transfers are in host endianness already for GL_UNSIGNED_BYTE conversion which is currently used everywhere so the endianness is not an issue for the texture transfers.
(In reply to Matthew Waters from comment #5) > So the problem with this is that GL transfers are in host endianness already > for GL_UNSIGNED_BYTE conversion which is currently used everywhere so the > endianness is not an issue for the texture transfers. I'm still in doubt, but if you could provide more detail of your thinking I could confirm. Unlike all the other case, the reason we have this byte order check is not because of GL, as you just confirmed, we read per byte which will indeed not affect the shader for the same format. Though, gst_video_overlay_rectangle_get_pixels_unscaled_argb() will return GST_VIDEO_FORMAT_BGRA when the host is little endian, and GST_VIDEO_FORMAT_ARGB when it's big endian. These are two different formats that requires two different shaders. Are you still completely sure that I made a mistake ? And if so, can you provide technical details ?
Gahh, gst_video_overlay_rectangle_get_pixels_unscaled_argb does not return data with native endianness. Confusing.
(In reply to Matthew Waters from comment #7) > Gahh, gst_video_overlay_rectangle_get_pixels_unscaled_argb does not return > data with native endianness. Confusing. It is, I agree.