Mailing List Archive

Picture in Picture broken
Hi Mark,

Read something on the mailing list about the PIP not working in v30. I have
not used it myself for the last few years but I have tested this now on my
living room system with today's master and it is really broken.
What happens is that when the PIP is added the screen is updated about two
times per second.
This is both with live TV and with recordings or a combination.
This is both with VDPAU and NVDEC on 1080i recordings.
This also with ffmpeg decoding of SD recordings.
When trying to exchange the PIP with the main screen then the GUI is locked
and a "kill -9" of mythfrontend is needed.
I think this easy to reproduce but if not, I can make any amount of debug
log that you want.

Thanks,
Klaas.
Re: Picture in Picture broken [ In reply to ]
On 05/03/2020 18:45, Klaas de Waal wrote:
> Hi Mark,
>
> Read something on the mailing list about the PIP not working in v30. I
> have not used it myself for the last few years but I have tested this
> now on my living room system with today's master and it is really broken.
> What happens is that when the PIP is added the screen is updated about
> two times per second.
> This is both with live TV and with recordings or a combination.
> This is both with VDPAU and NVDEC on 1080i recordings.
> This also with ffmpeg decoding of SD recordings.
> When trying to exchange the PIP with the main screen then the GUI is
> locked and a "kill -9" of mythfrontend is needed.
> I think this easy to reproduce but if not, I can make any amount of
> debug log that you want.
>
> Thanks,
> Klaas.
>

Klass, did you test fixes/31 also?

It's pretty much the same code at this point, so I will assume it
is also affected until proven otherwise


Regards
Stuart
_______________________________________________
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: Picture in Picture broken [ In reply to ]
On Thu, 5 Mar 2020 at 20:43, Stuart Auchterlonie <stuarta@squashedfrog.net>
wrote:

> On 05/03/2020 18:45, Klaas de Waal wrote:
> > Hi Mark,
> >
> > Read something on the mailing list about the PIP not working in v30. I
> > have not used it myself for the last few years but I have tested this
> > now on my living room system with today's master and it is really broken.
> > What happens is that when the PIP is added the screen is updated about
> > two times per second.
> > This is both with live TV and with recordings or a combination.
> > This is both with VDPAU and NVDEC on 1080i recordings.
> > This also with ffmpeg decoding of SD recordings.
> > When trying to exchange the PIP with the main screen then the GUI is
> > locked and a "kill -9" of mythfrontend is needed.
> > I think this easy to reproduce but if not, I can make any amount of
> > debug log that you want.
> >
> > Thanks,
> > Klaas.
> >
>
> Klass, did you test fixes/31 also?
>
> It's pretty much the same code at this point, so I will assume it
> is also affected until proven otherwise
>
>
> Hi Stuart, Mark,

Tested it just now and the behavior on fixes/31 is the same as master.

Groetjes,
Klaas.
Re: Picture in Picture broken [ In reply to ]
On Thu, 5 Mar 2020 at 21:05, Klaas de Waal <klaas.de.waal@gmail.com> wrote:
>> > Read something on the mailing list about the PIP not working in v30. I
>> > have not used it myself for the last few years but I have tested this
>> > now on my living room system with today's master and it is really broken.
>> > What happens is that when the PIP is added the screen is updated about
>> > two times per second.

OK - what I'm seeing looks like a problem with the new A/V sync code.

When a PiP is added, A/V sync (for the main player) breaks and it
can't recover. This line repeats and repeats:-

2020-03-06 09:54:57.943347 I [17324/17324] CoreContext
mythplayer.cpp:1793:AVSync Player(0): Dropping frame: Video is behind
by 65ms

with the same 65ms.

A quick pause and unpause and everything is fine again.

>> > When trying to exchange the PIP with the main screen then the GUI is
>> > locked and a "kill -9" of mythfrontend is needed.

Yes - confirmed - though I think that may have been a problem for a while.

For what its worth, at some point I'm going to remove PiP support and
re-build it. The code is a horror show.

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: Picture in Picture broken [ In reply to ]
On 3/6/20 5:01 AM, Mark Kendall wrote:
> On Thu, 5 Mar 2020 at 21:05, Klaas de Waal <klaas.de.waal@gmail.com> wrote:
>>>> Read something on the mailing list about the PIP not working in v30. I
>>>> have not used it myself for the last few years but I have tested this
>>>> now on my living room system with today's master and it is really broken.
>>>> What happens is that when the PIP is added the screen is updated about
>>>> two times per second.
> OK - what I'm seeing looks like a problem with the new A/V sync code.
>
> When a PiP is added, A/V sync (for the main player) breaks and it
> can't recover. This line repeats and repeats:-
>
> 2020-03-06 09:54:57.943347 I [17324/17324] CoreContext
> mythplayer.cpp:1793:AVSync Player(0): Dropping frame: Video is behind
> by 65ms
>
> with the same 65ms.
>
> A quick pause and unpause and everything is fine again.
>
>>>> When trying to exchange the PIP with the main screen then the GUI is
>>>> locked and a "kill -9" of mythfrontend is needed.
> Yes - confirmed - though I think that may have been a problem for a while.
>
> For what its worth, at some point I'm going to remove PiP support and
> re-build it. The code is a horror show.
>
> Regards
>
> Mark
>

When I created the new avsync code I did not consider PIP. On my VDPAU
system, PIP was not working for many years, if I remember correctly I
would get major jerkiness in the main picture and the PIP would just
show wavy lines. It may have worked better with OpenGL at that time.

