Mailing List Archive

On 04/10/2019 17:36, Mike Bibbings wrote:
> On 04/10/2019 08:48, Mark Kendall wrote:
>> On Thu, 3 Oct 2019 at 14:57, Mike Bibbings <mike.bibbings@gmail.com>
>> wrote:
>>> Mark,
>>>
>>> I have rebuilt with the "optimisation" commented out, no failures of
>>> any
>>> kind with livetv channel switching.
>>>
>>> However many of the channel changes are taking a long time up to around
>>> 30 seconds. There are some which are 1-2 seconds.
>>>
>> Mike - try the attached patch.
>>
>> Seems to be working without issue (i.e. no failures and fast(er)
>> channel changes (circa 3 seconds max)).
>>
>> Regards,
>> Mark
>
> Hi Mark,
>
> Thanks for the patch, it is looking good on DVB-T/T2 with my Hauppauge
> Quad HD tuner (PCI-e), yet to be tested with DVB-S/S2.
>
> I have switched my production system from master to the 2019-render
> branch, with the patch, to give it a workout.
>
> My production system uses PCI-e DVB-T/T2 and network DVB-S/S2 tuners.
>
>
> Mike
>

Mark,

Just reporting back.

I have had no failures running with the livetv patch over the weekend
using DVB-T/T2 or DVB-S/S2

It looks good for a commit at your leisure.

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

On Mon, 7 Oct 2019 at 11:53, Mike Bibbings <mike.bibbings@gmail.com> wrote:

> Mark,
>
> Just reporting back.
>
> I have had no failures running with the livetv patch over the weekend
> using DVB-T/T2 or DVB-S/S2
>
> It looks good for a commit at your leisure.

Thanks Mike - I've committed a more complete patch - but results
should be the same.

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

I just gave the 2019-render branch (devel/2019-render
v31-Pre-1095-gc7eabdaf86) a try on one of my frontend machines. The
frontend is home-built Apollo Lake Celeron J3455 system running Xubuntu
18.04 with Vaapi version 1.10. The frontend is used almost exclusively for
viewing NTSC LiveTV and the output is configured for a 1920x1080@59.94
modeline. The frontend is configured with a VAAPI2 profile with Vaapi
acceleration and opengl-hw High quality deinterlacing.

