GNOME Bugzilla – Bug 793271
v4l2object: Check for all allocators and pools in query
Last modified: 2018-11-03 15:25:59 UTC
See commit description.
Created attachment 368084 [details] [review] v4l2object: Check for all allocators and pools in query When the io-mode is dmabuf-import is important to look for an allocator and pool that supports dmabuf, either a dmabuf descendant allocator or a pool with the GST_BUFFER_POOL_OPTION_VIDEO_DMABUF config.
Ok, I see why you wanted this in 793270 now. There was an open question if it was ever correct to add a DMABuf allocator (for the case there is no alloc/custom) in the allocation query. I think if the answer is no, then until we have a non-custom dmabuf allocator, this is a bit speculative. For the pool option, well, an option is supposed to be explicitly enabled by the user. So the usage is a bit of a clash if enabling it have no effect (it's already enabled).
(In reply to Nicolas Dufresne (stormer) from comment #2) > Ok, I see why you wanted this in 793270 now. There was an open question if > it was ever correct to add a DMABuf allocator (for the case there is no > alloc/custom) in the allocation query. I think if the answer is no, then > until we have a non-custom dmabuf allocator, this is a bit speculative. Agree, a dmabuf allocator with a custom alloc, as the gstreamer-vaapi case, might no be right to share it. I can remove it from the query in gstreamer-vaapi :) > For the pool option, well, an option is supposed to be explicitly enabled by > the user. So the usage is a bit of a clash if enabling it have no effect > (it's already enabled). If enabled and downstream doesn't provide a dmabuf-enable pool or allocator, it fails.
(In reply to Víctor Manuel Jáquez Leal from comment #3) > (In reply to Nicolas Dufresne (stormer) from comment #2) > > Ok, I see why you wanted this in 793270 now. There was an open question if > > it was ever correct to add a DMABuf allocator (for the case there is no > > alloc/custom) in the allocation query. I think if the answer is no, then > > until we have a non-custom dmabuf allocator, this is a bit speculative. > > Agree, a dmabuf allocator with a custom alloc, as the gstreamer-vaapi case, > might no be right to share it. I can remove it from the query in > gstreamer-vaapi :) And looking at the implementation, it's not used. > > > For the pool option, well, an option is supposed to be explicitly enabled by > > the user. So the usage is a bit of a clash if enabling it have no effect > > (it's already enabled). > > If enabled and downstream doesn't provide a dmabuf-enable pool or allocator, > it fails. Make sense. Shall we add code to enable it though ?
Created attachment 368132 [details] [review] v4l2object: Check for all allocators and pools in query When the io-mode is dmabuf-import is important to look for a pool that supports dmabuf, that is, a buffer pool with GST_BUFFER_POOL_OPTION_VIDEO_DMABUF config.
(In reply to Nicolas Dufresne (stormer) from comment #4) > (In reply to Víctor Manuel Jáquez Leal from comment #3) > > Agree, a dmabuf allocator with a custom alloc, as the gstreamer-vaapi case, > > might no be right to share it. I can remove it from the query in > > gstreamer-vaapi :) > > And looking at the implementation, it's not used. Removed. I have updated the patches for vaapi pool to ignore any non-vaapi allocator and try to reuse the already set allocator, if there's one. > > > For the pool option, well, an option is supposed to be explicitly enabled by > > > the user. So the usage is a bit of a clash if enabling it have no effect > > > (it's already enabled). > > > > If enabled and downstream doesn't provide a dmabuf-enable pool or allocator, > > it fails. > > Make sense. Shall we add code to enable it though ? IMO, if the user request a specific io-mode an it's not achieved, the pipeline should fail.
Review of attachment 368132 [details] [review]: The main problem with this patch is that it's not backward compatible. We have kmssink that export a pool the produce DMABuf, without modifying kmssink, the following pipeline will not work any-more: v4l2src io-mode=dmabuf-import ! kmssink This is because the code will no longer consider any pool that does not have the new option.
-- 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/437.