Gstreamer + Clutter + Wayland

[Nicolas Dufresne]

Le ven. 19 avr. 2019 15 h 25, horai <ivo.hora at seznam.cz> a écrit :

> Dear sir,
>
> Thank you once more.
> I tested the element v4l2h264dec with this simple pipeline:
> gst-launch-1.0 -e rtspsrc location="rtsp://10.0.0.9:8555/test" latency=0 !
> rtph264depay ! h264parse ! v4l2h264dec ! videoconvert ! waylandsink (or
> clutterautovideosink)
> I compared it to:
> gst-launch-1.0 -e rtspsrc location="rtsp://10.0.0.9:8555/test" latency=0 !
> rtph264depay ! h264parse ! omxh264dec ! videoconvert ! waylandsink (or
> clutterautovideosink)
>
> It works, but the performance load was approximately the same.
>

Nice to see it's drop in replacement. I was not clear enough, I'm expecting
better performance with glimagesink over Mesa.

Anyway, what I do not fully understand is why, when compiling gst-omx, it is
> requesting header from libraspberrypi-dev
> which seem to be header files for libraspberrypi0. If I understand
> correctly
> libraspberrypi0 are proprietary GPU drivers from Broadcom supporting
> zero-copy. Well, I am I right stating that omx compiled agains this headers
> would have the zero-copy feature?


Both OMX and Broadcom GL requires calling the infamous brcm_init()
function. There is also some Broadcom GL code in gst-omx, but it won't be
used on Mesa GL.

This way I don't fully understand how it
> could switch from Broadcom binary to VC4 the one running the Weston is
> running on top:
> [10:52:28.444] GL version: OpenGL ES 2.0 Mesa 19.1.0-devel (git-2b7d5c3217)
> [10:52:28.445] GLSL version: OpenGL ES GLSL ES 1.0.16
> [10:52:28.445] GL vendor: Broadcom
> [10:52:28.445] GL renderer: VC4 V3D 2.1
>
> Anyway, I will continue trying to find solution for the slow performance.
> Even the before-mentioned pipeline is rather sluggish (but excellent
> delay).
> Clutter is a problem, maybe I experience what you have already mentioned
> that it is not maintained anymore ,as Wayland support is labeled as
> experimental after ./autogen.sh process. Anyway I compiled COGL with OpenGL
> (GL) as well as OpenGL ES 2.0 (GLES2) support the same I did with clutter
> and assumed that just swapping drivers:
> CLUTTER_DRIVER=gles2|gl could make some difference. But no way. Anyway, as
> always I blame myself as there are tons of switches (EGL, KMS etc. etc.)
> during compiling and requires a lot more testing.
> If only there would be a Clutter cookbook :)
>

For waylandsink, was the videoconvert required ? The best performance would
be achieved if Weston accept the colorformat and allow dmabuf FD being
passed.

For glimagesink, you should also try forcing GLES 2, since it's will be
closer to what the HW can do. GST_GL_API=gles2



>
>
>
>
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> 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/20190419/2f89b4e5/attachment.html>