[mythtv] fixes/31 branch created!

[Mike Bibbings]

On 14/02/2020 15:15, Mike Bibbings wrote:
> On 14/02/2020 14:10, Bruce Taber 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
>
>
> The following may assist, Raspberry pi Setup wiki has recently been 
> updated https://www.mythtv.org/wiki/Raspberry_Pi
>
> In summary, still work in progress.
>
> All Raspberry Pi Models - MythTV Version 31 and on.
>
>     Settings using raspi-config
>         Wait for Network ( B2 Wait for Network at Boot Choose whether 
> to wait for network connection during boot )
>         Boot to console with autologin for user pi  (B2 Console 
> Autologin Text console, automatically logged in as 'pi' user)
>         Enable  vc4-fkms driver   (G2 GL (Fake KMS) OpenGL desktop 
> driver with fake KMS)
>
>     Run time setting
>         enable performance governor (default is ondemand)
>         echo performance | sudo tee 
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
>
> At console prompt start mythfrontend as follows (mythbackend should be 
> found automatically):
> QT_QPA_PLATFORM=eglfs mythfrontend --logpath /tmp
>
> MythTV Frontend Setup Wizard set Video profile to V4L2 Codecs.
>
>
> I have a script to run mythfrontend:
>
> create a file named run_mythfrontend.sh in root of pi user i.e. 
> /home/pi/ with the following contents:
>
> #!/bin/sh
> # check if running via SSH, if so skip running mythfrontend, it must 
> only run locally.
> SSH=$(printenv | grep SSH)
> #echo "SSH Running = $SSH"
> if [ -z "$SSH" ]; then
> # set perfomance mode
> echo performance | sudo tee 
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
> echo -e "\n Starting MythTV Frontend -- this may take a few seconds -- 
> Please wait"
> QT_QPA_PLATFORM=eglfs mythfrontend --logpath /tmp
> # fixup keyboard after exit from mythfrontend
> kbd_mode -u
> fi
>
> make it executable
> chmod +x run_mythfrontend.sh
>
> For autostart on boot add /home/pi/run_mythfrontend.sh to .bashrc file
>
>
> I do have a couple of questions:
>
> 1. Do we still need MPEG2 licence ?
>
> 2. Do we still have to set gpu_mem=256 in /boot/config.txt ?
>
>
> Mike
>
Whoops!

I missed the bit about Pi 3 on stretch.

The only development that I am aware of for MythTV 31 and on, is for 
Raspbian Buster, not Stretch. In particular Pi 4 requires Raspbian Buster.

My understanding is that anyone using MythTV on Raspbian Stretch will 
need to upgrade to Raspbian Buster  (a clean install is recommended, 
in-place upgrade from Stretch to Buster may or may not work) for MythTV 
31 and on.


Mike