[mythtv] MythTV Raspberry Pi2 frontend testers

Lawrence Rust lvr at softsystem.co.uk
Wed Dec 2 21:18:12 UTC 2015


On Tue, 2015-12-01 at 21:32 +0100, Andreas Mayer wrote:
> Hi Lawrence,
> 
> first of all I would like to thank you for your great work allowing to 
> start use of OpenMax for MythTV on RPi2 (and for your build script I'm 
> using too for the mythtv build on Windows)!
> 
> I started to play with your development tree on Raspian Wheezy with Qt4 
> (Wheezy) and Qt5 (from twolike.be repository) installed (on Rpi2 with 
> mpeg2 and vc-1 license keys installed).
> 
> The binary build did play mpeg videos quite well (but with higher CPU 
> utilization than LiveTV using Kodi with the mythtv pvr plugin),
> The playback of H.264 videos was partially successful (some stuttering), 
> with one VC-1 video playback was unusable.
> I did run mythfrontend with -v playback to verify decoder and renderer used.
> 
> Next I tried to compile native on Wheezy without much luck (Qt4 does not 
> include OpenGL ES 2.0 support, would have needed additional Qt5 packages 
> but twolife.be did already switch to Jessie).

You should be able to build natively with Qt 4.8.x.  The OpenMAX decoder
and renderer should still build and function without OpenGLES2.  You'll
have to make do with a softblend OSD as without OpenGLES2 there's no EGL
overlay.  I'm looking for a workaround for this as it also impacts use
with Xv.  NB you will need the latest sources as they include a fix to
allow building without OpenGLES2. 

> So I decided to continue with a new vanilla Jessie image (and Jessie Qt 
> 5.3.2 packages) and initially had the same problems that were already 
> discussed here.
> As far as I remember:
> additional includes/libraries needed for /opt/vc
> configure failed to detect OpenGL ES when Qt4 and Qt5 were installed, 
> even if Qt5 included opengles
> QTCONF=$(pkg-config --variable=qt_config QtCore || pkg-config 
> --variable=qt_config Qt5Core)
> if echo "$QTCONF" | grep -qv opengles2 ; then
>      disable opengles
> fi

This doesn't matter, OpenGLES2 is not necessary for basic function.

> compile failed for videoout_omx.cpp, as far as I was able to find out 
> because there was redefinition of Bool and None in some X11 library, I 
> did #undef Bool. None and KeyPress (yes, I know, very dirty way)
> I had to include additional headers in videoout_omx.cpp (QTransform, 
> vc_dispmanx.h) and to typedef EGL_DISPMANX_WINDOW_T

This shouldn't be necessary when compiling latest source - it should
automatically omit any/all OpenGL references if OpenGLES2 is not
available.

> Finally I was able to successfully compile and install mythtv on Jessie.
> 
> Later on I had to find out that the Jessie Qt5 packages appear not to 
> use vc opengles, neither mythfontend nor Qt example hellogl_es2 
> -platform eglfs where able to create a surface.
> "EGL Error : Could not create the egl surface: error = 0x300b"

That is to be expected.

> Next I did install the Qt5 packages provided by twolife.be, both 
> mythfrontend and hellogl_es2 were able to start without an error message 
> but there is no usable screen display for both.

I feel that trying to get OpenGLES and EGLFS supported is too bleeding
edge until Qt5.4 or later becomes the default for Debian.

> Both Kodi (with videos on local SSD attached using USB and streamed 
> using UPnP from my mythbackend, without PVR addon because currently 
> there is no prebuilt package availabe) and omxplayer were able to 
> playback some mpeg, H264 and one VC-1 test videos without using too much 
> CPU.
> 
> Currently I'm still trying to get a usable native compile on Jessie.
> I think (without knowing any details how your work and kodi/omxplayer 
> openmax interfaces differ) that in addition one would need to improve 
> something to reduce CPU utilization (but I don't know if that's 
> something caused by mythtv in general or by the openmax part).

On my 2 RPi's (without overclocking) using the latest 0.27 build and a
profile with openmax decoder & renderer using the Advanced HW
deinterlacer I get the following CPU loads in EGLFS mode connected to a
BE with 802.11n WiFi.  The BE also uses WiFi.

- Live BBC1 (720x576i at 25Hz) uses about 15% CPU (includes MHEG data).
- Live BBC1HD (1920x1080i at 25Hz) uses about 25% CPU.

I have a 1280x720p at 50Hz test clip (stored locally) that plays on Myth
with about 15% CPU.  Omxplayer plays the same clip with about 5% CPU.

The major difference between the 2 is that omxplayer uses a complete
OpenMAX pipeline (GPU driven) to read/decode/render the clip whereas
Myth breaks the pipeline between decoder and renderer to manage A/V sync
and hence incurs 2 additional frame copies (1 CPU, 1 GPU).  In addition,
Myth handles file/network reads very inefficiently by copying (to
ringbuffer) in multiple places.  Without major architectural changes to
Myth I don't see much room for improvement.  I have an idea that might
finesse one of the CPU copies but it's pushing Myth's design limits.

The major overhead I see is GPU usage which runs out of steam with an HD
video and OSD.

> My nexts possible steps would be to try to find out why eglfs is not 
> working on Jessie and to try to compile Qt(5) myself using your patches.
> What do you think?

I would stick with Qt4 on Jessie.  That covers the least unknown ground.
EGLFS is not necessary to use the OpenMAX renderer - it works fine on X
too.  The only advantage is the EGLFS based OSD which is clearer and
smoother.

Let me know how you get on.

-- Lawrence Rust



More information about the mythtv-dev mailing list