[Bug 727886] GstVideoGLTextureUploadMeta assumes no color conversion is done during upload

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Wed Apr 9 19:39:51 PDT 2014


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

--- Comment #7 from Matthew Waters <ystreet00 at gmail.com> 2014-04-10 02:39:49 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > Then negotiation will fail based on caps features.  Either both sides of the
> > tee will support the meta or will not.
> 
> Which means that for every such meta, all of these elements (deinterlacer etc.)
> have to be rewritten. Either that, or some kind of converter element, which
> only complicates things and is actually unnecessary. Such a meta should never
> rule out other features.

Why do they have to be rewritten?  I would argue that if you have the meta (and
only that meta) in the caps features, then that's the only way of accessing the
data.  It's not ruling out other features because they weren't there to begin
with.  If however, you also have the Sysmem capsfeatures on the caps then you
can map the buffer and do what you like however (and this is what the bug is
about), the format should be the same for both the uploaded meta and accessing
the buffer through mapping.  Otherwise, you can negotiate between upload meta
and sysmem separately without any issues.

> > > Changing the format in the caps just because a meta is added just feels wrong
> > > to me. The caps should describe what is really inside. Additional mechanisms
> > > like this meta are placed on top of that. They do not replace anything.
> > 
> > Also, there is no guarantee that mapping the buffer is supported when the meta
> > exists, I would even suggest that mapping a buffer with the meta would be
> > undefined behaviour.  The meta provides a way to get the data from a buffer to
> > some GL texture/s of a specified format without downstream explicitly mapping
> > the buffer.
>
> There is a guarantee - if the SystemMemory caps feature is present, then it can
> be mapped. Also, if a GstMemory inside the GstBuffer cannot be mapped (= has
> the GST_MEMORY_FLAG_NOT_MAPPABLE flag set), then mapping will not be possible.

It can only be mapped if Sysmem is negotiated. Caps features are all or
nothing.  i.e. you cannot mix and match caps features from different caps
structures.  Either you support all the caps features in a certain caps
structure or you don't.  With that in mind, you could try to negotiate both
Sysmem and UploadMeta however you will not be able to link with elements that
support one or the other (but not both at the same time).

Sure, you may be able to map a buffer that's been negotiated as having upload
meta (no sysmem), however the data could be in a completely different format to
the one advertised in the caps, thus undefined behaviour.

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


More information about the gstreamer-bugs mailing list