Peter
_______________________________________________
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: Picture in Picture broken [ In reply to ]
On Fri, 6 Mar 2020 at 14:10, Peter Bennett <pb.mythtv@gmail.com> wrote:

> When I created the new avsync code I did not consider PIP. On my VDPAU
> system, PIP was not working for many years, if I remember correctly I
> would get major jerkiness in the main picture and the PIP would just
> show wavy lines. It may have worked better with OpenGL at that time.

So I have a few local fixes that get Pip up and running again
(deinterlacing and av sync) - but I realised that the the PiP player
now plays at whatever rate the main player is using. (e.g. playing a
standard PAL recording as PiP while watching a 60fps video and the PiP
plays at over twice the expected rate). I'm not entirely sure how the
old av sync code dealt with that - but I'm assuming it is something to
do with its 'predictive' nature. I don't know if it is possible to do
the same with the new code.

Furthermore, the deadlocks when switching PiP windows are nasty. May
be a straightforward fix but I failed to track it down after several
hours of testing. There are also problems with Picture By Picture -
trying to create a PBP just exits playback.

Unless anyone has some startling insight or time to work on it, I
propose we disable PiP/PBP support in v31.

Thoughts?

Regards
Mark

PS.

Looking at the code over the last day or so has just re-affirmed to me
that it will be my next priority/target.

For those interested, we currently have three main classes involved in
playback TV, PlayerContext and MythPlayer. There is a huge amount of
complexity baked into TV and PlayerContext (and at lower levels) that
is purely driven by PiP/PBP support. Anyone who has ever worked on
that code will know how much locking goes on - all for PiP. The
PlayerContext class also largely exists purely to cater for PiP/PBP.

I want to get to the stage where we have only the TV and MythPlayer classes.

MythPlayer should be effectively standalone - i.e. give it a url, a
window and tell it to play.

All user interaction is then handled thought the TV class - it becomes
the UI interface layer and handles any 'forced' changes of state for
the player. It should then be a relatively simple task to wrap TV in a
new 'PlayerWidget' that embeds seamlessly into the main UI.

PiP/PBP would then be handled at the top level - i.e. just another widget.

Having the player as a UI item also opens up all sorts of possibilities.
_______________________________________________
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: Picture in Picture broken [ In reply to ]
On Sun, 8 Mar 2020 at 09:51, Mark Kendall <mark.kendall@gmail.com> wrote:

> On Fri, 6 Mar 2020 at 14:10, Peter Bennett <pb.mythtv@gmail.com> wrote:
>
> > When I created the new avsync code I did not consider PIP. On my VDPAU
> > system, PIP was not working for many years, if I remember correctly I
> > would get major jerkiness in the main picture and the PIP would just
> > show wavy lines. It may have worked better with OpenGL at that time.
>
> So I have a few local fixes that get Pip up and running again
> (deinterlacing and av sync) - but I realised that the the PiP player
> now plays at whatever rate the main player is using. (e.g. playing a
> standard PAL recording as PiP while watching a 60fps video and the PiP
> plays at over twice the expected rate). I'm not entirely sure how the
> old av sync code dealt with that - but I'm assuming it is something to
> do with its 'predictive' nature. I don't know if it is possible to do
> the same with the new code.
>
> Furthermore, the deadlocks when switching PiP windows are nasty. May
> be a straightforward fix but I failed to track it down after several
> hours of testing. There are also problems with Picture By Picture -
> trying to create a PBP just exits playback.
>
> Unless anyone has some startling insight or time to work on it, I
> propose we disable PiP/PBP support in v31.
>
> Thoughts?
>
> Regards
> Mark
>
> PS.
>
> Looking at the code over the last day or so has just re-affirmed to me
> that it will be my next priority/target.
>
> For those interested, we currently have three main classes involved in
> playback TV, PlayerContext and MythPlayer. There is a huge amount of
> complexity baked into TV and PlayerContext (and at lower levels) that
> is purely driven by PiP/PBP support. Anyone who has ever worked on
> that code will know how much locking goes on - all for PiP. The
> PlayerContext class also largely exists purely to cater for PiP/PBP.
>
> I want to get to the stage where we have only the TV and MythPlayer
> classes.
>
> MythPlayer should be effectively standalone - i.e. give it a url, a
> window and tell it to play.
>
> All user interaction is then handled thought the TV class - it becomes
> the UI interface layer and handles any 'forced' changes of state for
> the player. It should then be a relatively simple task to wrap TV in a
> new 'PlayerWidget' that embeds seamlessly into the main UI.
>
> PiP/PBP would then be handled at the top level - i.e. just another widget.
>
> Having the player as a UI item also opens up all sorts of possibilities.
>
>
About who is going to fix this, I cannot even get my head around the Live
TV code so I am not the one to fix the PiP.
I think it that missing the PiP is not a show stopper for v31 as it also
does not really work in v30 as reported in the forum.
However, it is a cool feature and it would be great if it worked again.
With my thinking not being limited by knowledge, this is how I imagined
that it should work.
- main window video playback is leading for timing and frame rates,
deinterlacing etc
- PiP stream renders into memory only. If this cannot be done with
hardware, due to hardware being in use for the main window, then this is
software-only.
- synchronized with main window refresh the current pip picture is copied
into the main window
If you mix 50Hz and 60Hz streams then the PiP will be not a smooth as the
main window. This is for me a corner case and I think the PiP timing should
be ignored.
Again not limited by knowledge, I do see some similarity between the OSD
and the PiP. The OSD is painted on top of the main window so maybe this can
also be done with the PiP.
If this is being rewritten it might also be a good idea to cater for
audio-only, i.e. DVB radio broadcast, which has also been broken for years.

