[mythtv] MythTV Raspberry Pi2 frontend testers

Andreas Mayer and.mayer at aon.at
Wed Dec 9 18:53:06 UTC 2015


On 09.12.2015 13:00, Lawrence Rust wrote:
> 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).
Will think about that for the future (since I would need updated Windows 
builds as well), but currently I will continue with native RPi2 Jessie 
builds.
I think next I will give a native Qt 5 opengl ES build a try ...

>> 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.
For my tests I did use some videos stored on SSD connected over USB 
yesterday.
RPi2 is using a wired 100Mbit connection to my mythtv BE wich has a 
100Mbit NIC too (both connected to Gbit switches) but that did not 
matter in this case.
>
> 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.
Test results with the updates (again with mythavtest, no overclocking, 
mpeg2 and vc1 license keys, it made no real difference if test videos 
were read from SSD over USB or from local micro SD card or using NFS 
mounts from the myth BE using a 100Mbit wired connection):
720x576i at 25 6.2Mb/s mpeg2: 15-25% (was 25-30%)
1280x720p at 50 13,9Mb/s H.264: 40-45% (was 50-55%)
1920x1080i at 25 H.264: 40-45% (was 55-60%)
My VC-1 test video with high bitrate (1920x1080p at 24 20Mb/s) is still 
unusable.

So the improvement is about 5 to 15%, really good!

I'm still unsure why I get higher numbers than you do? But I guess it 
depends on bitrate too.
I'm using a HDMI display with 1920x1080 native resolution if that matters.

Would it be possible to use openmax HW acceleration for audio as well or 
would that be of no additional value?

Anyways. as far as I can tell by now your current MythTV openmax support 
would allow me to use RPi2 as a full function MythTV Frontend in most 
use cases.
THX again for your work!

Are you planning to submit your work to the main myth development tree?

> 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?
>
Pretty cool, although I think usabilty will be limited (SD and no wired 
network connection).

Andreas Mayer


More information about the mythtv-dev mailing list