Mailing List Archive

fixes/31 branch created!
Hi,

As you may have noticed we cut the fixes/31 branch yesterday.

We are now entering the stabilization phase before the official
release of v31.0

Please test out this branch and provided feedback / raise tickets
as appropriate.


Many thanks
Stuart Auchterlonie
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
On 07/02/2020 11:51, Stuart Auchterlonie wrote:
> Hi,
>
> As you may have noticed we cut the fixes/31 branch yesterday.
>
> We are now entering the stabilization phase before the official
> release of v31.0
>
> Please test out this branch and provided feedback / raise tickets
> as appropriate.
>
>
> Many thanks
> Stuart Auchterlonie


mythweb does not work on Xubuntu 20.04 Daily build which has mysql 8,
ticket raised see https://code.mythtv.org/trac/ticket/13576


Mike

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
On 07/02/2020 11:51, Stuart Auchterlonie wrote:
> Hi,
>
> As you may have noticed we cut the fixes/31 branch yesterday.
>
> We are now entering the stabilization phase before the official
> release of v31.0
>
> Please test out this branch and provided feedback / raise tickets
> as appropriate.
>
>

For information.

Just raised ticket against master branch (fixes/31 works fine) as it
breaks mythfrontend on my system.

see https://codemythtv.org/trac/ticket/13581


Mike


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
On Mon, 10 Feb 2020 at 10:59, Mike Bibbings <mike.bibbings@gmail.com> wrote:
> For information.
>
> Just raised ticket against master branch (fixes/31 works fine) as it
> breaks mythfrontend on my system.
>
> see https://codemythtv.org/trac/ticket/13581

Mike - I've responded in the ticket - but as you'll see, haven't got a clue:)

Regards
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
On 10/02/2020 11:49, Mark Kendall wrote:
> On Mon, 10 Feb 2020 at 10:59, Mike Bibbings <mike.bibbings@gmail.com> wrote:
>> For information.
>>
>> Just raised ticket against master branch (fixes/31 works fine) as it
>> breaks mythfrontend on my system.
>>
>> see https://codemythtv.org/trac/ticket/13581
> Mike - I've responded in the ticket - but as you'll see, haven't got a clue:)
>
> Regards
> Mark
> _______________________________________________


Mark,

Turns out it was my fault, I had a whole lot of older libraries in
/usr/local/lib going back to mythtv 30. After cleaning them all out
everything is now working.

I have annotated the ticket accordingly,


My apologies.


Mike

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
On Mon, 10 Feb 2020 at 16:32, Mike Bibbings <mike.bibbings@gmail.com> wrote:
> Turns out it was my fault, I had a whole lot of older libraries in
> /usr/local/lib going back to mythtv 30. After cleaning them all out
> everything is now working.
>
> I have annotated the ticket accordingly,
>
>
> My apologies.

No problem Mike - I thought there was something odd going on:)

But it prompted me to fix the fallback anyway.

regards
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
On 07/02/2020 11:51, Stuart Auchterlonie wrote:
> Hi,
>
> As you may have noticed we cut the fixes/31 branch yesterday.
>
> We are now entering the stabilization phase before the official
> release of v31.0
>
> Please test out this branch and provided feedback / raise tickets
> as appropriate.
>
>
> Many thanks
> Stuart Auchterlonie


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

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




_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
On Tue, Feb 11, 2020 at 10:31 AM Mike Bibbings <mike.bibbings@gmail.com>
wrote:

> On 07/02/2020 11:51, Stuart Auchterlonie wrote:
> > Hi,
> >
> > As you may have noticed we cut the fixes/31 branch yesterday.
> >
> > We are now entering the stabilization phase before the official
> > release of v31.0
> >
> > Please test out this branch and provided feedback / raise tickets
> > as appropriate.
> >
> >
> > Many thanks
> > Stuart Auchterlonie
>
>
> 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
>
> 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
>

