QT5, video playback over Wayland questions.

[George Kiagiadakis]

On 28/10/15 18:01, James Hughes wrote:
> Hello all,
> 
>  
> 
> I have some questions about running QT5.5 over Wayland, and playing back
> video using a gstreamer pipeline, on an embedded system. We have a QT
> application and performance is much slower than when using gstreamer
> gst-launch1.0 directly. We have determined that the cause of this is
> that the video pipeline ends up using a QGstreamerVideoRenderer rather
> than something based wayland sink. This means, we suspect, an extra copy
> of the video data, meaning we don’t the the same performance.
> 
>  
> 
> Looking at the code in qgstreamerplayerservice.cpp, we have
> 
>  
> 
> #if defined(Q_WS_MAEMO_6) && defined(__arm__)
> 
>     m_videoRenderer = new QGstreamerGLTextureRenderer(this);
> 
> #elif defined(HAVE_MIR) && defined (__arm__)
> 
>     m_videoRenderer = new QGstreamerMirTextureRenderer(this, m_session);
> 
> #else
> 
>     m_videoRenderer = new QGstreamerVideoRenderer(this);
> 
> #endif
> 
>  
> 
> So there are a couple of implmentations of video surface renderers for
> specific backends, in this case gl and mir.
> 
>  
> 
> My thoughts are that I need to add a new class, something like
> QGstreamerWaylandRenderer that I can insert at this point to provide a
> wayland backend for the video player.
> 
>  
> 
> Does this seem like the correct approach? I’ve been trundling through
> the code (and Google) and am making very slow progress , but if there is
> anyone out there who can point me in the right direction for
> documentation or any sort of architectural information on how all this
> bolts together, it would definitely make my life easier!
> 

I think that the correct approach would be to teach the code to use the
GL backend. This is probably going to perform better than the generic
video renderer, as it will allow scaling and colorspace conversion to
happen in hardware. If you need something even more performant than
that, then the correct approach would be to investigate the use of
dmabuf  to transfer video buffers from your hardware decoder (assuming
you are using one, since you are on embedded) to the graphics pipeline
directly. This will need some more work, though.

A wayland-specific backend for the video renderer is probably not going
to be significantly better than the generic renderer. I don't really
know what this code does, but I assume that the generic renderer goes
through QPainter, which in turn translates to painting on a shared
memory surface, using the wl_shm wayland interface to transfer it to the
display server. This is also what the GStreamer waylandsink does, so
there is no big difference. Maybe in your gst-launch tests you are using
glimagesink instead of waylandsink actually?

> 
> I do find it a bit odd that there isn’t already something in place for
> this. There is a QTWayland backend for general GUI stuff, but this
> gstreamer video stuff doesn’t seem to have the right backend in place to
> take advantage of the acceleration of Wayland that we have on the platform.
> 
>  
> 
> James
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3956 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151105/7921d6ab/attachment.bin>