should v4l2h264dec add "video/x-raw(memory:DMABuf)" besides "video/x-raw"?

[Halley Zhao]

thank, the explanation is clear.
I'd simply add nv12 to my weston shm_formats.

Nicolas Dufresne <nicolas at ndufresne.ca> 于2019年5月9日周四 下午7:40写道：

> Le jeudi 09 mai 2019 à 11:04 +0800, Halley Zhao a écrit :
> > Hi experts:
> > v4l2h264dec claims it supports "video/x-raw" format only, but it may use
> dmabuf format (its capture-io-mode supports
> rw/mmap/userptr/dmabuf/dmabuf-import). should it add
> "video/x-raw(memory:DMABuf)" as well.
> > on nxp imx8 bsp, I found caps negotiation goes with "video/x-raw"
> (diskplay->shm_formats), but buffer flows with
> dmabuf(display->dmabuf_formats), because there is
> gst_wl_linux_dmabuf_construct_wl_buffer() in log.
>
> v4l2h264dec always output DMABuf. DMABuf is user mappable memory, there
> is no need to have a caps feature in general. The DMABuf caps feature
> was added for specific use cases, to support implicit tiling (Intel
> GFX, and that was actually a bad idea), to support protected FDs (non-
> readable DMABuf, use to carry DRM content) and is open for future
> support for proprietary formats (like the one exposed through DRM
> modifiers). The caps feature implement is quite partial overall.
>
> >
> > I met issue that caps negotiation fails between v4l2h264dec and
> waylandsink,
> > because on my platform (imx8 + customized weston), v4l2h264dec claims it
> support video/x-raw with NV12 format, waylandsink claims it support
> video/x-raw without NV12 format, plus video/x-raw(memory:DMABuf) with NV12
> format.
>
> Compositors cannot guaranty availability of HW planes. Thus, it is
> important to provide a fallback mechanism (usually through the GL
> renderer) and then offer the same formats for both DMABuf and SHM.
> waylandsink will send DMABuf if the format is supported through the
> extension even without the caps feature.
>
> Of course, if you prefer hard failure if DMABuf isn't used, you may
> want to implement DMABuf caps feature support in v4l2 plugin. Patches
> are welcome, though be aware that negotiation of that feature should be
> last resort (chosen last).
>
> Nicolas
>
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190513/1fd41677/attachment.html>