[mythtv] fixes/31 branch created!

Fri Feb 14 14:28:43 UTC 2020

On Fri, Feb 14, 2020 at 9:11 AM Bruce Taber <b.taber at comcast.net> wrote:

>
> On 2/11/20 2:30 PM, Mark Kendall wrote:
> > On Tue, 11 Feb 2020 at 15:31, Mike Bibbings <mike.bibbings at gmail.com>
> wrote:
> >> I would like to run tests on Raspberry Pi 2/3 and 4.
> >>
> >> I assume the local build process, is the same as for Ubuntu/Debian i.e.
> >> install build depends using Ansible and use ./configure (no additional
> >> options) for mythtv.
> >>
> >> At present on a Pi 4 (4GB) with a default install of Raspbian Buster,
> >> the best performance I can get is with V4L2 Codecs, but even this has
> >> issues particularly with HD (UK DVB-T2 ) over HDMI 1920x1080 @50Hz.
> >>
> >> Video Playback Profile defaults to MMAL.
> >>
> >> I maybe missing some necessary settings, there are so many possible
> >> options, so I would like to use the same settings as used during
> >> development, can anyone provide these ?
> >>
> >> The settings needed for pi2/3 and 4 are:
> >>
> >> mythfrontend Video Profile
> >>
> >> any changes required to /boot/config.txt
>
>
> Anybody get any of configurations for the Pi3 to work with fixes/31
> branch? I have two PI3s that worked reasonably well on fixes/30. I can't
> seem to get the correct combination to make them work on 31. Menus are
> slow and playback has severe delay. I've tried MMAL and V4L2 to no
> avail. ThemePainter is set to auto.
>
> The systems run on raspbian stretch and the mythtv software is compiled
> on the systems. Ansible has been used to get the dependencies.
>
> >> Pi 4 default uses dtoverlay=vc4-fkms-v3d with max_framebuffers=2 i.e.
> >> running Fake KMS, Pi 2/3 do not use the fkms overlay.
> >>
> >> Once I have everything working I can update the mythtv-light wiki
> >> page(s) for Raspberry Pi.
> > Mike
> >
> > All of my development work was done using a stock install of Raspbian
> > buster on a Pi3 and Pi4.
> >
> > I think the ansible playlists should cover everything that is needed -
> > as I think the only new requirement is libdrm - which should now be in
> > the playlists where appropriate.
> One thing I've noticed is that the Mythtv Configuration indicates 'DRM
> no'. Not sure if it is indicating the installed libdrm-dev is not
> getting recognized.
> >
> > You shouldn't need to enable/disable anything when running ./configure
> > - though you may want to post the output from your first run, as there
> > is no doubt something I've forgotten:) And of course disabling
> > anything you don't need will speed up compile times.
> >
> > There are some issues - but first some background...
> >
> > One of the main goals of the render branch was to give consistent,
> > performant and accurate video display across different platforms. So
> > there is now one 'display' pathway that always uses OpenGL/ES for
> > rendering.
> >
> > One of the big problems with OpenGL on the Pi is how Qt is configured.
> > A stock raspbian Qt build is built for the open source OpenGL drivers.
> > If the closed source, broadcom driver is in use, Qt OpenGL
> > applications will not work. Likewise, if you tortured yourself enough
> > to build your own Qt with Broadcom support, trying to launch a Qt app
> > using the opensource driver will fail. This has implications for
> > rendering video with OpenGL.
> >
> > One of the first casualties of taking the OpenGL route was openmax
> > support. It is/was effectively just a wrapper around MMAL, I didn't
> > have the energy to modify our code to work with OpenGLES, it is
> > effectively dead in the water and MMAL and V4L2 codecs have all the
> > focus upstream. Openmax (and MMAL) will never get HEVC support but it
> > should arrive for V4L2 at some point. So any build scripts need to be
> > updated to remove any openmax options.
> >
> > So I focused on MMAL and V4L2 codecs, which are both supported
> > reasonably well in FFmpeg.
> >
> > The FFmpeg upstream code for both MMAL and V4L2 will return video
> > buffers to 'main' memory when decoding - not that there is a real
> > distinction between CPU and GPU memory on the Pi - but it does mean
> > there are multiple extra memory transfers for both decoders. This is
> > what the v4l2 and MMAL 'decode only' decoders do. They both work - but
> > are slow - and MMAL will still work in this mode regardless of the
> > OpenGL driver in use. V4L2 'decode only' will only work, I think (it's
> > been a while!), with the open source, VC4 driver.
> >
> > So I patched our version of FFmpeg to use 'zero copy' buffers for both
> > MMAL and V4L2. For V4L2 this means buffers are allocated as DRM-PRIME
> > memory which can then be directly mapped to EGL images/OpenGL textures
> > and displayed without any copies. The MMAL pathway is similar. These
> > are the 'direct rendering' decoders. Unfortunately, Broadcom uses a
> > 'custom' implementation for mapping video memory to textures, so if
> > the open source driver is in use, direct rendering of MMAL video is
> > not available. Likewise, the closed source driver will not work with
> > V4L2 buffers.
> >
> > In summary - a default Raspbian build should give you decoder options
> > of MMAL (decode only), V4L2 and V4L2 (decode only). The supported
> > codecs are different between the Pi3 and Pi4.
> >
> > So to the issues, in no particular order:-
> >
> > - the VC4 V4L2 driver does not pass through the interlacing flags when
> > decoding. So automatic deinterlacing just doesn't work - and you have
> > to manually enable deinterlacing through the OSD menu (other V4L2
> > drivers do handle this - it's just the Pi code that doesn't)
> >
> > - performance is not good enough. I would expect the Pi4 to
> > decode/display a standard h264 1080i stream without issue. But it
> > struggles - especially when deinterlacing (hint: only enable basic
> > deinterlacing). CPU load is low, so I'm assuming there is a bottleneck
> > somewhere. I have a hunch that trying to display anything close to the
> > display refresh rate hits issues - which would point to Qt.
> >
> > - performance can be improved by running mythfrontend without X. Boot
> > to the console and run with 'QT_QPA_PLATFORM=eglfs mythfrontend'. This
> > generally is much smoother - though still far from perfect - but has
> > issues of its own. There is a bug in Qt that causes it to crash on
> > exit and if you are not remotely logged in, you will lose the console.
> > This is, I think, fixed in later versions of Qt. Keypresses also have
> > a nasty habit of being passed to the console as well - which can cause
> > interesting behaviour when you launch a second version of
> > mythfrontend:) and there is a problem with blank screens when exiting
> > playback which is 'resolved' when you press a key. Not sure what
> > causes it but I think something to do with how we disable rendering
> > for plugins etc. and... there is no display mode switching, but I
> > added some Pi specific stuff which will give you frame rate switching
> > at least (it disallows resolution switching as it directly undercuts
> > the Qt platform plugin, which has no idea that it needs to create a
> > new framebuffer).
> >
> > - the Pi3 only has OpenGL ES2.0 - which doesn't support lossless
> > rendering of 10bit video. Obviously probably not a real world issue -
> > but it grates : )
> >
> > - I can't get the Pi4 to switch to 4k60p for love nor money, though I
> > did make some changes so the texture caching in libmythui scales to
> > the size of the display - which speeds up a 4k GUI considerably.
> >
> > Other than that - cec works well out of the box:)
> >
> > In terms of going forward, there is talk of a new V4L2 stateless
> > decoder for HEVC - though I suspect it is some way off. There is a
> > 25,000line patch for FFmpeg to accelerate HEVC on the Pi3  - which I
> > passed on:) - and there is an FFmpeg patch from the Pi foundation for
> > HEVC acceleration on the Pi4 - but it is a work in progress and has no
> > mechanism to integrate with OpenGL.
> >
> > MMAL support could probably be vastly improved by using the MMAL
> > presentation API but I haven't had the time to look at it, and I'm not
> > sure how it would integrate with OpenGL rendering. At the very least
> > it could be used for deinterlacing.
> >
> > The V4L2 direct rendering should be much faster with DRM rendering.
> > That is something I'm going to look at generically (it should work
> > with other devices as well as desktop machines) but it requires a
> > custom Qt platform plugin - which is a big ticket item for various
> > reasons.
> >
> > Any questions, just ask.
> > Regards
> > Mark
> > _______________________________________________
> > 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
> >
> Thanks for any hints/clues that are provided.
>
> Bruce
>
> I don't have a Raspi 3 to experiment on, but on my Raspi 4 I noticed a
change of load from Xorg to Mythfrontend.

These were observations (please don't treat them as scientific measurements
since they are only observations through Top):
(measurement watching Live TV 1080i off of a HDHomerun tuner):

%cpu use                Mythfrontend           Xorg         Mythbackend
fixes/30:                           80%                  20%
20%
fixes/31 or master:          105%                   5%              20%

So there seems to be an increase of total load (from 120% to 130%), but
that can be within the faulttolerance of the measurements. More worrysome
would be that more load is now concentrated on Mytfrontend, so that load
cannot be spread on multiple threads/cores.

The Raspi 4 is only used for testing, so no real user experience here, but
live TV on 1080i seems to be working fine.

Hans.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20200214/b5cd3ddb/attachment.htm>