Hi Mike, there has been some changes on the ./configure options that are
needed to compile the 31 branch (at least on a Raspi4, perhaps also on 2
and/or 3); I am not familiar with Ansible, so unless Ansible somehow
recognizes that FFmpeg 4.2 does not support omx_rpi anymore, the config.sh
script will run into trouble unless it is adapted. See
https://forum.mythtv.org/viewtopic.php?f=46&t=3606&p=17282#p17282
Re: fixes/31 branch created! [ In reply to ]
On 11/02/2020 16:49, Hans Dingemans wrote:
> On Tue, Feb 11, 2020 at 10:31 AM Mike Bibbings
> <mike.bibbings@gmail.com <mailto:mike.bibbings@gmail.com>> wrote:
>
> On 07/02/2020 11:51, Stuart Auchterlonie wrote:
> > Hi,
> >
> > As you may have noticed we cut the fixes/31 branch yesterday.
> >
> > We are now entering the stabilization phase before the official
> > release of v31.0
> >
> > Please test out this branch and provided feedback / raise tickets
> > as appropriate.
> >
> >
> > Many thanks
> > Stuart Auchterlonie
>
>
> 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
>
> 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
>
> Hi Mike, there has been some changes on the ./configure options that
> are needed to compile the 31 branch (at least on a Raspi4, perhaps
> also on 2 and/or 3); I am not familiar with Ansible, so unless Ansible
> somehow recognizes that FFmpeg 4.2 does not support omx_rpi anymore,
> the config.sh script will run into trouble unless it is adapted. See
> https://forum.mythtv.org/viewtopic.php?f=46&t=3606&p=17282#p17282

Hi Hans,

The --enable-omx-rpi configure error only affects mythplugins building,
there was a change a few months ago to packaging/deb-light/ which fixed
the mythtv build, a similar required change to mythplugins was overlooked.

python3 changes are also required.

My concern at the moment is getting adequate playback quality on
Raspberry Pi.


Mike
Re: fixes/31 branch created! [ In reply to ]
On Tue, 11 Feb 2020 at 15:31, Mike Bibbings <mike.bibbings@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
>
> 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.

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@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
On 2/11/20 2:30 PM, Mark Kendall wrote:
> On Tue, 11 Feb 2020 at 15:31, Mike Bibbings <mike.bibbings@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@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

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
On Fri, Feb 14, 2020 at 9:11 AM Bruce Taber <b.taber@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@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@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.
Re: fixes/31 branch created! [ In reply to ]
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@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@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

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
On Fri, 14 Feb 2020 at 15:16, Mike Bibbings <mike.bibbings@gmail.com> wrote:
> The following may assist, Raspberry pi Setup wiki has recently been
> updated https://www.mythtv.org/wiki/Raspberry_Pi

I think v31 needs a new page - enough has changed to make it a
different beast. No need to reference openmax, OSD renderers, subtitle
issues (no blended OSD anymore), video display profiles all changed
etc.

> I do have a couple of questions:
>
> 1. Do we still need MPEG2 licence ?

There is no need for a licence on the Pi4 - there is no hardware MPEG2
acceleration. They decided the CPU was powerful enough to decode MPEG2
without help.

On older Pis, I understand an MPEG2 licence will be needed for a few more years.

> 2. Do we still have to set gpu_mem=256 in /boot/config.txt ?

You can probably get away with less but I haven't tested for a while.

I've pushed one tweak for Raspberry Pi performance to master, another
improvement for software decoding/basic opengl deinerlacing almost
ready and then I'm going to take a look at what is inhibiting H264
hardware decoding/playback.

regards
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
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@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@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

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
I've pushed a few improvements in the last few days for the Pi4 - Pi3
not tested. My Pi4 has gone a little nuts however - so will need to
start from scratch before I can go any further.

With the latest fixes, I'd recommend the following display profile
settings for the Pi4 (probably the same for Pi3):-

- decoder - V4L2
- max cpus - 4
- deinterlacer (both single and double rate) - low quality, Prefer
OpenGL deinterlacers.

This should give the best performance for both H264 hardware decode
and fallback to software decoding (e.g. MPEG2 on Pi4, or no licence on
Pi3).

In terms of performance, there is a definite performance limitation
tying to decode 1080P H264. Frames are dropped.

1080i is in theory fine - no frames are dropped, CPU load is low but
playback has intermittent tearing (depending on the source material).
As far as I can tell, this is a Pi4 firmware/driver issue. There are
plenty of reported issues with the Pi4 and tearing and recognition
from the Pi foundation/engineers that this is an unresolved issue. The
giveaway for me is that testing with 1080i, software decode of MPEG2,
there is intermittent breakup of the displayed frames - but absolutely
no indication from the mythtv logs that anything is wrong. Under load,
the timing signals to the display are erratic.