Klaas.
Re: Picture in Picture broken [ In reply to ]
On Sun, 8 Mar 2020 at 16:28, Klaas de Waal <klaas.de.waal@gmail.com> wrote:
> About who is going to fix this, I cannot even get my head around the Live TV code so I am not the one to fix the PiP.
> I think it that missing the PiP is not a show stopper for v31 as it also does not really work in v30 as reported in the forum.
> However, it is a cool feature and it would be great if it worked again.
> With my thinking not being limited by knowledge, this is how I imagined that it should work.
> - main window video playback is leading for timing and frame rates, deinterlacing etc
> - PiP stream renders into memory only. If this cannot be done with hardware, due to hardware being in use for the main window, then this is software-only.
> - synchronized with main window refresh the current pip picture is copied into the main window

This is essentially how it should be working - though hardware
decoding in secondary players is disabled, as it is just too
unpredictable.

> If you mix 50Hz and 60Hz streams then the PiP will be not a smooth as the main window. This is for me a corner case and I think the PiP timing should be ignored.

Well this used to work. The old A/V sync code used the refresh rate of
the display - and in secondary players would effectively either decide
that it was too early for a new frame or drop frames as necessary (I
think). With the new code, the secondary players effectively follow
the main player.

That said, I've fixed the deadlock when swapping PiPs (had only been
there 3 years:) ).

There are still a few issues (other than the framerate). The second
player is not recreated when swapping PiPs when the pip has focus -
but is fine if the main player has focus. Picture By Picture is fairly
broken - looks to be mainly a positioning issue, both players are
running but showing fullscreen.

> Again not limited by knowledge, I do see some similarity between the OSD and the PiP. The OSD is painted on top of the main window so maybe this can also be done with the PiP.

The PiP is drawn just like the OSD. Essentially the rendering is
video, PiPs, visualisation and then OSD.

> If this is being rewritten it might also be a good idea to cater for audio-only, i.e. DVB radio broadcast, which has also been broken for years.

That should be working in master/v31 - various fixes went into the
render branch before the merge.

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: Picture in Picture broken [ In reply to ]
On Mon, 9 Mar 2020 at 11:16, Mark Kendall <mark.kendall@gmail.com> wrote:

> On Sun, 8 Mar 2020 at 16:28, Klaas de Waal <klaas.de.waal@gmail.com>
> wrote:
> > About who is going to fix this, I cannot even get my head around the
> Live TV code so I am not the one to fix the PiP.
> > I think it that missing the PiP is not a show stopper for v31 as it also
> does not really work in v30 as reported in the forum.
> > However, it is a cool feature and it would be great if it worked again.
> > With my thinking not being limited by knowledge, this is how I imagined
> that it should work.
> > - main window video playback is leading for timing and frame rates,
> deinterlacing etc
> > - PiP stream renders into memory only. If this cannot be done with
> hardware, due to hardware being in use for the main window, then this is
> software-only.
> > - synchronized with main window refresh the current pip picture is
> copied into the main window
>
> This is essentially how it should be working - though hardware
> decoding in secondary players is disabled, as it is just too
> unpredictable.
>
> > If you mix 50Hz and 60Hz streams then the PiP will be not a smooth as
> the main window. This is for me a corner case and I think the PiP timing
> should be ignored.
>
> Well this used to work. The old A/V sync code used the refresh rate of
> the display - and in secondary players would effectively either decide
> that it was too early for a new frame or drop frames as necessary (I
> think). With the new code, the secondary players effectively follow
> the main player.
>
> That said, I've fixed the deadlock when swapping PiPs (had only been
> there 3 years:) ).
>
> There are still a few issues (other than the framerate). The second
> player is not recreated when swapping PiPs when the pip has focus -
> but is fine if the main player has focus. Picture By Picture is fairly
> broken - looks to be mainly a positioning issue, both players are
> running but showing fullscreen.
>
> > Again not limited by knowledge, I do see some similarity between the OSD
> and the PiP. The OSD is painted on top of the main window so maybe this can
> also be done with the PiP.
>
> The PiP is drawn just like the OSD. Essentially the rendering is
> video, PiPs, visualisation and then OSD.
>
> > If this is being rewritten it might also be a good idea to cater for
> audio-only, i.e. DVB radio broadcast, which has also been broken for years.
>
> That should be working in master/v31 - various fixes went into the
> render branch before the merge.
>
> About the PiPs. Tested this right now with the latest master. Huge
improvement! I can now have live TV in the main window and four PiPs from
recordings and it all plays OK. Exchanging PiP and main window does stilll
lock, both with focus on the PiP and focus on the main screen.
When I start with playing a recording in the main window and then start a
PiP with live TV then this works OK but the screen is frozen for a few
seconds when the live TV is starting up. After it has started to move again
playback of the recording is still stuttering for maybe two seconds until
it is smooth again.

About the DVB radio, recordings work fine but "Live TV" radio is not,
unless you have fixed it recently. See ticket #13156. Will test that later.
The problem with the "Live TV" radio is that the system creates dummy video
frames so that it can be treated as regular TV but it then has huge
problems with synchronization between the audio and the dummy video. This
is the code that I spent more time on that I want to admit before bailing
out....

Groetjes,
Klaas.
Re: Picture in Picture broken [ In reply to ]
On Mon, 9 Mar 2020 at 18:13, Klaas de Waal <klaas.de.waal@gmail.com> wrote:
> About the PiPs. Tested this right now with the latest master. Huge improvement! I can now have live TV in the main window and four PiPs from recordings and it all plays OK. Exchanging PiP and main window does stilll lock, both with focus on the PiP and focus on the main screen.

