[mythtv] MythTV Raspberry Pi2 frontend testers

[Lawrence Rust]

On Wed, 2015-12-09 at 19:53 +0100, Andreas Mayer wrote:
[snip]
> > 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.

I'm also using a 1920x1080 HDMI display so that counts the display rez
out.

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

I believe that improved audio decoding may hold the key to achieving
parity with omxplayer.  I've been experimenting with my Zero and tweaked
the memory footprint of the video renderer so that the Zero comfortably
plays SD video with 64MB of GPU memory (the Zero can't hack an EGL OSD
so softblend is required).  During testing I disabled audio (audio
device set to NULL) and measured around 20% CPU utilisation for a
720x576i at 25 H264 clip.  When I re-enabled audio I found the CPU load
shot to over 45%.  Using 'top -H' (show threads) demonstrated that the
decoder thread uses <10% for video decoding alone but that shoots up to
30+% when audio is enabled.  I'm going to run the same tests on a RPi2
to see if audio decoding causes a similar load there.

Off-loading audio decoding is going to take some significant changes in
avformatdecoder since the current structure assumes that ffmpeg will
always decode the audio stream.  It's not impossible but it needs
careful thought.

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

Yes - ASAP.  Hopefully I'm going to be granted git commit rights very
soon now.  So look forward to some changes in these areas.

[snip]
> > 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).

The Zero was always just 'proof of concept', nothing more.  It's always
revealing to run on the lowest powered system - it has a habit of
flushing out the gremlins.  I've always believed that devs should
develop on the lowest powered system that an app is expected to run on.
Devs have a habit of refining an app so that it runs comfortably on the
test machine.

-- Lawrence Rust