[Bug 783521] gl: Add "direct" dmabuf uploader

[GStreamer (GNOME Bugzilla)]

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

--- Comment #72 from Michael Olbrich <m.olbrich at pengutronix.de> ---
(In reply to Nicolas Dufresne (ndufresne) from comment #71)
> First sorry for the confusion on my previous comment, I worked on this on
> the plane and didn't realize your comments.

No problem.

> Yes, note that I didn't ignore your patch, "glupload: Do prepend the
> preferred caps" implements what you described, but in the specific uploader
> instead of globally. So it's the same but narrowed to direct dmabuf upload.
> Prepending RGBA should be glcolorconvert jobs for the cases where glupload
> isn't doing color conversion. It's nothing new, videoconvert does that same
> to encourage upstream into going passthrough.

Hmm, downstream caps are not propagated properly right now. Try this for
example:

videotestsrc ! glupload ! \
"video/x-raw(memory:GLMemory),format={RGBA,I420}" ! fakesink

Without my patch, I420 is chosen and I don't think that's correct. Your patch
added an extra structure with RGBA and I420 but without my patch the order of
the two is picked from the filter caps and there I420 comes first.

In practice this probably wont matter. I don't think there is a realistic
use-case like that.

There might be issues when elements are plugged after the pipeline starts, but
that's nothing new.

> And I also when for the subset approach like you also described, even though
> I agree that something isn't quite right. It fixes the regression that first
> data pointer get uploaded twice (not just that unit test failing). I'll need
> your help to confirm it also works for you use case, considering that my
> Intel GPU do very little formats in direct dmabuf upload.

I'm not seeing any problems. I've considered this some more. I've pretty sure
what we do here is correct.
The subset means that the caps produces by the upload method are compatible but
possibly stricter than the caps negotiated with downstream. I don't think we
can produce a buffer here that will not be accepted downstream.

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