Gstreamer + Clutter + Wayland

[Nicolas Dufresne]

Le jeudi 28 mars 2019 à 10:57 -0500, horai a écrit :
> Hello everybody,
> 
> I tried to run Gstreamer rtsp video playback on Raspberry Pi embedded into
> Clutter stage in Wayland, but the video seems very slow.
> We compiled Wayland/Weston this way:
> https://www.collabora.com/news-and-blog/blog/2016/06/03/running-weston-on-a-raspbian/
> 
> In order to get clutter library with Wayland support, we also recompiled
> libclutter-1.0, clutter-gst and clutter-gtk
> In order to take advantage of hardware video deconding, I was forced to
> recompile gst-plugins-bad as well as gst-omx suited for Raspberry Pi.
> The result is much slower performance compared to the same application
> running on top of X11.
> I would like to point out that the source of all these libraries were the
> same version as packages in Raspbian repository in order to keep
> compatibility with the other libraries' versions installed in the system.
> We also tried to avoid installing as many libraries which were about to
> install mesa related stuff as we already installed Mesa from sources.
> Does anyone have any idea how to find where the bottleneck of the
> application is? We found out that standalone Gstreamer element Waylandsink
> gives reasonable results when playing  pipeline rtsp video from rtspsrc
> element sinking to Waylandsink omxh264dec, but utilitizing Clutter gives
> very poor performance.

omxh264dec zero-copy solution is not supported by the Mesa VC4 driver,
only the brcm GLES driver supports this. I know they are working on a
V4L2 driver that speaks mmal in the kernel, with DMABuf plumbed through
mmal in order to allow using standard DMABuf import path into GL. That
being said, patches where submitted to cluttersink (which is not part
of GStreamer project), but was never merged due to lack of proper
support in CoGL/Clutter. Clutter is basically left without maintenance
these days.

The right solution is what is coming next, but I have no idea when this
will happen, or if there is a way to pick dev version here and there to
make it work.

> On X11, the same application with same versions of all these libraries runs
> reasonably fast. Maybe we should recompile all these libraries from
> up-to-date sources in order to get newest versions, but I guess finding the
> part which slows down the entire system would probably be the key for the
> solution, but does anyone know how to profile it?

Without a compositor, X11 rendering should be faster indeed. Profiling
and trying to get closer in performance is mainly left to you. To speak
for my part, I am waiting on DMABuf support to resume any renderer work
on this target platform.

> 
> 
> 
> 
> --
> 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