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

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Wed May 17 01:07:14 UTC 2017


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

--- Comment #27 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
(In reply to Matt Fischer from comment #26)
> (In reply to Nicolas Dufresne (stormer) from comment #25)
> > I miss that in the review, you indeed need to check if the vmeta pointer is
> > null, otherwise your code may crash. To check if downstream supports
> > GstVideoMeta, you need to look into the allocation query. See
> > "propose_allocation" function in _UploadMethod structure. There is a
> > "decide_query" pointer that contains this information. Then you can get the
> > information using:
> > 
> >   gst_query_find_allocation_meta(query, GST_VIDEO_META_API_TYPE, NULL)
> > 
> 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.

> The offset and stride have to be communicated on the outbuf through a
> VideoMeta, and so if we can't put one on there, then we really can't perform
> the export at all.  And if the input buffer had a VideoMeta, then it seems
> like the pipeline had already negotiated that it was ok to pass them
> downstream anyway.  Would that be sufficient, or is that missing some case
> that we need to cover?

You should always be able to copy the data to get rid of the uncommon strides
and offsets (gst_video_frame_copy() will do that). Your download code should
fail, so another download method can take care. Pushing buffers with
GstVideoMeta when downsteam don't support it is incorrect.

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