Seems to be intermittent - I've only had it lock up once since I
thought I'd fixed it - though may be more livetv related.

> When I start with playing a recording in the main window and then start a PiP with live TV then this works OK but the screen is frozen for a few seconds when the live TV is starting up. After it has started to move again playback of the recording is still stuttering for maybe two seconds until it is smooth again.

Unfortunately this is expected behaviour. The UI thread blocks until
the new player is setup - which will then throw out av sync for the
main player as well.

> About the DVB radio, recordings work fine but "Live TV" radio is not, unless you have fixed it recently. See ticket #13156. Will test that later.

I tested with live tv this morning before I replied and it seemed to
be working OK.

> The problem with the "Live TV" radio is that the system creates dummy video frames so that it can be treated as regular TV but it then has huge problems with synchronization between the audio and the dummy video. This is the code that I spent more time on that I want to admit before bailing out....

Yep - I hope to get rid of that at some point. The underlying problem
is that the player was originally written with video first and
foremost - audio only (and MHEG only) isn't well catered for.

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: Picture in Picture broken [ In reply to ]
So I've pushed a number of updates to master - nothing in fixes/31 just yet.

In summary:-

- PiP should be working
- only the main player will use hardware decoding - all PiPs will use
software decoding (and this is enforced when swapping PiPs - so it
will always be the main player that uses hardware decoding).
- PiPs have a new sync method that should ensure PiP plays at correct
rate - regardless of the main player's frame rate.
- there is still a remote possibility of locking up the frontend when
using hardware decoding. One of the newer updates attempts to
catch/prevent decoder deadlocks but it simply cannot catch all cases.
That said in the testing I've done over the last few days, I've failed
to trigger a deadlock again. A complete fix requires some significant
surgery to the decoder code - the use of the global, static
avcodeclock mutex is the problem.

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: Picture in Picture broken [ In reply to ]
On Wed, 11 Mar 2020 at 12:12, Mark Kendall <mark.kendall@gmail.com> wrote:

> So I've pushed a number of updates to master - nothing in fixes/31 just
> yet.
>
> In summary:-
>
> - PiP should be working
> - only the main player will use hardware decoding - all PiPs will use
> software decoding (and this is enforced when swapping PiPs - so it
> will always be the main player that uses hardware decoding).
> - PiPs have a new sync method that should ensure PiP plays at correct
> rate - regardless of the main player's frame rate.
> - there is still a remote possibility of locking up the frontend when
> using hardware decoding. One of the newer updates attempts to
> catch/prevent decoder deadlocks but it simply cannot catch all cases.
> That said in the testing I've done over the last few days, I've failed
> to trigger a deadlock again. A complete fix requires some significant
> surgery to the decoder code - the use of the global, static
> avcodeclock mutex is the problem.
>
>
> Getting better all the time... having had a quick test drive with the
latest as of time of writing.
- Main window plays recording, start PIP with recording, is OK
- Main window plays Live TV, start PIP with recording, is OK
- Main window plays recording, start PIP with Live TV, then:
- Stuttering!!
- Solved by doing Pause: then the Live TV in PIP is paused and main
window plays OK
- Unpausing then LIve TV in PIP plays OK.
- Exchanging PIP and main window: hangs/locks about 30% of the time.

HTH,
Klaas.
Re: Picture in Picture broken [ In reply to ]
On Wed, 11 Mar 2020 at 16:21, Klaas de Waal <klaas.de.waal@gmail.com> wrote:

> Getting better all the time... having had a quick test drive with the latest as of time of writing.
> - Main window plays recording, start PIP with recording, is OK
> - Main window plays Live TV, start PIP with recording, is OK
> - Main window plays recording, start PIP with Live TV, then:
> - Stuttering!!
> - Solved by doing Pause: then the Live TV in PIP is paused and main window plays OK
> - Unpausing then LIve TV in PIP plays OK.

OK - I think I know what is happening here - should be a simple fix.

> - Exchanging PIP and main window: hangs/locks about 30% of the time.

What hardware decoder are you using?

Can you get a backtrace when it is locking up? If it is the same issue
I was seeing, then it clearly isn't fixed properly - and 30% is not
really acceptable:) - and we may need to disable PiP for the release.

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
Re: Picture in Picture broken [ In reply to ]
On Wed, 11 Mar 2020 at 18:43, Mark Kendall <mark.kendall@gmail.com> wrote:

> On Wed, 11 Mar 2020 at 16:21, Klaas de Waal <klaas.de.waal@gmail.com>
> wrote:
>
> > Getting better all the time... having had a quick test drive with the
> latest as of time of writing.
> > - Main window plays recording, start PIP with recording, is OK
> > - Main window plays Live TV, start PIP with recording, is OK
> > - Main window plays recording, start PIP with Live TV, then:
> > - Stuttering!!
> > - Solved by doing Pause: then the Live TV in PIP is paused and main
> window plays OK
> > - Unpausing then LIve TV in PIP plays OK.
>
> OK - I think I know what is happening here - should be a simple fix.
>
> > - Exchanging PIP and main window: hangs/locks about 30% of the time.
>
> What hardware decoder are you using?
>
> Can you get a backtrace when it is locking up? If it is the same issue
> I was seeing, then it clearly isn't fixed properly - and 30% is not
> really acceptable:) - and we may need to disable PiP for the release.
>
>
> Report from this afternoon was from the living room frontend, with Nvidia
VDPAU graphics. This has the 30% hang/lock performance.

