[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 #15 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2012-03-16 12:14:15 UTC ---
> > But then, perhaps a consumer that does support global
> > alpha should just check the GstBuffer pointers it gets 
> 
> Also a possibility, one that would already be possible without further changes,
> but maybe a bit hackish? 
> 
> > - we could put a seqnum into GST_BUFFER_OFFSET() or
> > so which could be used along the same lines.
> 
> You lost me here.

A consumer can't 100% rely on the buffer pointer values to identify the same
buffer (unless it keeps a ref to the buffer itself), since the buffer structure
could be recycled by GSlice etc. GST_BUFFER_OFFSET() is a field in the buffer
structure, which we could abuse to store a seqnum, which could then be used to
uniquely identify buffers.


> True, but this depends also on the usage of the API on the producer side.
> As there is no _composition_remove_rectangle() the only way for the producer to
> update an already existing rectangle for changed data is 
> 
> _composition_unref(cached_comp);
> _composition_new(cached_rect);
> foreach (cached_rects as r)
> ... _add_rectangle(r)

They should be able to do:

 comp = composition_make_writable (comp);
 rect = get_rectangle (comp, 0)
 rectange_set_global_alpha (rect, X)

I didn't see the point of doing a remove_rectangle, since you have to make the
composition writable anyway before doing that, and then you could just not
bother and not cache the composition in the producer and only keep on to the
rectangles and always create a new composition. But we could add a
_remove_rectangle() or _steal_rectangle() if that makes things easier.


> This is, btw, a bit unclear in the API description. Also
> draft-subtitle-overlays.txt is not very clear about the expected handling of
> composition-lifetime vs. rectangle-lifetime.

Perhaps that could be expanded upon. It depends on the elements involved
really. So far, all that caching is mostly theoretical (I think), not sure it's
implemented anywhere (perhaps in gst-vaapi?)


> Please let me know how you decide for the seq_num issue, to avoid further
> re-coding ;-)

I don't know what to do about that right now, let's just update the seq_num as
you do and ignore the issue for now. I think this needs more thought. Perhaps
document in _get_seqnum() that those aren't as useful as they may seem.

-- 
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.