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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Halley Zhao
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.

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.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

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

Nicolas Dufresne-5
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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 于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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel