[Bug 776927] gl: gldownload: convert GstGLMemory to GstDmaBuf

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Wed May 17 15:03:18 UTC 2017


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

--- Comment #28 from Matt Fischer <mattfischer84 at gmail.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #27)
> > That makes sense, and I can add that if necessary.  However, I was wondering
> > if we need to go to that much trouble.  Would it be sufficient simply to say
> > if the inbuf has a VideoMeta then we're allowed to put one on the outbuf,
> > and if it doesn't have one, then just don't bother with exporting at all? 
> 
> No, because the reason gldownload element have GstVideoMeta attached has
> input is because it will advertise it in it's main "propose_allocation". It
> is completely unrelated with downstream support.
> 
Sorry for causing so much hassle here, but I have just one more question on
this.  As it stands now, the gldownload element does not have either a
propose_allocation or a decide_allocation method.  My understanding is that
this means it will just pass along any allocation queries from downstream to
upstream without modification.  So if upstream is sending us VideoMetas,
doesn't that mean that the downstream element said that it supported them, and
our element simply passed that information back upstream?

I can understand your statement in cases where gldownload had its own
propose/decide methods, and could therefore send something upstream which is
different than what is downstream.  But in cases where it's simply passing the
requests through transparently, can't we just react to what the upstream
element is sending, based on the fact that it negotiated that feature with the
downstream element during the allocation phase?

I can certainly implement a decide_allocation method, check the query for the
VideoMeta feature, and save off a bit telling the transform function that it's
ok to add VideoMetas to the buffers that it creates.  I'm just having trouble
understanding the case where that would result in different behavior than
simply examining the input buffer, given that gldownload passes allocation
requests through unmodified.

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