[mythtv] MythTV Raspberry Pi2 frontend testers

Bryan bryan at mlewallpapers.com
Wed Dec 9 21:00:05 UTC 2015


What are your video RAM and clock settings from /boot/config.txt?

e.g.
arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=2
gpu_mem=256



On Wed, Dec 9, 2015 at 1:53 PM, Andreas Mayer <and.mayer at aon.at> wrote:

>
> 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
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20151209/41d3774d/attachment.html>


More information about the mythtv-dev mailing list