[Bug 668483] video: add support for global-alpha multiplicator for overlay rectangles

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=668483
  GStreamer | gst-plugins-base | git

--- Comment #4 from Holger Kaelberer <hk at getslash.de> 2012-02-17 08:43:07 UTC ---
Thanks for your comments.

> I think for most use cases defaulting to 1.0 is sufficient, and if anyone wants 
> to set a different global alpha they can use the setter API after creating the 
> rectangle, no?

I agree, that was what I thought first, but then wanted to be complete in the
constructing call. Will change ...

> What I think should happen is that it automagically modifies the overlay pixel 
> data (making it writable first if needed) and multiplies all the alpha values  
> in it with the global alpha if the caller doesn't support global alpha.

Ok, that would be a nice extension. That's basically the step we perform so far
in the producer-plugin. I will move it into the overlay-composition code then
and implement it equivalently to the PREMULTIPLIED_ALPHA flag/functionality,
defaulting to 'handle global alpha inside OverlayComposition-API' and leave
pixel-values untouched only if requested by consumer/renderer. (VA-API
definesvaSetSubpictureGlobalAlpha() in its interface, but it's mostly
unimplemented in the backends). I think we will need to backup the initial
per-pixel alpha values inside the GstVideoOverlayRectangle because (for fading
for example) multiple calls to rect_set_global_alpha() on the same pixel-data
are to be expected and global_alpha multiplication should always be relative to
the initial per-pixel alpha values. This backup-array will be treated like the
pixel-values, i.e. not copied in a _copy()-call.

One detail that is unclear to me is how you want seq_num handling to be done.
The per-rectangle seq_num *must* be changed after a call to set_global_alpha()
on the producer side so that the consumer/renderer can detect the changed
pixel-data and update its specific overlays/subpictures (at least thats how its
done in the vaapi-case). Do you think the seq_num should updated automatically
or on demand?

For example, consider the case of an already created overlay_composition+rects
that will be updated per-chain call. producer-side calls:

gst_video_overlay_composition_make_writable(comp);
# -> unlikely updating the seq_nums
gst_video_overlay_rectangle_set_global_alpha(rect1, val);

Should a gst_video_overlay_rectangle_update_seq_num() be introduced here or
make set_global_alpha() update the seq_num automatically?

I would propose the last.

Same holds for gst_video_overlay_rectangle_set_render_rectangle().

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.