Tested now on my development system, frontend/backend combined, i7-7700, no
graphics card.
System status / Video Decoders shows: nothing at all.
Selected OpenGL (or a variant) for video profile.
Here the PIP/main window exchange is always correct. Repeat: no hanging!!

Tested on backend system which also has a display, so frontend/backend
combined, i5-650, no graphics card.
System status / Video Decoders shows: VAAPI.
Selected OpenGL (or a variant) for video profile.
Here the PIP/main window exchange always hangs. Repeat: lock on all
attempts to exchange.
From this I have made a gdb backtrace which is attached.
Also: after the PIP is started (main window plays recording, PIP plays
recording) display is a bit stuttering AND about twice per second there are
four new threads and four threads exiting. Hence the high thread number in
the traceback.

HTH,
Klaas.
Re: Picture in Picture broken [ In reply to ]
On 11/03/2020 20:11, Klaas de Waal wrote:
>
>
> On Wed, 11 Mar 2020 at 18:43, Mark Kendall <mark.kendall@gmail.com
> <mailto:mark.kendall@gmail.com>> wrote:
>
> On Wed, 11 Mar 2020 at 16:21, Klaas de Waal <klaas.de.waal@gmail.com
> <mailto:klaas.de.waal@gmail.com>> wrote:
>
> > Getting better all the time... having had a quick test drive with
> the latest as of time of writing.
> > - Main window plays recording, start PIP with recording, is OK
> > - Main window plays Live TV, start PIP with recording, is OK
> > - Main window plays recording, start PIP with Live TV, then:
> >   - Stuttering!!
> >   - Solved by doing Pause: then the Live TV in PIP is paused and
> main window plays OK
> >   - Unpausing then LIve TV in PIP plays OK.
>
> OK - I think I know what is happening here - should be a simple fix.
>
> > - Exchanging PIP and main window: hangs/locks about 30% of the time.
>
> What hardware decoder are you using?
>
> Can you get a backtrace when it is locking up? If it is the same issue
> I was seeing, then it clearly isn't fixed properly - and 30% is not
> really acceptable:) - and we may need to disable PiP for the release.
>
>
> Report from this afternoon was from the living room frontend, with
> Nvidia VDPAU graphics. This has the 30% hang/lock performance.
>
> Tested now on my development system, frontend/backend combined, i7-7700,
> no graphics card.
> System status / Video Decoders shows: nothing at all.
> Selected OpenGL (or a variant) for video profile.
> Here the PIP/main window exchange is always correct. Repeat: no hanging!!
>
> Tested on backend system which also has a display, so frontend/backend
> combined, i5-650, no graphics card.
> System status / Video Decoders shows: VAAPI.
> Selected OpenGL (or a variant) for video profile.
> Here the PIP/main window exchange always hangs. Repeat: lock on all
> attempts to exchange.
> From this I have made a gdb backtrace which is attached.
> Also: after the PIP is started (main window plays recording, PIP plays
> recording) display is a bit stuttering AND about twice per second there
> are four new threads and four threads exiting. Hence the high thread
> number in the traceback.
>
> HTH,
> Klaas.
>

It seems to be working adequately for me at 625fc71, with live tv in the
small window while playing a recording in the big one. It stutters on
enabling the live tv, and the initial OSD is is intrusive, but a quick
pause-and-resume gives good playback in both. Main problem for me is
unfamiliarity with the keyboard options. It's easy to imagine getting
into problems but so far I haven't. el7 system, all ffmpeg, 2 x 2.7
GHz, SD only.

John P
_______________________________________________
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: Picture in Picture broken [ In reply to ]
On Wed, 11 Mar 2020 at 20:11, Klaas de Waal <klaas.de.waal@gmail.com> wrote:

> Here the PIP/main window exchange always hangs. Repeat: lock on all attempts to exchange.
> From this I have made a gdb backtrace which is attached.

OK - plan A is not going to work.

The more I looked at the threading issues, the more problems I saw and
the more deadlocks I could trigger... and no amount of tweaking will
fix it.

So onto plan B.

I've disabled PiP in v31, reverted some of the attempts to fix the
deadlocks and started to sanitise some of the locking in the decoder
classes.

I have 2 more patches, that will probably go in tomorrow morning, that
factor out the most significant global, static locks in the codebase.

While I am pretty comfortable with these patches and they are not at
face value too complicated, they do make some fundamental changes to
decoding of ALL media - not just PiP.

So volunteers welcome for some heavy duty testing in the next few days
- otherwise the code is unlikely to make v31.

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: Picture in Picture broken [ In reply to ]
On Fri, 13 Mar 2020 at 23:35, Mark Kendall <mark.kendall@gmail.com> wrote:

> On Wed, 11 Mar 2020 at 20:11, Klaas de Waal <klaas.de.waal@gmail.com>
> wrote:
>
> > Here the PIP/main window exchange always hangs. Repeat: lock on all
> attempts to exchange.
> > From this I have made a gdb backtrace which is attached.
>
> OK - plan A is not going to work.
>
> The more I looked at the threading issues, the more problems I saw and
> the more deadlocks I could trigger... and no amount of tweaking will
> fix it.
>
> So onto plan B.
>
> I've disabled PiP in v31, reverted some of the attempts to fix the
> deadlocks and started to sanitise some of the locking in the decoder
> classes.
>
> I have 2 more patches, that will probably go in tomorrow morning, that
> factor out the most significant global, static locks in the codebase.
>
> While I am pretty comfortable with these patches and they are not at
> face value too complicated, they do make some fundamental changes to
> decoding of ALL media - not just PiP.
>
> So volunteers welcome for some heavy duty testing in the next few days
> - otherwise the code is unlikely to make v31.
>
>
> Quick test with the latest as of this morning.

