GNOME Bugzilla – Bug 793270
videopool: define GST_BUFFER_POOL_OPTION_VIDEO_DMABUF
Last modified: 2018-11-03 12:03:20 UTC
See commit description. Though I'm not sure if this is the correct place to define the macro, neither if it is expected to use dmabuf only for video.
Created attachment 368083 [details] [review] videopool: define GST_BUFFER_POOL_OPTION_VIDEO_DMABUF In order to know if a video buffer pool can produce dmabuf-based buffers this option can be configured and queried in buffers.
Why do you need this ?
(In reply to Nicolas Dufresne (stormer) from comment #2) > Why do you need this ? to check for it when a pool with that option is required (for example bug #793271)
Ok, don't forget about kmssink. I bet adding this option will help decision making in complex cases. I think overall it make sense. Now, the location ... it's a hard one. So far DMABuf is only used for Video, but it should not be limited to that ... Maybe GST_BUFFER_POOL_OPTION_DMABUF, in the base class ... Further thinking, what always come out for Video (this one is video specific) is if there will be 1 FD or multiple FD (planar formats). Is there anyway to advertise / differentiate that ? Two options ?
(In reply to Nicolas Dufresne (stormer) from comment #4) > Ok, don't forget about kmssink. I bet adding this option will help decision > making in complex cases. > > I think overall it make sense. Now, the location ... it's a hard one. So far > DMABuf is only used for Video, but it should not be limited to that ... > Maybe GST_BUFFER_POOL_OPTION_DMABUF, in the base class ... > > Further thinking, what always come out for Video (this one is video > specific) is if there will be 1 FD or multiple FD (planar formats). Is there > anyway to advertise / differentiate that ? Two options ? would that be part of the future allocation meta? Any other opinion? @tim? @slomo?
(In reply to Víctor Manuel Jáquez Leal from comment #5) > (In reply to Nicolas Dufresne (stormer) from comment #4) > > Ok, don't forget about kmssink. I bet adding this option will help decision > > making in complex cases. > > > > I think overall it make sense. Now, the location ... it's a hard one. So far > > DMABuf is only used for Video, but it should not be limited to that ... > > Maybe GST_BUFFER_POOL_OPTION_DMABUF, in the base class ... > > > > Further thinking, what always come out for Video (this one is video > > specific) is if there will be 1 FD or multiple FD (planar formats). Is there > > anyway to advertise / differentiate that ? Two options ? > > would that be part of the future allocation meta? I don't really have a plan anymore. There is also the GstVideoMeta API params for ome of this that could be used. But then for my use cases, I'll need params merging for tee to still work in zero-copy.
See https://bugzilla.gnome.org/show_bug.cgi?id=779146 "This meta can be added to the allocation query to indicate support for dmabuf memory" Isn't what you need Victor ?
-- 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-base/issues/418.