<div dir="ltr"><div>What are your video RAM and clock settings from /boot/config.txt?<br><br></div>e.g.<br>arm_freq=1000<br>core_freq=500<br>sdram_freq=500<br>over_voltage=2<br>gpu_mem=256<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 1:53 PM, Andreas Mayer <span dir="ltr"><<a href="mailto:and.mayer@aon.at" target="_blank">and.mayer@aon.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On 09.12.2015 13:00, Lawrence Rust wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, 2015-12-08 at 14:16 +0100, Andreas Mayer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 03.12.2015 13:00, Lawrence Rust wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would stick with Qt4 on Jessie. That covers the least unknown<br>
ground. EGLFS is not necessary to use the OpenMAX renderer - it works<br>
fine on X too. The only advantage is the EGLFS based OSD which is<br>
clearer and smoother.Let me know how you get on. -- Lawrence Rust<br>
</blockquote>
By using Qt4 on Jessie again (and using your updated fixes-0.27-rpi2<br>
branch) I was able to compile now without troubles (build took about one<br>
hour with make -j4 and without mythplugins).<br>
The only thing I had to do was to include /opt/vc headers and libraries<br>
when configuring (and to remove one inline definition in FFmpegs<br>
intmath.h, I guess because I did enable the external decoders).<br>
</blockquote>
That's encouraging. NB the latest mythbuild.sh script now supports<br>
x-building for Jessie too. Just execute...<br>
<br>
RASPBIAN_FLAVOUR=jessie mythbuild.sh -Q 5.4.0 ...<br>
<br>
to build MythTV with Qt5.4.0 and EGLFS support (but no external decoder<br>
support).<br>
</blockquote></span>
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.<br>
I think next I will give a native Qt 5 opengl ES build a try ...<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Playback of some test videos (recorded from Astra) using mythfrontend<br>
does work now without problems (I'm using a profile with openmax<br>
decoder, softblend OSD and openmax advanced HW deinterlacer as well, no<br>
overclocking, for testing I'm using mythavtest):<br>
720x576i@25 6.2Mb/s mpeg2: 25-30%<br>
1280x720p@50 13,9Mb/s H.264: 50-55%<br>
1920x1080i@25 H.264: 55-60%<br>
I've got one VC-1 test video with high bitrate (1920x1080p@24 20Mb/s)<br>
which is still unusable (CPU > 100% and stuttering, omxplayer is able to<br>
playback with 18%).<br>
</blockquote>
The CPU figures are a bit higher than I would expect but not<br>
significantly so. Could this be down to the network or file system?<br>
Out of curiosity, what sort of connection (including NIC/dongle) do you<br>
have between FE & BE, or was this from SD card? I'm beginning to think<br>
that network/file overhead could be adding some significant CPU load,<br>
especially because of Myth's inefficient buffering & copying.<br>
</blockquote></span>
For my tests I did use some videos stored on SSD connected over USB yesterday.<br>
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.<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
With the current MythTV architecture we can't compete with omxplayer<br>
because Myth requires A/V sync control in software, forcing a break<br>
between decoder & renderer, whereas omxplayer uses a single OpenMAX<br>
hardware tunnel from source to video output.<br>
<br>
While on the efficiency tack, I've been able to tweak the OpenMAX<br>
decoder to share buffers with the video renderer. This avoids a CPU<br>
buffer copy. A 1920x1080 frame occupies ~3MB so @ 30Hz this avoids<br>
~100MB/s of CPU copies. In my tests this lowers CPU overhead by around<br>
8% for SD and 15% for HD.<br>
<br>
You can pull the additional 2 patches from softsystem/fixes-0.27-rpi2 or<br>
softsystem/master-rpi2.<br>
</blockquote></span>
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):<br>
720x576i@25 6.2Mb/s mpeg2: 15-25% (was 25-30%)<br>
1280x720p@50 13,9Mb/s H.264: 40-45% (was 50-55%)<br>
1920x1080i@25 H.264: 40-45% (was 55-60%)<br>
My VC-1 test video with high bitrate (1920x1080p@24 20Mb/s) is still unusable.<br>
<br>
So the improvement is about 5 to 15%, really good!<br>
<br>
I'm still unsure why I get higher numbers than you do? But I guess it depends on bitrate too.<br>
I'm using a HDMI display with 1920x1080 native resolution if that matters.<br>
<br>
Would it be possible to use openmax HW acceleration for audio as well or would that be of no additional value?<br>
<br>
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.<br>
THX again for your work!<br>
<br>
Are you planning to submit your work to the main myth development tree?<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Optionally download the pre-built archives (~100MB)<br>
# For Debian wheezy/0.27:<br>
wget <a href="http://www.softsystem.co.uk/download/mythtv/mythtv-v0.27.5-101-g665ee21-RPI2.tar.bz2" rel="noreferrer" target="_blank">http://www.softsystem.co.uk/download/mythtv/mythtv-v0.27.5-101-g665ee21-RPI2.tar.bz2</a><br>
# For Debian wheezy/0.28:<br>
wget <a href="http://www.softsystem.co.uk/download/mythtv/mythtv-v0.28-pre-3252-g0a0927f-RPI2.tar.bz2" rel="noreferrer" target="_blank">http://www.softsystem.co.uk/download/mythtv/mythtv-v0.28-pre-3252-g0a0927f-RPI2.tar.bz2</a><br>
# For Debian jessie/0.28:<br>
wget <a href="http://www.softsystem.co.uk/download/mythtv/mythtv-v0.28-pre-3252-g0a0927f-RPI2-jessie.tar.bz2" rel="noreferrer" target="_blank">http://www.softsystem.co.uk/download/mythtv/mythtv-v0.28-pre-3252-g0a0927f-RPI2-jessie.tar.bz2</a><br>
<br>
The jessie build even runs on a Pi Zero! The Zero can only cope with SD<br>
material though, but at $5 what do you expect?<br>
<br>
</blockquote></span>
Pretty cool, although I think usabilty will be limited (SD and no wired network connection).<span class="HOEnZb"><font color="#888888"><br>
<br>
Andreas Mayer</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
mythtv-dev mailing list<br>
<a href="mailto:mythtv-dev@mythtv.org" target="_blank">mythtv-dev@mythtv.org</a><br>
<a href="http://lists.mythtv.org/mailman/listinfo/mythtv-dev" rel="noreferrer" target="_blank">http://lists.mythtv.org/mailman/listinfo/mythtv-dev</a><br>
<a href="http://wiki.mythtv.org/Mailing_List_etiquette" rel="noreferrer" target="_blank">http://wiki.mythtv.org/Mailing_List_etiquette</a><br>
MythTV Forums: <a href="https://forum.mythtv.org" rel="noreferrer" target="_blank">https://forum.mythtv.org</a><br>
</div></div></blockquote></div><br></div>