Good news: exchanging PIP and main windows is OK, also with live TV.

Bad news: Playback is failing on 60Hz HD content (1080 interlaced), it just
freezes after a few frames.
This uses VDPAU for decoding. Last page of the log is here.
Playback of 60Hz SD content is OK but that is decoded with ffmpeg.
Playback of local broadcast 50Hz content (1080 interlaced) is OK, both
live and recordings. With VDPAU
--- last page of mythfrontend.log -----------
Mar 15 10:41:29 myth3 mythfrontend: mythfrontend[1647]: I CoreContext
opengl/mythopenglinterop.cpp:159 (GetInteropType) OpenGLInterop: Rendering
supported for frame type 'VDPAU' with VDPAU
Mar 15 10:41:29 myth3 mythfrontend: mythfrontend[1647]: I CoreContext
opengl/mythpainteropengl.cpp:74 (ClearCache) Clearing OpenGL painter cache.
Mar 15 10:41:29 myth3 mythfrontend: mythfrontend[1647]: I CoreContext
mythdisplay.cpp:669 (SwitchToVideo) Display: Using current mode
1920x1080@59.9394Hz
Mar 15 10:41:29 myth3 mythfrontend: mythfrontend[1647]: I CoreContext
mythvideoout.cpp:394 (SetDeinterlacing) VideoOutput: SetDeinterlacing
(Doublerate 1): Single High|CPU|GLSL|DRIVER Double High|CPU|GLSL|DRIVER
Mar 15 10:41:29 myth3 mythfrontend: mythfrontend[1647]: I CoreContext
tv_play.cpp:5702 (StartPlayer) TV::StartPlayer(): Created player.
Mar 15 10:41:29 myth3 mythfrontend: mythfrontend[1647]: I CoreContext
tv_play.cpp:2398 (HandleStateChange) TV::HandleStateChange(): Changing from
None to WatchingVideo
Mar 15 10:41:29 myth3 mythfrontend: mythfrontend[1647]: I Decoder
mythplayer.cpp:3122 (QueueCallback) Player(a): Queuing callback for VDPAU
context creation
Mar 15 10:41:29 myth3 mythfrontend: mythfrontend[1647]: I CoreContext
tv_play.cpp:2484 (HandleStateChange) TV::HandleStateChange(): Main UI
disabled.
Mar 15 10:41:29 myth3 mythfrontend: mythfrontend[1647]: I CoreContext
tv_play.cpp:391 (StartTV) TV::StartTV(): Entering main playback loop.
Mar 15 10:41:29 myth3 mythfrontend: mythfrontend[1647]: I CoreContext
mythplayer.cpp:3110 (ProcessCallbacks) Player(a): Executing VDPAU context
creation
Mar 15 10:41:29 myth3 mythfrontend: mythfrontend[1647]: I CoreContext
opengl/mythopenglinterop.cpp:159 (GetInteropType) OpenGLInterop: Rendering
supported for frame type 'VDPAU' with VDPAU
Mar 15 10:41:29 myth3 mythfrontend: mythfrontend[1647]: I CoreContext
mythvideoout.cpp:394 (SetDeinterlacing) VideoOutput: SetDeinterlacing
(Doublerate 1): Single High|CPU|GLSL|DRIVER Double High|CPU|GLSL|DRIVER
Mar 15 10:41:29 myth3 mythfrontend: mythfrontend[1647]: W CoreContext
opengl/mythopenglvideo.cpp:516 (SetupFrameFormat) GLVid: New frame format:
None:None 1920x1080 (Tex: 2D) -> VDPAU:ARGB32 1920x1080 (Tex: 2D)
Mar 15 10:41:33 myth3 mythfrontend: mythfrontend[1647]: N CoreContext
mythplayer.cpp:2025 (PrebufferEnoughFrames) Player(a): Waited 101ms for
video buffers AAAAAAAAAAALLp
Mar 15 10:41:34 myth3 mythfrontend: mythfrontend[1647]: N CoreContext
mythplayer.cpp:2025 (PrebufferEnoughFrames) Player(a): Waited 203ms for
video buffers AAAAAAAAAAALLp
Mar 15 10:41:34 myth3 mythfrontend: mythfrontend[1647]: N CoreContext
mythplayer.cpp:2025 (PrebufferEnoughFrames) Player(a): Waited 304ms for
video buffers AAAAAAAAAAALLp
Mar 15 10:41:34 myth3 mythfrontend: mythfrontend[1647]: N CoreContext
mythplayer.cpp:2025 (PrebufferEnoughFrames) Player(a): Waited 406ms for
video buffers AAAAAAAAAAALLp
Mar 15 10:41:34 myth3 mythfrontend: mythfrontend[1647]: N CoreContext
mythplayer.cpp:2025 (PrebufferEnoughFrames) Player(a): Waited 507ms for
video buffers AAAAAAAAAAALLp
Mar 15 10:41:34 myth3 mythfrontend: mythfrontend[1647]: N CoreContext
mythplayer.cpp:2025 (PrebufferEnoughFrames) Player(a): Waited 609ms for
video buffers AAAAAAAAAAALLp
Mar 15 10:41:34 myth3 mythfrontend: mythfrontend[1647]: N CoreContext
mythplayer.cpp:2025 (PrebufferEnoughFrames) Player(a): Waited 710ms for
video buffers AAAAAAAAAAALLp
Mar 15 10:41:34 myth3 mythfrontend: mythfrontend[1647]: N CoreContext
mythplayer.cpp:2025 (PrebufferEnoughFrames) Player(a): Waited 812ms for
video buffers AAAAAAAAAAALLp
Mar 15 10:41:34 myth3 mythfrontend: mythfrontend[1647]: N CoreContext
mythplayer.cpp:2025 (PrebufferEnoughFrames) Player(a): Waited 913ms for
video buffers AAAAAAAAAAALLp
Mar 15 10:41:34 myth3 mythfrontend: mythfrontend[1647]: N CoreContext
mythplayer.cpp:2014 (PrebufferEnoughFrames) Player(a): To see more
buffering messages use -v playback
Mar 15 10:42:03 myth3 mythfrontend: mythfrontend[1647]: E CoreContext
mythplayer.cpp:2072 (PrebufferEnoughFrames) Player(a): Waited too long for
decoder to fill video buffers. Exiting..
Mar 15 10:42:03 myth3 mythfrontend: mythfrontend[1647]: I CoreContext
tv_play.cpp:2146 (HandleStateChange) TV::HandleStateChange(): Attempting to
change from WatchingVideo to None
Mar 15 10:42:04 myth3 mythfrontend: mythfrontend[1647]: W CoreContext
mythplayer.cpp:3144 (PauseDecoder) Player(a): Waited 100ms for decoder to
pause
Mar 15 10:42:19 myth3 mythfrontend: mythfrontend[1647]: E CoreContext
mythplayer.cpp:3211 (DecoderEnd) Player(a): Failed to stop decoder loop.
Mar 15 10:42:19 myth3 mythfrontend: mythfrontend[1647]: I CoreContext
mythplayer.cpp:5426 (SetDecoder) Player(a): Waited 10ms for decoder lock
^C
---- end of log ----------