Regards
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
On 18/02/2020 11:17, Mark Kendall wrote:
> I've pushed a few improvements in the last few days for the Pi4 - Pi3
> not tested. My Pi4 has gone a little nuts however - so will need to
> start from scratch before I can go any further.
>
> With the latest fixes, I'd recommend the following display profile
> settings for the Pi4 (probably the same for Pi3):-
>
> - decoder - V4L2
> - max cpus - 4
> - deinterlacer (both single and double rate) - low quality, Prefer
> OpenGL deinterlacers.
>
> This should give the best performance for both H264 hardware decode
> and fallback to software decoding (e.g. MPEG2 on Pi4, or no licence on
> Pi3).
>
> In terms of performance, there is a definite performance limitation
> tying to decode 1080P H264. Frames are dropped.
>
> 1080i is in theory fine - no frames are dropped, CPU load is low but
> playback has intermittent tearing (depending on the source material).
> As far as I can tell, this is a Pi4 firmware/driver issue. There are
> plenty of reported issues with the Pi4 and tearing and recognition
> from the Pi foundation/engineers that this is an unresolved issue. The
> giveaway for me is that testing with 1080i, software decode of MPEG2,
> there is intermittent breakup of the displayed frames - but absolutely
> no indication from the mythtv logs that anything is wrong. Under load,
> the timing signals to the display are erratic.
>
> Regards
> Mark
> _______________________________________________

Hi Mark,

Ran some tests on Pi2 and Pi4 master at commit 4e0da5033

Using your recommended settings LiveTV and recorded playback are looking
good for both Pi2 and Pi4.

On occasion Pi4 LiveTV shows MPEG-2 ffmpeg   Deint None instead of 2x
GLSL Onefield.

mythfrontend started by QT_QPA_PLATFORM=eglfs mythfrontend at console.

It looks like something in drm/fkms/kernel is reading edid from the
connected hdmi device and deciding to ignore settings for hdmi_group and
hdmi_mode in /boot/config.txt.

Being in UK, transmissions are 50Hz based, I use hdmi_group=1 and
hdmi_mode=31 (translates to 1920x1080@50Hz), which is what tvservice -s
reports at console.

Once mythfrontend is running tvservice -s reports different values being
used, depending on capabilities of hdmi connected TV.

hdmi HD TV (max supported 1920x1080@60Hz), see below for full list of
supported CEA modes.

Pi2 and Pi4 state 0xa [HDMI CUSTOM RGB lim 16:9], 1920x1080 @ 60.00Hz,
progressive

hdmi 4K TV, see below for full list of supported CEA modes

Pi4 state 0xa [HDMI CUSTOM RGB lim unknown AR], 4096x2160 @ 30.00Hz,
progressive
This gives terrible playback!


I can work round the problem by using hdmi_cvt= in /boot/config.txt e.g.
for 1920x1080@50Hz but this is a pain for Users.

hdmi_cvt=1920 1080 50
hdmi_group=2
hdmi_mode=87

I can provide any logs you want, just let me know what --loglevel and -v
settings you need.


HD TV modes:

Group CEA has 16 modes:
           mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
           mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
           mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
           mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive
  (native) mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced
           mode 6: 720x480 @ 60Hz 4:3, clock:27MHz x2 interlaced
           mode 7: 720x480 @ 60Hz 16:9, clock:27MHz x2 interlaced
           mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive
           mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive
           mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive
  (native) mode 19: 1280x720 @ 50Hz 16:9, clock:74MHz progressive
           mode 20: 1920x1080 @ 50Hz 16:9, clock:74MHz interlaced
           mode 21: 720x576 @ 50Hz 4:3, clock:27MHz x2 interlaced
           mode 22: 720x576 @ 50Hz 16:9, clock:27MHz x2 interlaced
           mode 31: 1920x1080 @ 50Hz 16:9, clock:148MHz progressive
           mode 32: 1920x1080 @ 24Hz 16:9, clock:74MHz progressive

4K TV modes:

Group CEA has 23 modes:
           mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
           mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
           mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
           mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive
           mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced
           mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive
           mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive
           mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive
           mode 19: 1280x720 @ 50Hz 16:9, clock:74MHz progressive
           mode 20: 1920x1080 @ 50Hz 16:9, clock:74MHz interlaced
           mode 21: 720x576 @ 50Hz 4:3, clock:27MHz x2 interlaced
           mode 31: 1920x1080 @ 50Hz 16:9, clock:148MHz progressive
           mode 32: 1920x1080 @ 24Hz 16:9, clock:74MHz progressive
           mode 33: 1920x1080 @ 25Hz 16:9, clock:74MHz progressive
           mode 34: 1920x1080 @ 30Hz 16:9, clock:74MHz progressive
           mode 63: 1920x1080 @ 120Hz 16:9, clock:297MHz progressive
           mode 64: 1920x1080 @ 100Hz 16:9, clock:297MHz progressive
           mode 93: 3840x2160 @ 24Hz 16:9, clock:297MHz progressive
           mode 94: 3840x2160 @ 25Hz 16:9, clock:297MHz progressive
           mode 95: 3840x2160 @ 30Hz 16:9, clock:297MHz progressive
           mode 98: 4096x2160 @ 24Hz unknown AR, clock:297MHz progressive
           mode 99: 4096x2160 @ 25Hz unknown AR, clock:297MHz progressive
           mode 100: 4096x2160 @ 30Hz unknown AR, clock:297MHz progressive

 and with hdmi_enable_4kp60=1 in /boot/config.txt

Group CEA has 27 modes:
           mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
           mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
           mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
           mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive
           mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced
           mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive
           mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive
           mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive
           mode 19: 1280x720 @ 50Hz 16:9, clock:74MHz progressive
           mode 20: 1920x1080 @ 50Hz 16:9, clock:74MHz interlaced
           mode 21: 720x576 @ 50Hz 4:3, clock:27MHz x2 interlaced
           mode 31: 1920x1080 @ 50Hz 16:9, clock:148MHz progressive
           mode 32: 1920x1080 @ 24Hz 16:9, clock:74MHz progressive
           mode 33: 1920x1080 @ 25Hz 16:9, clock:74MHz progressive
           mode 34: 1920x1080 @ 30Hz 16:9, clock:74MHz progressive
           mode 63: 1920x1080 @ 120Hz 16:9, clock:297MHz progressive
           mode 64: 1920x1080 @ 100Hz 16:9, clock:297MHz progressive
           mode 93: 3840x2160 @ 24Hz 16:9, clock:297MHz progressive
           mode 94: 3840x2160 @ 25Hz 16:9, clock:297MHz progressive
           mode 95: 3840x2160 @ 30Hz 16:9, clock:297MHz progressive
           mode 96: 3840x2160 @ 50Hz 16:9, clock:594MHz progressive
  (native) mode 97: 3840x2160 @ 60Hz 16:9, clock:594MHz progressive
           mode 98: 4096x2160 @ 24Hz unknown AR, clock:297MHz progressive
           mode 99: 4096x2160 @ 25Hz unknown AR, clock:297MHz progressive
           mode 100: 4096x2160 @ 30Hz unknown AR, clock:297MHz progressive
           mode 101: 4096x2160 @ 50Hz unknown AR, clock:594MHz progressive
           mode 102: 4096x2160 @ 60Hz unknown AR, clock:594MHz progressive


Mike

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
On Wed, 19 Feb 2020 at 16:59, Mike Bibbings <mike.bibbings@gmail.com> wrote:
> Ran some tests on Pi2 and Pi4 master at commit 4e0da5033
>
> Using your recommended settings LiveTV and recorded playback are looking
> good for both Pi2 and Pi4.
>
> On occasion Pi4 LiveTV shows MPEG-2 ffmpeg Deint None instead of 2x
> GLSL Onefield.

I suspect I'm going to get a lot of reports of this :(

The default behaviour is now to assume progressive material and only
switch on deinterlacing when interlaced frames are seen.

The main reason for the switch is that FFmpeg is very good these days
at detecting the interlaced flags properly and there are fewer false
positives this way.

There appear to be a number of UK SD channels that have 'mixed'
content. Whether they are genuinely progressive, interlaced or mixed,
I'm not sure - but regardless, it often takes anything from a few
seconds to a few minutes for deinterlacing to actually turn on.

I'm not ruling out an issue with the deinterlacing/video profile code
but I do see this behavour a lot on UK Freeview - without any obvious
loss of quality.

> mythfrontend started by QT_QPA_PLATFORM=eglfs mythfrontend at console.
>
> It looks like something in drm/fkms/kernel is reading edid from the
> connected hdmi device and deciding to ignore settings for hdmi_group and
> hdmi_mode in /boot/config.txt.