Everything works great with the exception of one issue:
On 1920x1080i channels where deinterlacing is in use, any overlaid info
flickers in the overlaid section in the top 1/4 or of the screen (see video
here: https://youtu.be/PXospaUX1lo). The same flickering behavior is also
observed if viewing a 1920x1080i@30fps recording so this doesn't appear
unique to LiveTV. The overlay flickering is not present in any
circumstance when viewing 1280x720@60 content where deinterlacing is not in
use.

To compare, I also tried the render branch on another machine with an
Nvidia card (GT 1030 / driver version 390.116). Using VDPAU acceleration
and opengl-hw deinterlacing on this frontend, the overlay flickering is not
present with either interlaced or progressive content.

Any hints on why I might be experiencing this with VAAPI acceleration on my
Apollo Lake machine?

Thank you for all of your work on this!
Tim


Tim

On Fri, Oct 11, 2019 at 6:10 AM Mark Kendall <mark.kendall@gmail.com> wrote:

> On Mon, 7 Oct 2019 at 11:53, Mike Bibbings <mike.bibbings@gmail.com>
> wrote:
>
> > Mark,
> >
> > Just reporting back.
> >
> > I have had no failures running with the livetv patch over the weekend
> > using DVB-T/T2 or DVB-S/S2
> >
> > It looks good for a commit at your leisure.
>
> Thanks Mike - I've committed a more complete patch - but results
> should be the same.
>
> 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
>

On Mon, Oct 21, 2019 at 7:26 PM Tim Pletcher <pletchtd@gmail.com> wrote:

> I just gave the 2019-render branch (devel/2019-render
> v31-Pre-1095-gc7eabdaf86) a try on one of my frontend machines. The
> frontend is home-built Apollo Lake Celeron J3455 system running Xubuntu
> 18.04 with Vaapi version 1.10. The frontend is used almost exclusively for
> viewing NTSC LiveTV and the output is configured for a 1920x1080@59.94
> modeline. The frontend is configured with a VAAPI2 profile with Vaapi
> acceleration and opengl-hw High quality deinterlacing.
>
> Everything works great with the exception of one issue:
> On 1920x1080i channels where deinterlacing is in use, any overlaid info
> flickers in the overlaid section in the top 1/4 or of the screen (see video
> here: https://youtu.be/PXospaUX1lo). The same flickering behavior is also
> observed if viewing a 1920x1080i@30fps recording so this doesn't appear
> unique to LiveTV. The overlay flickering is not present in any
> circumstance when viewing 1280x720@60 content where deinterlacing is not
> in use.
>
> To compare, I also tried the render branch on another machine with an
> Nvidia card (GT 1030 / driver version 390.116). Using VDPAU acceleration
> and opengl-hw deinterlacing on this frontend, the overlay flickering is not
> present with either interlaced or progressive content.
>
> Any hints on why I might be experiencing this with VAAPI acceleration on
> my Apollo Lake machine?
>
> Thank you for all of your work on this!
> Tim
>
>
> Tim
>
> On Fri, Oct 11, 2019 at 6:10 AM Mark Kendall <mark.kendall@gmail.com>
> wrote:
>
>> On Mon, 7 Oct 2019 at 11:53, Mike Bibbings <mike.bibbings@gmail.com>
>> wrote:
>>
>> > Mark,
>> >
>> > Just reporting back.
>> >
>> > I have had no failures running with the livetv patch over the weekend
>> > using DVB-T/T2 or DVB-S/S2
>> >
>> > It looks good for a commit at your leisure.
>>
>> Thanks Mike - I've committed a more complete patch - but results
>> should be the same.
>>
>> 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
>
>
So sorry about the prior top-post. I don't email the mailing list very
often.... Reposting in the proper place below.

I just gave the 2019-render branch (devel/2019-render
v31-Pre-1095-gc7eabdaf86) a try on one of my frontend machines. The
frontend is home-built Apollo Lake Celeron J3455 system running Xubuntu
18.04 with Vaapi version 1.10. The frontend is used almost exclusively for
viewing NTSC LiveTV and the output is configured for a 1920x1080@59.94
modeline. The frontend is configured with a VAAPI2 profile with Vaapi
acceleration and opengl-hw High quality deinterlacing.

Everything works great with the exception of one issue:
On 1920x1080i channels where deinterlacing is in use, any overlaid info
flickers in the overlaid section in the top 1/4 or of the screen (see video
here: https://youtu.be/PXospaUX1lo). The same flickering behavior is also
observed if viewing a 1920x1080i@30fps recording so this doesn't appear
unique to LiveTV. The overlay flickering is not present in any
circumstance when viewing 1280x720@60 content where deinterlacing is not in
use.

To compare, I also tried the render branch on another machine with an
Nvidia card (GT 1030 / driver version 390.116). Using VDPAU acceleration
and opengl-hw deinterlacing on this frontend, the overlay flickering is not
present with either interlaced or progressive content.

Any hints on why I might be experiencing this with VAAPI acceleration on my
Apollo Lake machine?

Thank you for all of your work on this!
Tim

On Tue, 1 Oct 2019 at 07:44, Klaas de Waal <klaas.de.waal@gmail.com> wrote:

> > If you have tearing in master and the branch - you definitely have a
> > vsync issue.
> >
> > A quick google gave me this:-
> >
> > https://askubuntu.com/questions/240923/enable-sync-to-vblank-on-lxde-with-intel-video-card
> >
> > Otherwise try forcing sync to vbank from the command line (intel/amd
> > driver environment variable) :
> >
> > vblank_mode=1 mythfrontend -v playback
> >
> The 'vblank_mode=1' did not make any difference, the first one will be
> tested after the next reboot.
> Agree that this has probably nothing to do with your changes.

Klaas,

Just a thought - having noticed tearing when I was testing something
the other day. Do you have multiple monitors attached? I see tearing
if I plug in another monitor on my development machine - which is
presumably X deciding it doesn't know which display to sync to.

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

On Tue, 22 Oct 2019 at 00:27, Tim Pletcher <pletchtd@gmail.com> wrote:
>
> I just gave the 2019-render branch (devel/2019-render v31-Pre-1095-gc7eabdaf86) a try on one of my frontend machines. The frontend is home-built Apollo Lake Celeron J3455 system running Xubuntu 18.04 with Vaapi version 1.10. The frontend is used almost exclusively for viewing NTSC LiveTV and the output is configured for a 1920x1080@59.94 modeline. The frontend is configured with a VAAPI2 profile with Vaapi acceleration and opengl-hw High quality deinterlacing.
>
> Everything works great with the exception of one issue:
> On 1920x1080i channels where deinterlacing is in use, any overlaid info flickers in the overlaid section in the top 1/4 or of the screen (see video here: https://youtu.be/PXospaUX1lo). The same flickering behavior is also observed if viewing a 1920x1080i@30fps recording so this doesn't appear unique to LiveTV. The overlay flickering is not present in any circumstance when viewing 1280x720@60 content where deinterlacing is not in use.
>
> To compare, I also tried the render branch on another machine with an Nvidia card (GT 1030 / driver version 390.116). Using VDPAU acceleration and opengl-hw deinterlacing on this frontend, the overlay flickering is not present with either interlaced or progressive content.
>
> Any hints on why I might be experiencing this with VAAPI acceleration on my Apollo Lake machine?

Tim,

Thanks for the video. Very helpful - though a curious issue.

This can only be a performance problem as the OSD is the last thing to
be displayed - certainly not a vsync problem as the video is fine. As
a sanity check can you possibly produce a log with "-v
playback,gpu,gpuvideo" logging.

Also worth going into the detail of the display profile page, if you
haven't done so already, and ensuring that you have everything setup
properly - as previously mentioned, the display profiles aren't
currently migrated completely. You'll need VAAPI acceleration then try
setting deinterlacers to high quality and enabling both shaders and
driver deints. If you still see the issue, try dropping the quality of
the deinterlacers.

Furthermore, again if you haven't tried it already, try to force EGL
from the command line - which gives much better VAAPI performance.
Something like:

QT_XCB_GL_INTEGRATION="xcb_egl" mythfrontend -v playback

I'm not sure how powerful that GPU is or what features it supports -
so it may be falling back to some basic VAAPI deinterlacing or OpenGL
shaders. Logs would confirm - or alternatively if you try a different
theme (e.g. MythCentre-wide) it will show which deinterlacer is in use
in the Debug OSD screen.

All that said, on reflection I think this is an OpenGL flushing issue.
Flushing is currently disabled - I'll add it back by default. I'm
pretty sure that will fix the problem.

Thanks and 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

On Tue, Oct 22, 2019 at 8:38 AM Mark Kendall <mark.kendall@gmail.com> wrote:

> On Tue, 22 Oct 2019 at 00:27, Tim Pletcher <pletchtd@gmail.com> wrote:
> >
> > I just gave the 2019-render branch (devel/2019-render
> v31-Pre-1095-gc7eabdaf86) a try on one of my frontend machines. The
> frontend is home-built Apollo Lake Celeron J3455 system running Xubuntu
> 18.04 with Vaapi version 1.10. The frontend is used almost exclusively for
> viewing NTSC LiveTV and the output is configured for a 1920x1080@59.94
> modeline. The frontend is configured with a VAAPI2 profile with Vaapi
> acceleration and opengl-hw High quality deinterlacing.
> >
> > Everything works great with the exception of one issue:
> > On 1920x1080i channels where deinterlacing is in use, any overlaid info
> flickers in the overlaid section in the top 1/4 or of the screen (see video
> here: https://youtu.be/PXospaUX1lo). The same flickering behavior is also
> observed if viewing a 1920x1080i@30fps recording so this doesn't appear
> unique to LiveTV. The overlay flickering is not present in any
> circumstance when viewing 1280x720@60 content where deinterlacing is not
> in use.
> >
> > To compare, I also tried the render branch on another machine with an
> Nvidia card (GT 1030 / driver version 390.116). Using VDPAU acceleration
> and opengl-hw deinterlacing on this frontend, the overlay flickering is not
> present with either interlaced or progressive content.
> >
> > Any hints on why I might be experiencing this with VAAPI acceleration on
> my Apollo Lake machine?
>
> Tim,
>
> Thanks for the video. Very helpful - though a curious issue.
>
> This can only be a performance problem as the OSD is the last thing to
> be displayed - certainly not a vsync problem as the video is fine. As
> a sanity check can you possibly produce a log with "-v
> playback,gpu,gpuvideo" logging.
>
> Also worth going into the detail of the display profile page, if you
> haven't done so already, and ensuring that you have everything setup
> properly - as previously mentioned, the display profiles aren't
> currently migrated completely. You'll need VAAPI acceleration then try
> setting deinterlacers to high quality and enabling both shaders and
> driver deints. If you still see the issue, try dropping the quality of
> the deinterlacers.
>
> Furthermore, again if you haven't tried it already, try to force EGL
> from the command line - which gives much better VAAPI performance.
> Something like:
>
> QT_XCB_GL_INTEGRATION="xcb_egl" mythfrontend -v playback
>
> I'm not sure how powerful that GPU is or what features it supports -
> so it may be falling back to some basic VAAPI deinterlacing or OpenGL
> shaders. Logs would confirm - or alternatively if you try a different
> theme (e.g. MythCentre-wide) it will show which deinterlacer is in use
> in the Debug OSD screen.
>
> All that said, on reflection I think this is an OpenGL flushing issue.
> Flushing is currently disabled - I'll add it back by default. I'm
> pretty sure that will fix the problem.
>
> Hi Mark,

Thank you for your response.

I tried the command you suggested to force EGL
(QT_XCB_GL_INTEGRATION="xcb_egl" mythfrontend) and that fixed the issue
entirely!

I also grabbed a couple of frontend logs with the suggested "-v
playback,gpu,gpuvideo" options and posted them here:
https://gist.github.com/pletch/eba2c199441604539b8627abdc48e219
Two logs are posted there with the first being a log captured with the EGL
force command line option on (no flickering) and a second without this
option (flickering present).

I'll use the force EGL option by default going forward.

Regards,
Tim