I can generate any amount of logs needed but probably you know already what
is happening...

Groetjes,
Klaas.
Re: Picture in Picture broken [ In reply to ]
On Sun, 15 Mar 2020 at 09:58, Klaas de Waal <klaas.de.waal@gmail.com> wrote:
> Quick test with the latest as of this morning.
>
> Good news: exchanging PIP and main windows is OK, also with live TV.
>
> Bad news: Playback is failing on 60Hz HD content (1080 interlaced), it just freezes after a few frames.

Klass,

Thanks for testing. I do have another commit in the pipeline but I
don't think it is relevant here.

Can you get generate a backtrace when it locks up?

Thanks again 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
Re: Picture in Picture broken [ In reply to ]
On Sun, 15 Mar 2020 at 11:56, Mark Kendall <mark.kendall@gmail.com> wrote:

> On Sun, 15 Mar 2020 at 09:58, Klaas de Waal <klaas.de.waal@gmail.com>
> wrote:
> > Quick test with the latest as of this morning.
> >
> > Good news: exchanging PIP and main windows is OK, also with live TV.
> >
> > Bad news: Playback is failing on 60Hz HD content (1080 interlaced), it
> just freezes after a few frames.
>
> Klass,
>
> Thanks for testing. I do have another commit in the pipeline but I
> don't think it is relevant here.
>
> Can you get generate a backtrace when it locks up?
>
>
> As requested, a backtrace when locked and also a "-v playback" from a
previous run two minutes before with the same video file.
This is on the development machine with i7-7700 intel-only hardware, so no
Nvidia. Issue is exactly the same.

FYI also: have been experimenting with the PIPs on both machines and it
looks really good.No problems found, not even with multiple PIPs and mixing
live TV and recordings.

Groetjes,
Klaas.
Re: Picture in Picture broken [ In reply to ]
On Sun, 15 Mar 2020 at 14:42, Klaas de Waal <klaas.de.waal@gmail.com> wrote:

>
>
> On Sun, 15 Mar 2020 at 11:56, Mark Kendall <mark.kendall@gmail.com> wrote:
>
>> On Sun, 15 Mar 2020 at 09:58, Klaas de Waal <klaas.de.waal@gmail.com>
>> wrote:
>> > Quick test with the latest as of this morning.
>> >
>> > Good news: exchanging PIP and main windows is OK, also with live TV.
>> >
>> > Bad news: Playback is failing on 60Hz HD content (1080 interlaced), it
>> just freezes after a few frames.
>>
>> Klass,
>>
>> Thanks for testing. I do have another commit in the pipeline but I
>> don't think it is relevant here.
>>
>> Can you get generate a backtrace when it locks up?
>>
>>
>> As requested, a backtrace when locked and also a "-v playback" from a
> previous run two minutes before with the same video file.
> This is on the development machine with i7-7700 intel-only hardware, so no
> Nvidia. Issue is exactly the same.
>
> FYI also: have been experimenting with the PIPs on both machines and it
> looks really good.No problems found, not even with multiple PIPs and mixing
> live TV and recordings.
>
>
On the third machine, my living room backend (i5-650 intel-only so no
Nvidia) the PIP has sometimes issues (but not always).
Attached is a "-v playback" log made with the following sequence:
- Start mythfrontend
- Start live TV
- Live TV plays OK
- Start PIP from recording
- Main window with Live TV now stutters
- Exchange PIP and Main window
- Main window with playback of recording now stutters.
- Exit
The log shows that it creates and removes a deinterlacer twice per second.
N.B. Closing the PIP restores correct playback in the main window.

HTH & Groetjes,
Klaas.
Re: Picture in Picture broken [ In reply to ]
On Sun, 15 Mar 2020 at 15:19, Jan Ceuleers <jan.ceuleers@computer.org>
wrote:

