This could be more involved than it seems as, in the ideal world, if downstream offers memory:dmabuf, it would be best for v4l2src to automatically elect for io-mode=dmabuf-import, instead of having to explicitly set that property.

Comments welcome.

It could be nice to document through example pipelines the cases where you want the caps feature to be announce and how it will be useful to solve something we can't otherwise. A proposed solution to probe the HW for EXPBUF would also help.

(or maybe you only care about the caps feature for DMABUF importation, memory:dmabuf caps feature has this ambiguity we need to consider)

You don't need to put dmabuf in the caps, it is an allocator, it should be selected at pool negotiation time.
You can iterate into pool possible allocators and decide to use dmabuf so you can set the correct io-mode.

This statement is not entirely correct. The dmabuf caps feature can lead to different output videoformat being chosen by v4l2transform, it can also help certain auto-plugger cases. It's not just a matter of allocation.

+1 for memory:dmabuf caps feature. I think the discussions about having this feature as derived here: https://bugzilla.gnome.org/show_bug.cgi?id=711155

After gst wayland, vaapi and gl, isn't v4l2 turn ? :)

Patch welcome of course. Though, it's not as trivial, I would do the exporter. First, the importer require several weeks of work.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/163.