[mythtv] MythTV Raspberry Pi2 frontend testers

[Lawrence Rust]

On Tue, 2015-12-08 at 14:16 +0100, Andreas Mayer wrote:
> On 03.12.2015 13:00, Lawrence Rust wrote:
> > 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
> By using Qt4 on Jessie again (and using your updated fixes-0.27-rpi2 
> branch) I was able to compile now without troubles (build took about one 
> hour with make -j4 and without mythplugins).
> The only thing I had to do was to include /opt/vc headers and libraries 
> when configuring (and to remove one inline definition in FFmpegs 
> intmath.h, I guess because I did enable the external decoders).

That's encouraging.  NB the latest mythbuild.sh script now supports
x-building for Jessie too.  Just execute...

RASPBIAN_FLAVOUR=jessie mythbuild.sh -Q 5.4.0 ...

to build MythTV with Qt5.4.0 and EGLFS support (but no external decoder
support).

> Playback of some test videos (recorded from Astra) using mythfrontend 
> does work now without problems (I'm using a profile with openmax 
> decoder, softblend OSD and openmax advanced HW deinterlacer as well,  no 
> overclocking, for testing I'm using mythavtest):
> 720x576i at 25 6.2Mb/s mpeg2: 25-30%
> 1280x720p at 50 13,9Mb/s H.264: 50-55%
> 1920x1080i at 25 H.264: 55-60%
> I've got one VC-1 test video with high bitrate (1920x1080p at 24 20Mb/s) 
> which is still unusable (CPU > 100% and stuttering, omxplayer is able to 
> playback with 18%).

The CPU figures are a bit higher than I would expect but not
significantly so.  Could this be down to the network or file system?
Out of curiosity, what sort of connection (including NIC/dongle) do you
have between FE & BE, or was this from SD card?  I'm beginning to think
that network/file overhead could be adding some significant CPU load,
especially because of Myth's inefficient buffering & copying.

With the current MythTV architecture we can't compete with omxplayer
because Myth requires A/V sync control in software, forcing a break
between decoder & renderer, whereas omxplayer uses a single OpenMAX
hardware tunnel from source to video output.

While on the efficiency tack, I've been able to tweak the OpenMAX
decoder to share buffers with the video renderer.  This avoids a CPU
buffer copy.  A 1920x1080 frame occupies ~3MB so @ 30Hz this avoids
~100MB/s of CPU copies.  In my tests this lowers CPU overhead by around
8% for SD and 15% for HD.

You can pull the additional 2 patches from softsystem/fixes-0.27-rpi2 or
softsystem/master-rpi2.

Optionally download the pre-built archives (~100MB)
# For Debian wheezy/0.27:
wget http://www.softsystem.co.uk/download/mythtv/mythtv-v0.27.5-101-g665ee21-RPI2.tar.bz2
# For Debian wheezy/0.28:
wget http://www.softsystem.co.uk/download/mythtv/mythtv-v0.28-pre-3252-g0a0927f-RPI2.tar.bz2
# For Debian jessie/0.28:
wget http://www.softsystem.co.uk/download/mythtv/mythtv-v0.28-pre-3252-g0a0927f-RPI2-jessie.tar.bz2

The jessie build even runs on a Pi Zero!  The Zero can only cope with SD
material though, but at $5 what do you expect?

-- Lawrence Rust