> On 15/03/2020 15:10, Klaas de Waal wrote:
>
>
>
> On Sun, 15 Mar 2020 at 14:42, Klaas de Waal <klaas.de.waal@gmail.com>
> wrote:
>
>>
>>
>> On Sun, 15 Mar 2020 at 11:56, Mark Kendall <mark.kendall@gmail.com>
>> wrote:
>>
>>> On Sun, 15 Mar 2020 at 09:58, Klaas de Waal <klaas.de.waal@gmail.com>
>>> wrote:
>>> > Quick test with the latest as of this morning.
>>> >
>>> > Good news: exchanging PIP and main windows is OK, also with live TV.
>>> >
>>> > Bad news: Playback is failing on 60Hz HD content (1080 interlaced), it
>>> just freezes after a few frames.
>>>
>>> Klass,
>>>
>>> Thanks for testing. I do have another commit in the pipeline but I
>>> don't think it is relevant here.
>>>
>>> Can you get generate a backtrace when it locks up?
>>>
>>>
>>> As requested, a backtrace when locked and also a "-v playback" from a
>> previous run two minutes before with the same video file.
>> This is on the development machine with i7-7700 intel-only hardware, so
>> no Nvidia. Issue is exactly the same.
>>
>> FYI also: have been experimenting with the PIPs on both machines and it
>> looks really good.No problems found, not even with multiple PIPs and mixing
>> live TV and recordings.
>>
>>
> On the third machine, my living room backend (i5-650 intel-only so no
> Nvidia) the PIP has sometimes issues (but not always).
> Attached is a "-v playback" log made with the following sequence:
> - Start mythfrontend
> - Start live TV
> - Live TV plays OK
> - Start PIP from recording
> - Main window with Live TV now stutters
> - Exchange PIP and Main window
> - Main window with playback of recording now stutters.
> - Exit
> The log shows that it creates and removes a deinterlacer twice per second.
> N.B. Closing the PIP restores correct playback in the main window.
>
> HTH & Groetjes,
> Klaas.
>
>
> Klaas,
>
> Attachment vergeten?
>
>
> Oeps.... and now the attachment................

Groetjes,
Klaas.
Re: Picture in Picture broken [ In reply to ]
On Sun, 15 Mar 2020 at 14:26, Klaas de Waal <klaas.de.waal@gmail.com> wrote:

>>> As requested, a backtrace when locked and also a "-v playback" from a previous run two minutes before with the same video file.
>>> This is on the development machine with i7-7700 intel-only hardware, so no Nvidia. Issue is exactly the same.

Thanks Klaas - that should be fixed.

>> On the third machine, my living room backend (i5-650 intel-only so no Nvidia) the PIP has sometimes issues (but not always).
>> Attached is a "-v playback" log made with the following sequence:

The problem here is it gets into a bit of a vicious circle - mostly
performance related.

The main player is using software decode for 1080i H264, with Yadif
CPU deinterlacer at double rate and your are using opengl rather than
opengl-yv12 for rendering. So there is a lot of cpu load.

Add a PiP player and it loses sync/can't keep up, frames are skipped,
the deinterlacer has to be deleted and recreated. Repeat. Repeat...

I would try one or more of:-

- use VAAPI decoding (from memory, Ironlake does not have VAAPI
deinterlacing, so you would need to use OpenGL for deinterlacing)
- switch to the medium quality CPU deinterlacer (much lower load and
it does not have to be recreated when frames are dropped)
- try deinterlacing in the shader/opengl.
- switch to OpenGL-YV12 renderer.

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: Picture in Picture broken [ In reply to ]
On Sun, 15 Mar 2020 at 15:41, Mark Kendall <mark.kendall@gmail.com> wrote:

> On Sun, 15 Mar 2020 at 14:26, Klaas de Waal <klaas.de.waal@gmail.com>
> wrote:
>
> >>> As requested, a backtrace when locked and also a "-v playback" from a
> previous run two minutes before with the same video file.
> >>> This is on the development machine with i7-7700 intel-only hardware,
> so no Nvidia. Issue is exactly the same.
>
> Thanks Klaas - that should be fixed.
>
> >> On the third machine, my living room backend (i5-650 intel-only so no
> Nvidia) the PIP has sometimes issues (but not always).
> >> Attached is a "-v playback" log made with the following sequence:
>
> The problem here is it gets into a bit of a vicious circle - mostly
> performance related.
>
> The main player is using software decode for 1080i H264, with Yadif
> CPU deinterlacer at double rate and your are using opengl rather than
> opengl-yv12 for rendering. So there is a lot of cpu load.
>
> Add a PiP player and it loses sync/can't keep up, frames are skipped,
> the deinterlacer has to be deleted and recreated. Repeat. Repeat...
>
> I would try one or more of:-
>
> - use VAAPI decoding (from memory, Ironlake does not have VAAPI
> deinterlacing, so you would need to use OpenGL for deinterlacing)
> - switch to the medium quality CPU deinterlacer (much lower load and
> it does not have to be recreated when frames are dropped)
> - try deinterlacing in the shader/opengl.
> - switch to OpenGL-YV12 renderer.
>
>
> About the 60Hz videos: I confirm they do play correct now with the
"adb7a7: AvFormatDecoder: Fix a decoder lockup" in place.
About the PIP on the i650: changing the video profile to "Normal" and
"OpenGL YV12" the PIPs are OK on this machine as well.
So for me all is OK now.

Thanks,
Klaas.