You probably want this:-

https://doc.qt.io/qt-5/embedded-linux.html#display-output

and this line is probably key:-

When mode is not defined, the system's preferred mode is chosen. The
accepted values for mode are: off, current, preferred, skip,
widthxheight, widthxheight@vrefresh, or a modeline string.

In summary, you need to create a config file for Qt to read. That
should get the correct mode at startup. If you enable video mode
switching in mythtv settings, it should switch the refresh rate for
you as well (if needed, not really an issue if you are just watching
broadcast 50Hz content).

I can't test right now - but fingers crossed that should do the trick:)

regards
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
On 19/02/2020 18:28, Mark Kendall wrote:
> On Wed, 19 Feb 2020 at 16:59, Mike Bibbings <mike.bibbings@gmail.com> wrote:
>> Ran some tests on Pi2 and Pi4 master at commit 4e0da5033
>>
>> Using your recommended settings LiveTV and recorded playback are looking
>> good for both Pi2 and Pi4.
>>
>> On occasion Pi4 LiveTV shows MPEG-2 ffmpeg Deint None instead of 2x
>> GLSL Onefield.
> I suspect I'm going to get a lot of reports of this :(
>
> The default behaviour is now to assume progressive material and only
> switch on deinterlacing when interlaced frames are seen.
>
> The main reason for the switch is that FFmpeg is very good these days
> at detecting the interlaced flags properly and there are fewer false
> positives this way.
>
> There appear to be a number of UK SD channels that have 'mixed'
> content. Whether they are genuinely progressive, interlaced or mixed,
> I'm not sure - but regardless, it often takes anything from a few
> seconds to a few minutes for deinterlacing to actually turn on.
>
> I'm not ruling out an issue with the deinterlacing/video profile code
> but I do see this behavour a lot on UK Freeview - without any obvious
> loss of quality.
>
>> mythfrontend started by QT_QPA_PLATFORM=eglfs mythfrontend at console.
>>
>> It looks like something in drm/fkms/kernel is reading edid from the
>> connected hdmi device and deciding to ignore settings for hdmi_group and
>> hdmi_mode in /boot/config.txt.
> You probably want this:-
>
> https://doc.qt.io/qt-5/embedded-linux.html#display-output
>
> and this line is probably key:-
>
> When mode is not defined, the system's preferred mode is chosen. The
> accepted values for mode are: off, current, preferred, skip,
> widthxheight, widthxheight@vrefresh, or a modeline string.
>
> In summary, you need to create a config file for Qt to read. That
> should get the correct mode at startup. If you enable video mode
> switching in mythtv settings, it should switch the refresh rate for
> you as well (if needed, not really an issue if you are just watching
> broadcast 50Hz content).
>
> I can't test right now - but fingers crossed that should do the trick:)
>
> regards
> Mark
> _______________________________________________

Hi Mark,

I have produced a script (a bit crude, but works)  to handle the
resolution issue on Pi2/3/4 using a qt eglfs json override file as you
suggested.

At present I create the json file in /home/pi/

The script assumes that user has set the required resolution in
/boot/config.txt (hdmi_group and hdmi_mode).

The script can also be run from .bashrc thus allowing autostart of
mythfrontend at boot.

It would be nice to get the script included in mythtv-light package, so
a user does not have to download it from somewhere.

I need to create something similar for mythtv-setup is run locally on
the Pi (when using Pi as a mythbackend), not required if running via SSH
from another box.


Current script named run_mythfrontend.sh

#!/bin/bash

# script to run mythfrontend from version 31 on Raspberry Pi under
Raspian Buster using EGLFS
# can be added to .bashrc to allow autostart of mythfrontend on boot

# Last Modified 20 February 2020

# Author Mike Bibbings

# check if running via SSH, if so skip running mythfrontend, it must
only run locally.
SSH=$(printenv | grep SSH)
if [ -n "$SSH" ]; then
    exit 1
fi

#check mythfrontend has been installed, if not abort with message
MYTHFRONTEND=`which mythfrontend`
if [ -z "$MYTHFRONTEND" ]; then
    echo -e "mythfrontend not found - please install MythTV-Light package"
    echo -e "See 'https://www.mythtv.org/wiki/MythTV_Light'\n"
    exit 1
fi

echo "Starting MythTV Frontend -- this may take a few seconds -- Please
wait"

