GNOME Bugzilla – Bug 666090
videoconvert: Add support for GST_VIDEO_FLAG_PREMULTIPLIED_ALPHA
Last modified: 2018-11-03 11:20:02 UTC
Currently only non-premultiplied alpha is supported. I'd add it by adding new variants of all the video formats with alpha and adding a new flag to GstVideoFormatFlags. Adding it to GstVideoColorimetry is probably not enough because that is not negotiable currently
There's GST_VIDEO_FLAG_PREMULTIPLIED_ALPHA now
> There's GST_VIDEO_FLAG_PREMULTIPLIED_ALPHA now Is that enough? It's not even used anywhere apart from the video overlay code - at least videoconvert etc. would need to be able to handle it (or the packing/unpacking funcs in libgstvideo).
video-convert should use premultiplied alpha when doing scaling or else you can get wrong colors from neighbouring pixels with 0 alpha. video-convert should therefore look at the input video-info flags and premultiply before scaling if needed, then look at the output flags and unpremultiply if needed. We don't have anything in the caps to mark premultiplied alpha.
Premultiplying and then unpremultiplying will reduce the precision of the color components though, in the worst case leaving everything black. Or for AYUV, green :)
And first premultiplying and then unpremultiplying whenever we scale seems quite expensive.
at a bare minimum we should zero out all color with 0 alpha to make sure whatever random color is in there doesn't get used when interpolating.
Yeah, I see what you mean :) It would give better results if the alpha is preserved, but if something is modifying only the alpha later (videoconvert to a non-alpha format!) you would lose colors. And it also seems to require more CPU to modify the colors. All options seem not great :)
A compromise could be to allocate an extra buffer, in which we store the pre-multiplied colors. This way we can reference the original and the premultiplied colors as needed to maintain precision. And we don't need to "unmultiply" at the end.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/56.