[Bug 797234] overlaycomposition: New element that allows applications to draw GstVideoOverlayComposition on a stream

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797234

--- Comment #8 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
> > I wonder if we should actually pass the buffer here too, 
> > there might be metas on the buffer that are relevant for
> > what should be drawn (e.g. extra time metas or other kind
> > of metas).
> 
> Maybe we should just pass a GstSample here? Then we have the
> buffer and also the segment.

Yes, sounds like a good idea, if we can implement it in a way that reuses a
GstSample in the normal case and doesn't create a GstSample for each buffer.

> > >+  if (gst_pad_check_reconfigure (self->srcpad)) {
> > >+    if (!gst_overlay_composition_negotiate (self, NULL)) {
> > >+      gst_pad_mark_reconfigure (self->srcpad);
> > >+      gst_buffer_unref (buffer);
> > >+      if (GST_PAD_IS_FLUSHING (self->srcpad))
> > >+        return GST_FLOW_FLUSHING;
> > >+      ..
> > >+    }
> > >+  }
> > 
> > Not sure the GST_PAD_IS_FLUSHING is thread-safe here, since we don't hold
> > the srcpad object lock? Maybe we want a gst_pad_is_flushing() too?
> 
> If the negotiation failed due to flushing, then the relevant locks were all
> taken already before. But using gst_pad_is_flushing() would be cleaner, yes.

Negotiation could have failed for another reason, and we could have a
flush-start event being processed at the same time in another thread, no?
(unlikely as it may be, but still)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.