# set perfomance mode, not sure if needed for Pi4, do it anyway
echo performance | sudo tee
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

#TODO check /boot/config for hdmi_group and hdmi_mode settings
#HDMI_MODE=$(grep '^hdmi_mode' /boot/config.txt)
#HDMI_GROUP=$(grep '^hdmi_group' /boot/config.txt)

# use tvservice -s for current settings.
# assumes User has setup required resolution.
# for resolutions greater than 1920x1080@60Hz
# hdmi_enable_4kp60=1 is required in /boot/config.txt for Pi4 (not
applicable to Pi2/3)

CURRENT_REFRESH=$(tvservice -s|sed -n -e 's/^.*@ //p')
#get first 2 characters
CURRENT_REFRESH=${CURRENT_REFRESH:0:2}

CURRENT_RES=$(tvservice -s|sed -n -e 's/^.*], //p')
#strip out everything except resolution e.g. 1920x1080
CURRENT_RES=${CURRENT_RES%%[[:space:]]*}

RESOLUTION="$CURRENT_RES@$CURRENT_REFRESH"

# we need override file to force correct resolution.
# QT defaults to using EDID from connected hdmi device
# pi2/3 use /dev/dri/card0,  pi4 /dev/dri/card1
# find out which model of Pi we have

PI_MODEL=$(grep -ic 'Pi 4' /proc/device-tree/model)
if [ "$PI_MODEL" = 1 ]
then
      CARD="card1"
else
      CARD="card0"
fi

#file created everytime this script is run,avoids checking previous and
current resolution everytime
bash -c "cat >/home/pi/pi_mythfrontend.json" <<ENDOFSCRIPTINPUT
{
    "device": "/dev/dri/${CARD}",
    "outputs": [
        { "name": "HDMI1", "mode": "${RESOLUTION}" }
    ]
}
ENDOFSCRIPTINPUT

#for QT debug add to command line QT_QPA_EGLFS_DEBUG=1
QT_LOGGING_RULES=qt.qpa.*=true
QT_QPA_PLATFORM=eglfs
QT_QPA_EGLFS_KMS_CONFIG=/home/pi/pi_mythfrontend.json mythfrontend
--logpath /tmp
# fixup keyboard after exit from mythfrontend (bug in QT causes segment
fault which kills keyboard input)
kbd_mode -u

exit 0



_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
On Thu, 20 Feb 2020 at 18:39, Mike Bibbings <mike.bibbings@gmail.com> wrote:
> Hi Mark,
>
> I have produced a script (a bit crude, but works) to handle the
> resolution issue on Pi2/3/4 using a qt eglfs json override file as you
> suggested.
>

Mike

Nice work on the script. I do intend to rework the frontend window
settings for 0.32 - and one of those changes will be to allow the user
to set the default GUI video mode (rather than just using what it
started with). As it stands however that won't work for the Pi without
X - due to permission issues with drm.

I've also made changes to the software deinterlacers. Yadif is now the
high quality deinterlacer (with multithreading support) and there is a
new linearblend filter for medium quality. It should be reasonably
fast on the Pi *if* neon intrinsics support is enabled at compile time
- details in the commit :-

https://github.com/MythTV/mythtv/commit/8b16ce6ae8a8e214c3002a13d911c8356e061373

Not sure if OpenGL onefield/bob is still faster though:)

regards
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
On 27/02/2020 11:14, Mark Kendall wrote:
> On Thu, 20 Feb 2020 at 18:39, Mike Bibbings <mike.bibbings@gmail.com> wrote:
>> Hi Mark,
>>
>> I have produced a script (a bit crude, but works) to handle the
>> resolution issue on Pi2/3/4 using a qt eglfs json override file as you
>> suggested.
>>
> Mike
>
> Nice work on the script. I do intend to rework the frontend window
> settings for 0.32 - and one of those changes will be to allow the user
> to set the default GUI video mode (rather than just using what it
> started with). As it stands however that won't work for the Pi without
> X - due to permission issues with drm.
>
> I've also made changes to the software deinterlacers. Yadif is now the
> high quality deinterlacer (with multithreading support) and there is a
> new linearblend filter for medium quality. It should be reasonably
> fast on the Pi *if* neon intrinsics support is enabled at compile time
> - details in the commit :-
>
> https://github.com/MythTV/mythtv/commit/8b16ce6ae8a8e214c3002a13d911c8356e061373
>
> Not sure if OpenGL onefield/bob is still faster though:)
>
> regards
> Mark
> _______________________________________________

