overlay: fix check for pixels buffer change.
authorGwenole Beauchesne <gwenole.beauchesne@intel.com>
Fri, 11 Jan 2013 10:12:26 +0000 (11:12 +0100)
committerGwenole Beauchesne <gwenole.beauchesne@intel.com>
Fri, 11 Jan 2013 14:29:12 +0000 (15:29 +0100)
commite876d9a5814be41a3f258214b0d24bb2b82707df
treed96c421c7b59decaa5dfdf817c88a98224f12ed3
parenta14d259060255febe46923a59482a6e7ff25b262
overlay: fix check for pixels buffer change.

A GstVideoOverlayRectangle is created whenever the underlying pixels data
change. However, when global-alpha is supported, it is possible to re-use
the same GstVideoOverlayRectangle but with a change to the global-alpha
value. This process causes a change of sequence number, so we can no longer
check for that.

Still, if sequence numbers did not change, then there was no change in
global-alpha either. So, we need a way to compare the underlying GstBuffer
pointers. There is no API to retrieve the original pixels buffer from
a GstVideoOverlayRectangle. So, we use the following heuristics:

1. Use gst_video_overlay_rectangle_get_pixels_unscaled_argb() with the same
   format flags from which the GstVideoOverlayRectangle was created. This
   will work if there was no prior consumer of the GstVideoOverlayRectangle
   with alternate (non-"native") format flags.

2. In overlay_rectangle_has_changed_pixels(), we have to use the same
   gst_video_overlay_rectangle_get_pixels_unscaled_argb() function but
   with flags that match the subpicture. This is needed to cope with
   platforms that don't support global-alpha in HW, so the gst-video
   layer takes care of that and fixes this up with a possibly new
   GstBuffer, and hence pixels data (or) in-place by caching the current
   global-alpha value applied. So we have to determine the rectangle
   was previously used, based on what previous flags were used to
   retrieve the ARGB pixels buffer.
gst-libs/gst/vaapi/gstvaapicontext.c