Hi Mark,

Latest version v32-Pre-151-g4e81d4b52b  working well on Pi4.

On a Pi2 I am seeing from time to time - it is fatal, and it needs a
reboot to resolve.

[ 4067.968745] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from
CMA:
[ 4067.968765] [drm]                            V3D: 158964kb BOs (1142)
[ 4067.968771] [drm]                     V3D shader:     84kb BOs (21)
[ 4067.968778] [drm]                           dumb:   8116kb BOs (2)
[ 4067.968783] [drm]                         binner:  16384kb BOs (1)
[ 4067.968789] [drm]                total purged BO:  21216kb BOs (112)
[ 4067.970319] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from
CMA:
[ 4067.970333] [drm]                            V3D: 151216kb BOs (1114)
[ 4067.970339] [drm]                     V3D shader:     84kb BOs (21)
[ 4067.970343] [drm]                           dumb:   8116kb BOs (2)
[ 4067.970349] [drm]                         binner:  16384kb BOs (1)
[ 4067.970354] [drm]                total purged BO:  21216kb BOs (112)
[ 4067.981562] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from
CMA:
[ 4067.981577] [drm]                            V3D: 151216kb BOs (1114)
[ 4067.981583] [drm]                     V3D shader:     84kb BOs (21)
[ 4067.981588] [drm]                           dumb:   8116kb BOs (2)
[ 4067.981595] [drm]                         binner:  16384kb BOs (1)
[ 4067.981601] [drm]                total purged BO:  21216kb BOs (112)
[ 4068.076587] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from
CMA:
[ 4068.076607] [drm]                            V3D: 159380kb BOs (1116)
[ 4068.076613] [drm]                     V3D shader:     84kb BOs (21)
[ 4068.076620] [drm]                           dumb:   8116kb BOs (2)
[ 4068.076627] [drm]                total purged BO:  31516kb BOs (174)
[ 4068.076642] vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile
binning: -12. You may need to enable CMA or give it more memory.

Note this is using mythfrontend only  to a remote backend.

Have you or anyone else seen this ?

There is a thread on Raspberry forum see
https://www.raspberrypi.org/forums/viewtopic.php?f=53&t=223363&p=1613246&hilit=vc4_v3d+3fc00000.v3d%3A+Failed+to+allocate+memory+for+tile+binning%3A#p1613246

which also gives a possible solution

echo on >/sys/devices/platform/soc/*.v3d/power/control


Mike

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
> Wiadomo?? napisana przez Mike Bibbings <mike.bibbings@gmail.com> w dniu 10.03.2020, o godz. 13:57:
>
> Hi Mark,
>
> Latest version v32-Pre-151-g4e81d4b52b working well on Pi4.
>
> On a Pi2 I am seeing from time to time - it is fatal, and it needs a reboot to resolve.
>
> [ 4067.968745] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> [ 4067.968765] [drm] V3D: 158964kb BOs (1142)
> [ 4067.968771] [drm] V3D shader: 84kb BOs (21)
> [ 4067.968778] [drm] dumb: 8116kb BOs (2)
> [ 4067.968783] [drm] binner: 16384kb BOs (1)
> [ 4067.968789] [drm] total purged BO: 21216kb BOs (112)
> [ 4067.970319] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> [ 4067.970333] [drm] V3D: 151216kb BOs (1114)
> [ 4067.970339] [drm] V3D shader: 84kb BOs (21)
> [ 4067.970343] [drm] dumb: 8116kb BOs (2)
> [ 4067.970349] [drm] binner: 16384kb BOs (1)
> [ 4067.970354] [drm] total purged BO: 21216kb BOs (112)
> [ 4067.981562] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> [ 4067.981577] [drm] V3D: 151216kb BOs (1114)
> [ 4067.981583] [drm] V3D shader: 84kb BOs (21)
> [ 4067.981588] [drm] dumb: 8116kb BOs (2)
> [ 4067.981595] [drm] binner: 16384kb BOs (1)
> [ 4067.981601] [drm] total purged BO: 21216kb BOs (112)
> [ 4068.076587] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
> [ 4068.076607] [drm] V3D: 159380kb BOs (1116)
> [ 4068.076613] [drm] V3D shader: 84kb BOs (21)
> [ 4068.076620] [drm] dumb: 8116kb BOs (2)
> [ 4068.076627] [drm] total purged BO: 31516kb BOs (174)
> [ 4068.076642] vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile binning: -12. You may need to enable CMA or give it more memory.
>
> Note this is using mythfrontend only to a remote backend.
>
> Have you or anyone else seen this ?
>

looks to me like kernel has too smal CMA to operate with video playback.
cma is needed as video frames decoded by decoder and passed to 3D engine needs continues memory regions (rpi iirc don’t have IOMMU to help here)
may you pls try do add in config.txt i.e.
cma=256 (or 384)
and see how it goes?

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: fixes/31 branch created! [ In reply to ]
On 10/03/2020 16:10, Piotr Oniszczuk wrote:
>
>> Wiadomo?? napisana przez Mike Bibbings <mike.bibbings@gmail.com> w dniu 10.03.2020, o godz. 13:57:
>>
>> Hi Mark,
>>
>> Latest version v32-Pre-151-g4e81d4b52b working well on Pi4.
>>
>> On a Pi2 I am seeing from time to time - it is fatal, and it needs a reboot to resolve.
>>
>> [ 4067.968745] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
>> [ 4067.968765] [drm] V3D: 158964kb BOs (1142)
>> [ 4067.968771] [drm] V3D shader: 84kb BOs (21)
>> [ 4067.968778] [drm] dumb: 8116kb BOs (2)
>> [ 4067.968783] [drm] binner: 16384kb BOs (1)
>> [ 4067.968789] [drm] total purged BO: 21216kb BOs (112)
>> [ 4067.970319] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
>> [ 4067.970333] [drm] V3D: 151216kb BOs (1114)
>> [ 4067.970339] [drm] V3D shader: 84kb BOs (21)
>> [ 4067.970343] [drm] dumb: 8116kb BOs (2)
>> [ 4067.970349] [drm] binner: 16384kb BOs (1)
>> [ 4067.970354] [drm] total purged BO: 21216kb BOs (112)
>> [ 4067.981562] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
>> [ 4067.981577] [drm] V3D: 151216kb BOs (1114)
>> [ 4067.981583] [drm] V3D shader: 84kb BOs (21)
>> [ 4067.981588] [drm] dumb: 8116kb BOs (2)
>> [ 4067.981595] [drm] binner: 16384kb BOs (1)
>> [ 4067.981601] [drm] total purged BO: 21216kb BOs (112)
>> [ 4068.076587] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
>> [ 4068.076607] [drm] V3D: 159380kb BOs (1116)
>> [ 4068.076613] [drm] V3D shader: 84kb BOs (21)
>> [ 4068.076620] [drm] dumb: 8116kb BOs (2)
>> [ 4068.076627] [drm] total purged BO: 31516kb BOs (174)
>> [ 4068.076642] vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile binning: -12. You may need to enable CMA or give it more memory.
>>
>> Note this is using mythfrontend only to a remote backend.
>>
>> Have you or anyone else seen this ?
>>
> looks to me like kernel has too smal CMA to operate with video playback.
> cma is needed as video frames decoded by decoder and passed to 3D engine needs continues memory regions (rpi iirc don’t have IOMMU to help here)
> may you pls try do add in config.txt i.e.
> cma=256 (or 384)
> and see how it goes?
>
> ____________________________________________

kernel already has cma=256

[    0.000000] cma: Reserved 256 MiB at 0x1ec00000
[    0.000000] Kernel command line: coherent_pool=1M cma=256M
video=HDMI-A-1:1920x1080M@50,margin_left=0,margin_right=0,margin_top=0,margin_bottom=0
smsc95xx.macaddr=B8:27:EB:F3:20:52 vc_mem.mem_base=0x3ec00000
vc_mem.mem_size=0x40000000  console=ttyAMA0,115200 console=tty1
root=PARTUUID=ea7d04d6-02 rootfstype=ext4 elevator=deadline
fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
[    0.000000] Memory: 684636K/970752K available (8192K kernel code,
653K rwdata, 2220K rodata, 1024K init, 822K bss, 23972K reserved,
262144K cma-reserved)

The problem can take many hours to appear but when it does, it requires
a hard reboot (power off then on) unless already logged in via ssh from
another machine, in which case sudo reboot works.

Mike


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org