Mailing List Archive

On Tue, Feb 12, 2019 at 11:01:19AM -0500, Peter Bennett wrote:
> I have been using the latest patch https://code.mythtv.org/trac/attachment/ticket/13383/20190208_1644_catchup_plus.patch
> for a couple of days and it looks good now.
>
> Mark- you said you may have some improvements - I plan to commit it anyway
> and those can always be done afterwards.
>
> You said that making the wait into a series of short waits may improve
> things. Currently on a desktop system everything is between -5 and +5 ms so
> I don't know if much improvement is possible. Also on thinking about it I
> don't know how that would help, if the operating system is going to delay
> resuming a process on one wait, would it be less likely to delay it on a
> bunch of smaller waits?
>
> If I don't hear anything back I will commit that patch to master and
> fixes/30.

Peter,

Perhaps you must have missed my report on IRC. The 0208 patch causes
problems with live TV. When starting live TV or changing channels,
playback stutters badly until it is briefly paused or skipped back. I
don't know if earlier patches did this since I didn't test them on
live TV.

David
--
David Engel
david@istwok.net
_______________________________________________
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, Feb 12, 2019 at 10:31 AM David Engel <david@istwok.net> wrote:

> On Tue, Feb 12, 2019 at 11:01:19AM -0500, Peter Bennett wrote:
> > I have been using the latest patch
> https://code.mythtv.org/trac/attachment/ticket/13383/20190208_1644_catchup_plus.patch
> > for a couple of days and it looks good now.
> >
> > Mark- you said you may have some improvements - I plan to commit it
> anyway
> > and those can always be done afterwards.
> >
> > You said that making the wait into a series of short waits may improve
> > things. Currently on a desktop system everything is between -5 and +5 ms
> so
> > I don't know if much improvement is possible. Also on thinking about it I
> > don't know how that would help, if the operating system is going to delay
> > resuming a process on one wait, would it be less likely to delay it on a
> > bunch of smaller waits?
> >
> > If I don't hear anything back I will commit that patch to master and
> > fixes/30.
>
> Peter,
>
> Perhaps you must have missed my report on IRC. The 0208 patch causes
> problems with live TV. When starting live TV or changing channels,
> playback stutters badly until it is briefly paused or skipped back. I
> don't know if earlier patches did this since I didn't test them on
> live TV.
>

I have not had a chance to try the last couple of patch candidates. For
me, that Live TV issue is "long standing" and seems to depend on the source
material -- mpeg2 is fine, but H.264 with large key-frame distance has that
behavior. In other words, the new avsync does not 'create' that problem,
at least for me.

John

On 2/12/19 12:31 PM, David Engel wrote:
> On Tue, Feb 12, 2019 at 11:01:19AM -0500, Peter Bennett wrote:
>> I have been using the latest patch https://code.mythtv.org/trac/attachment/ticket/13383/20190208_1644_catchup_plus.patch
>> for a couple of days and it looks good now.
>>
>> Mark- you said you may have some improvements - I plan to commit it anyway
>> and those can always be done afterwards.
>>
>> You said that making the wait into a series of short waits may improve
>> things. Currently on a desktop system everything is between -5 and +5 ms so
>> I don't know if much improvement is possible. Also on thinking about it I
>> don't know how that would help, if the operating system is going to delay
>> resuming a process on one wait, would it be less likely to delay it on a
>> bunch of smaller waits?
>>
>> If I don't hear anything back I will commit that patch to master and
>> fixes/30.
> Peter,
>
> Perhaps you must have missed my report on IRC. The 0208 patch causes
> problems with live TV. When starting live TV or changing channels,
> playback stutters badly until it is briefly paused or skipped back. I
> don't know if earlier patches did this since I didn't test them on
> live TV.
>
> David
Yes - i missed that. I will look into it and fix it. Thanks for letting
me know.

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

On Tue, Feb 12, 2019 at 10:56:31AM -0700, John P Poet wrote:
> On Tue, Feb 12, 2019 at 10:31 AM David Engel <david@istwok.net> wrote:
>
> > On Tue, Feb 12, 2019 at 11:01:19AM -0500, Peter Bennett wrote:
> > > I have been using the latest patch
> > https://code.mythtv.org/trac/attachment/ticket/13383/20190208_1644_catchup_plus.patch
> > > for a couple of days and it looks good now.
> > >
> > > Mark- you said you may have some improvements - I plan to commit it
> > anyway
> > > and those can always be done afterwards.
> > >
> > > You said that making the wait into a series of short waits may improve
> > > things. Currently on a desktop system everything is between -5 and +5 ms
> > so
> > > I don't know if much improvement is possible. Also on thinking about it I
> > > don't know how that would help, if the operating system is going to delay
> > > resuming a process on one wait, would it be less likely to delay it on a
> > > bunch of smaller waits?
> > >
> > > If I don't hear anything back I will commit that patch to master and
> > > fixes/30.
> >
> > Peter,
> >
> > Perhaps you must have missed my report on IRC. The 0208 patch causes
> > problems with live TV. When starting live TV or changing channels,
> > playback stutters badly until it is briefly paused or skipped back. I
> > don't know if earlier patches did this since I didn't test them on
> > live TV.
> >
>
> I have not had a chance to try the last couple of patch candidates. For
> me, that Live TV issue is "long standing" and seems to depend on the source
> material -- mpeg2 is fine, but H.264 with large key-frame distance has that
> behavior. In other words, the new avsync does not 'create' that problem,
> at least for me.

In my experience, it used to be an issue but hasn't been since v30 and
the already committed avsync2. Playback syncs up fairly quickly now
(without the current patch) whereas before it could take minutes to
sync up.

David
--
David Engel
david@istwok.net
_______________________________________________
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, Feb 12, 2019 at 12:57:59PM -0500, Peter Bennett wrote:
>
>
> On 2/12/19 12:31 PM, David Engel wrote:
> > On Tue, Feb 12, 2019 at 11:01:19AM -0500, Peter Bennett wrote:
> > > I have been using the latest patch https://code.mythtv.org/trac/attachment/ticket/13383/20190208_1644_catchup_plus.patch
> > > for a couple of days and it looks good now.
> > >
> > > Mark- you said you may have some improvements - I plan to commit it anyway
> > > and those can always be done afterwards.
> > >
> > > You said that making the wait into a series of short waits may improve
> > > things. Currently on a desktop system everything is between -5 and +5 ms so
> > > I don't know if much improvement is possible. Also on thinking about it I
> > > don't know how that would help, if the operating system is going to delay
> > > resuming a process on one wait, would it be less likely to delay it on a
> > > bunch of smaller waits?
> > >
> > > If I don't hear anything back I will commit that patch to master and
> > > fixes/30.
> > Peter,
> >
> > Perhaps you must have missed my report on IRC. The 0208 patch causes
> > problems with live TV. When starting live TV or changing channels,
> > playback stutters badly until it is briefly paused or skipped back. I
> > don't know if earlier patches did this since I didn't test them on
> > live TV.
> >
> > David
> Yes - i missed that. I will look into it and fix it. Thanks for letting me
> know.

Thanks. On IRC, I also added that other than the live TV issue, the
0208 patch worked very well.

David
--
David Engel
david@istwok.net
_______________________________________________
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 2/13/2019 3:01 AM, Peter Bennett wrote:
> I have been using the latest patch
> https://code.mythtv.org/trac/attachment/ticket/13383/20190208_1644_catchup_plus.patch
> for a couple of days and it looks good now.
>
> Mark- you said you may have some improvements - I plan to commit it
> anyway and those can always be done afterwards.
>
> You said that making the wait into a series of short waits may improve
> things. Currently on a desktop system everything is between -5 and +5
> ms so I don't know if much improvement is possible. Also on thinking
> about it I don't know how that would help, if the operating system is
> going to delay resuming a process on one wait, would it be less likely
> to delay it on a bunch of smaller waits?
>
> If I don't hear anything back I will commit that patch to master and
> fixes/30.
>
By all means commit. It seems pretty good to me. Haven't tested live TV
since I don't use it but the periodic video stutter is ok. Not as smooth
as it could be but pretty good at all speeds so far used. I see on the
shield +-20ms which I don't understand ATM. The opensles driver chunks
things into 10ms blocks so that is currently the best audio time quantum
that is available. Ill look at providing a better estimate which should
be possible using the buffer callback and a time delta.

The original AVSync used some averaging/smoothing of the AV delta, so
that may be useful to improve playback smoothness. Panning shots and
ticks show this effect quite clearly.

Not sure how much the smaller delays affect things. When I get time Ill
disable or maybe put in a config and do some A/B tests.

As mentioned before, there may be a timestamp wrap issue but only saw
strangeness once and have deleted that program so Ill have to wait until
I see it again.

Cheers

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 2/12/19 3:59 PM, Mark Spieth wrote:
> On 2/13/2019 3:01 AM, Peter Bennett wrote:
>> I have been using the latest patch
>> https://code.mythtv.org/trac/attachment/ticket/13383/20190208_1644_catchup_plus.patch
>> for a couple of days and it looks good now.
>>
>> Mark- you said you may have some improvements - I plan to commit it
>> anyway and those can always be done afterwards.
>>
>> You said that making the wait into a series of short waits may
>> improve things. Currently on a desktop system everything is between
>> -5 and +5 ms so I don't know if much improvement is possible. Also on
>> thinking about it I don't know how that would help, if the operating
>> system is going to delay resuming a process on one wait, would it be
>> less likely to delay it on a bunch of smaller waits?
>>
>> If I don't hear anything back I will commit that patch to master and
>> fixes/30.
>>
> By all means commit. It seems pretty good to me. Haven't tested live
> TV since I don't use it but the periodic video stutter is ok. Not as
> smooth as it could be but pretty good at all speeds so far used. I see
> on the shield +-20ms which I don't understand ATM. The opensles driver
> chunks things into 10ms blocks so that is currently the best audio
> time quantum that is available. Ill look at providing a better
> estimate which should be possible using the buffer callback and a time
> delta.
>
> The original AVSync used some averaging/smoothing of the AV delta, so
> that may be useful to improve playback smoothness. Panning shots and
> ticks show this effect quite clearly.
>
I added the avsync averaging code to address the problems with OpenMAX
Audio. AVSync2 is supposed to achieve the same by limiting the size of
each adjustment to 10 ms or other value as specified in settings. You
could try changing that to see if it helps.
> Not sure how much the smaller delays affect things. When I get time
> Ill disable or maybe put in a config and do some A/B tests.
>
> As mentioned before, there may be a timestamp wrap issue but only saw
> strangeness once and have deleted that program so Ill have to wait
> until I see it again.
>
The code under "if ((lateness > AVSYNC_MAX_LATE || lateness < -
AVSYNC_MAX_LATE)" is supposed to address timestamp wrap, which should
occur without anything unusual being visible. If you have any example
which wraps I would like to test it and make sure.
> Cheers
>
> Mark
>
I have attached a new patch to the ticket to address the LiveTV problem.

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

On 13/02/2019 10:38 am, Peter Bennett wrote:
>
>
> On 2/12/19 3:59 PM, Mark Spieth wrote:
>> On 2/13/2019 3:01 AM, Peter Bennett wrote:
>>> I have been using the latest patch
>>> https://code.mythtv.org/trac/attachment/ticket/13383/20190208_1644_catchup_plus.patch
>>> for a couple of days and it looks good now.
>>>
>>> Mark- you said you may have some improvements - I plan to commit it
>>> anyway and those can always be done afterwards.
>>>
>>> You said that making the wait into a series of short waits may
>>> improve things. Currently on a desktop system everything is between
>>> -5 and +5 ms so I don't know if much improvement is possible. Also
>>> on thinking about it I don't know how that would help, if the
>>> operating system is going to delay resuming a process on one wait,
>>> would it be less likely to delay it on a bunch of smaller waits?
>>>
>>> If I don't hear anything back I will commit that patch to master and
>>> fixes/30.
>>>
>> By all means commit. It seems pretty good to me. Haven't tested live
>> TV since I don't use it but the periodic video stutter is ok. Not as
>> smooth as it could be but pretty good at all speeds so far used. I
>> see on the shield +-20ms which I don't understand ATM. The opensles
>> driver chunks things into 10ms blocks so that is currently the best
>> audio time quantum that is available. Ill look at providing a better
>> estimate which should be possible using the buffer callback and a
>> time delta.
>>
>> The original AVSync used some averaging/smoothing of the AV delta, so
>> that may be useful to improve playback smoothness. Panning shots and
>> ticks show this effect quite clearly.
>>
> I added the avsync averaging code to address the problems with OpenMAX
> Audio. AVSync2 is supposed to achieve the same by limiting the size of
> each adjustment to 10 ms or other value as specified in settings. You
> could try changing that to see if it helps.
>> Not sure how much the smaller delays affect things. When I get time
>> Ill disable or maybe put in a config and do some A/B tests.
>>
>> As mentioned before, there may be a timestamp wrap issue but only saw
>> strangeness once and have deleted that program so Ill have to wait
>> until I see it again.
>>
> The code under "if ((lateness > AVSYNC_MAX_LATE || lateness < -
> AVSYNC_MAX_LATE)" is supposed to address timestamp wrap, which should
> occur without anything unusual being visible. If you have any example
> which wraps I would like to test it and make sure.
It was just a gut feeling. No evidence. Have to find another instance
and chase it when I see it.
>> Cheers
>>
>> Mark
>>
> I have attached a new patch to the ticket to address the LiveTV problem.
>
LGTM but it does change the pause nature of the system. Not sure of this
effect, but resetting rtcbase seems key.

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, Feb 12, 2019 at 06:38:46PM -0500, Peter Bennett wrote:
>
>
> On 2/12/19 3:59 PM, Mark Spieth wrote:
> > On 2/13/2019 3:01 AM, Peter Bennett wrote:
> > > I have been using the latest patch https://code.mythtv.org/trac/attachment/ticket/13383/20190208_1644_catchup_plus.patch
> > > for a couple of days and it looks good now.
> > >
> > > Mark- you said you may have some improvements - I plan to commit it
> > > anyway and those can always be done afterwards.
> > >
> > > You said that making the wait into a series of short waits may
> > > improve things. Currently on a desktop system everything is between
> > > -5 and +5 ms so I don't know if much improvement is possible. Also
> > > on thinking about it I don't know how that would help, if the
> > > operating system is going to delay resuming a process on one wait,
> > > would it be less likely to delay it on a bunch of smaller waits?
> > >
> > > If I don't hear anything back I will commit that patch to master and
> > > fixes/30.
> > >
> > By all means commit. It seems pretty good to me. Haven't tested live TV
> > since I don't use it but the periodic video stutter is ok. Not as smooth
> > as it could be but pretty good at all speeds so far used. I see on the
> > shield +-20ms which I don't understand ATM. The opensles driver chunks
> > things into 10ms blocks so that is currently the best audio time quantum
> > that is available. Ill look at providing a better estimate which should
> > be possible using the buffer callback and a time delta.
> >
> > The original AVSync used some averaging/smoothing of the AV delta, so
> > that may be useful to improve playback smoothness. Panning shots and
> > ticks show this effect quite clearly.
> >
> I added the avsync averaging code to address the problems with OpenMAX
> Audio. AVSync2 is supposed to achieve the same by limiting the size of each
> adjustment to 10 ms or other value as specified in settings. You could try
> changing that to see if it helps.
> > Not sure how much the smaller delays affect things. When I get time Ill
> > disable or maybe put in a config and do some A/B tests.
> >
> > As mentioned before, there may be a timestamp wrap issue but only saw
> > strangeness once and have deleted that program so Ill have to wait until
> > I see it again.
> >
> The code under "if ((lateness > AVSYNC_MAX_LATE || lateness < -
> AVSYNC_MAX_LATE)" is supposed to address timestamp wrap, which should occur
> without anything unusual being visible. If you have any example which wraps
> I would like to test it and make sure.
> > Cheers
> >
> > Mark
> >
> I have attached a new patch to the ticket to address the LiveTV problem.

Recordings worked fine with the new patch. Live TV was also better in
that it did sync up. I think we can and should do better, though.
Several seconds before the big stuttering settles down 60+ seconds for
the little, jerkiness to go away is too long, IMO. I know most of us
either don't use live TV or don't mind pausing briefly when we do.
However, some of us have family members who do use live TV and, at
least in my case, it has been a point of contention.

My hope is that we can find a good, deterministic way to handle the
live TV case better. Failing that, we might need to capitulate add a
delay. I know someone objected to that recently. Perhaps we could
make such a delay configurable with the default being 0.

David
--
David Engel
david@istwok.net
_______________________________________________
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 Wed, Feb 13, 2019 at 10:27 AM David Engel <david@istwok.net> wrote:

> On Tue, Feb 12, 2019 at 06:38:46PM -0500, Peter Bennett wrote:
> > > On 2/12/19 3:59 PM, Mark Spieth wrote:
> > > On 2/13/2019 3:01 AM, Peter Bennett wrote:
> > > > I have been using the latest patch
> https://code.mythtv.org/trac/attachment/ticket/13383/20190208_1644_catchup_plus.patch
> > > > for a couple of days and it looks good now.
> > > >
> > > > Mark- you said you may have some improvements - I plan to commit it
> > > > anyway and those can always be done afterwards.
> > > >
> > > > You said that making the wait into a series of short waits may
> > > > improve things. Currently on a desktop system everything is between
> > > > -5 and +5 ms so I don't know if much improvement is possible. Also
> > > > on thinking about it I don't know how that would help, if the
> > > > operating system is going to delay resuming a process on one wait,
> > > > would it be less likely to delay it on a bunch of smaller waits?
> > > >
> > > > If I don't hear anything back I will commit that patch to master and
> > > > fixes/30.
> > > >
> > > By all means commit. It seems pretty good to me. Haven't tested live TV
> > > since I don't use it but the periodic video stutter is ok. Not as
> smooth
> > > as it could be but pretty good at all speeds so far used. I see on the
> > > shield +-20ms which I don't understand ATM. The opensles driver chunks
> > > things into 10ms blocks so that is currently the best audio time
> quantum
> > > that is available. Ill look at providing a better estimate which should
> > > be possible using the buffer callback and a time delta.
> > >
> > > The original AVSync used some averaging/smoothing of the AV delta, so
> > > that may be useful to improve playback smoothness. Panning shots and
> > > ticks show this effect quite clearly.
> > >
> > I added the avsync averaging code to address the problems with OpenMAX
> > Audio. AVSync2 is supposed to achieve the same by limiting the size of
> each
> > adjustment to 10 ms or other value as specified in settings. You could
> try
> > changing that to see if it helps.
> > > Not sure how much the smaller delays affect things. When I get time Ill
> > > disable or maybe put in a config and do some A/B tests.
> > >
> > > As mentioned before, there may be a timestamp wrap issue but only saw
> > > strangeness once and have deleted that program so Ill have to wait
> until
> > > I see it again.
> > >
> > The code under "if ((lateness > AVSYNC_MAX_LATE || lateness < -
> > AVSYNC_MAX_LATE)" is supposed to address timestamp wrap, which should
> occur
> > without anything unusual being visible. If you have any example which
> wraps
> > I would like to test it and make sure.
> > > Cheers
> > >
> > > Mark
> > >
> > I have attached a new patch to the ticket to address the LiveTV problem.
>
> Recordings worked fine with the new patch. Live TV was also better in
> that it did sync up. I think we can and should do better, though.
> Several seconds before the big stuttering settles down 60+ seconds for
> the little, jerkiness to go away is too long, IMO. I know most of us
> either don't use live TV or don't mind pausing briefly when we do.
> However, some of us have family members who do use live TV and, at
> least in my case, it has been a point of contention.
>
> My hope is that we can find a good, deterministic way to handle the
> live TV case better. Failing that, we might need to capitulate add a
> delay. I know someone objected to that recently. Perhaps we could
> make such a delay configurable with the default being 0.
>
> David
> --
> David Engel
> david@istwok.net
>

I'm just speaking from experience with almost every available TV provider
and / or STB since the 80s here, but they all have a fairly significant
wait before presenting a viewable picture to the TV. What would be the
harm of doing it in the background automatically with the delay and just
not present the screen until it is finished?

It would be no different than the norm here in the US. From all I have
read on this subject over the last few years when Live TV actually got some
love after even more than a few years of total neglect, it is so close to
unaided usability that it would be a shame to not throw this in there and
put it to bed for good -- especially when someone is willing and currently
working on it..

Just my $.02 as a user.

On 2/13/19 11:26 AM, David Engel wrote:
> Recordings worked fine with the new patch. Live TV was also better in
> that it did sync up. I think we can and should do better, though.
> Several seconds before the big stuttering settles down 60+ seconds for
> the little, jerkiness to go away is too long, IMO. I know most of us
> either don't use live TV or don't mind pausing briefly when we do.
> However, some of us have family members who do use live TV and, at
> least in my case, it has been a point of contention.
>
> My hope is that we can find a good, deterministic way to handle the
> live TV case better. Failing that, we might need to capitulate add a
> delay. I know someone objected to that recently. Perhaps we could
> make such a delay configurable with the default being 0.
>
I think that now it is working the same as in v29.

It pauses one frame at a time until playback is 3 seconds behind the
recording. The problem is that after that it gets slightly ahead of the
3 seconds again from time to time and does more pauses. I will need to
change it so that it pauses a bit longer than the amount it uses for
subsequent checks. Alternatively, only pause once and never check again.
The reason I have subsequent checks is in case you hit jump forward and
get into the stuttering situation again. I am not sure if this is possible.

Another thing I want to do is reduce the excessive number of messages it
puts in the verbose playback during Live TV startup.

I will get another patch for it.

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

On 2/13/19 12:56 PM, Peter Bennett wrote:
>
>
> On 2/13/19 11:26 AM, David Engel wrote:
>> Recordings worked fine with the new patch.  Live TV was also better in
>> that it did sync up.  I think we can and should do better, though.
>> Several seconds before the big stuttering settles down 60+ seconds for
>> the little, jerkiness to go away is too long, IMO.  I know most of us
>> either don't use live TV or don't mind pausing briefly when we do.
>> However, some of us have family members who do use live TV and, at
>> least in my case, it has been a point of contention.
>>
>> My hope is that we can find a good, deterministic way to handle the
>> live TV case better.  Failing that, we might need to capitulate add a
>> delay.  I know someone objected to that recently.  Perhaps we could
>> make such a delay configurable with the default being 0.
>>
> I think that now it is working the same as in v29.
>
> It pauses one frame at a time until playback is 3 seconds behind the
> recording. The problem is that after that it gets slightly ahead of
> the 3 seconds again from time to time and does more pauses. I will
> need to change it so that it pauses a bit longer than the amount it
> uses for subsequent checks. Alternatively, only pause once and never
> check again. The reason I have subsequent checks is in case you hit
> jump forward and get into the stuttering situation again. I am not
> sure if this is possible.
>
> Another thing I want to do is reduce the excessive number of messages
> it puts in the verbose playback during Live TV startup.
>
> I will get another patch for it.
>
> Peter
I was not able to easily change the logic, so I have added a setting for
a delay at the start of Live TV that defaults to zero and is
configurable. Setting 4000 ms seems to eliminate the stuttering. Setting
zero will still recover over approximately a minute.
Updated patch:

https://code.mythtv.org/trac/attachment/ticket/13383/20190213_1544_catchup_plus.patch

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

On Thu, Feb 14, 2019 at 10:15:50AM -0500, Peter Bennett wrote:
>
>
> On 2/13/19 12:56 PM, Peter Bennett wrote:
> >
> >
> > On 2/13/19 11:26 AM, David Engel wrote:
> > > Recordings worked fine with the new patch.? Live TV was also better in
> > > that it did sync up.? I think we can and should do better, though.
> > > Several seconds before the big stuttering settles down 60+ seconds for
> > > the little, jerkiness to go away is too long, IMO.? I know most of us
> > > either don't use live TV or don't mind pausing briefly when we do.
> > > However, some of us have family members who do use live TV and, at
> > > least in my case, it has been a point of contention.
> > >
> > > My hope is that we can find a good, deterministic way to handle the
> > > live TV case better.? Failing that, we might need to capitulate add a
> > > delay.? I know someone objected to that recently.? Perhaps we could
> > > make such a delay configurable with the default being 0.
> > >
> > I think that now it is working the same as in v29.
> >
> > It pauses one frame at a time until playback is 3 seconds behind the
> > recording. The problem is that after that it gets slightly ahead of the
> > 3 seconds again from time to time and does more pauses. I will need to
> > change it so that it pauses a bit longer than the amount it uses for
> > subsequent checks. Alternatively, only pause once and never check again.
> > The reason I have subsequent checks is in case you hit jump forward and
> > get into the stuttering situation again. I am not sure if this is
> > possible.
> >
> > Another thing I want to do is reduce the excessive number of messages it
> > puts in the verbose playback during Live TV startup.
> >
> > I will get another patch for it.
> >
> > Peter
> I was not able to easily change the logic, so I have added a setting for a
> delay at the start of Live TV that defaults to zero and is configurable.
> Setting 4000 ms seems to eliminate the stuttering. Setting zero will still
> recover over approximately a minute.
> Updated patch:
>
> https://code.mythtv.org/trac/attachment/ticket/13383/20190213_1544_catchup_plus.patch

I saw the new patch and tried it briefly last night. Setting a wait
of 1000ms helped sometimes and not others when entering live TV. I
need to test more with longer waits. One thing I noticed was that no
value seemed to have any effect on channel changes. They were always
very stuttery. Is the new setting even used when changing channels?

David
--
David Engel
david@istwok.net
_______________________________________________
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 2/14/19 11:51 AM, David Engel wrote:
> I saw the new patch and tried it briefly last night. Setting a wait
> of 1000ms helped sometimes and not others when entering live TV. I
> need to test more with longer waits. One thing I noticed was that no
> value seemed to have any effect on channel changes. They were always
> very stuttery. Is the new setting even used when changing channels?

It is probably not used when changing channels - I will check into that.

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

On 14/02/2019 16:58, Peter Bennett wrote:
>
>
> On 2/14/19 11:51 AM, David Engel wrote:
>> I saw the new patch and tried it briefly last night.  Setting a wait
>> of 1000ms helped sometimes and not others when entering live TV.  I
>> need to test more with longer waits.  One thing I noticed was that no
>> value seemed to have any effect on channel changes.  They were always
>> very stuttery.  Is the new setting even used when changing channels?
>
> It is probably not used when changing channels - I will check into that.
>
> Peter

This is getting to sound like a re-run of ancient history.
File-and-database management issues are always going to put Myth at a
disadvantage in contests with 'real TVs' for channel-surfing and
being-the-first-to-know. Please let's just accept that and get it as
good as seems reasonably possible. Perhaps attempts to jump too far
forward in live tv should be just ignored, too.

2c?

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

On 2/14/19 12:38 PM, John Pilkington wrote:
> On 14/02/2019 16:58, Peter Bennett wrote:
>>
>>
>> On 2/14/19 11:51 AM, David Engel wrote:
>>> I saw the new patch and tried it briefly last night.  Setting a wait
>>> of 1000ms helped sometimes and not others when entering live TV.  I
>>> need to test more with longer waits.  One thing I noticed was that no
>>> value seemed to have any effect on channel changes.  They were always
>>> very stuttery.  Is the new setting even used when changing channels?
>>
>> It is probably not used when changing channels - I will check into that.
>>
>> Peter
>
> This is getting to sound like a re-run of ancient history.
> File-and-database management issues are always going to put Myth at a
> disadvantage in contests with 'real TVs' for channel-surfing and
> being-the-first-to-know.  Please let's just accept that and get it as
> good as seems reasonably possible.  Perhaps attempts to jump too far
> forward in live tv should be just ignored, too.
>
> 2c?
>
If you set the new "Live TV Wait" setting to zero (which is the
default), I believe that you get the quickest change possible with
MythTV, with a few stutterings which will take less than a minute. If
you really object to the few stutterings, set the "Live TV wait" to 4000
or whatever value works for you.

There is a new patch that adds the wait to channel change and "switch
input".

https://code.mythtv.org/trac/attachment/ticket/13383/20190214_1507_catchup_plus.patch

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

Peter,

This discussion and the direction the code is going worries me.

Firstly, as I've said recently, I never took any interest in the a/v
sync code before because it just worked. It might have a jitter or two
after a seek, channel change etc - but it always recovered.
Over the last few weeks I've realised that just isn't the case any
more - for 'old' avsync or avsync2. Both just get it wrong far too
often and in the worst cases never recover and/or just lose the plot
suddenly when playback has been fine and uninterrupted for minutes
beforehand.

As far as I'm concerned this is a regression.

Secondly and more importantly, I think you're fighting symptoms and
not causes. I think David alluded too it in a previous email - but
fundamentally the code is starting to control a/v sync after the
battle has been lost. Audio and video are taking very different paths
after being demuxed - and in the most common case, the far longer path
is for video. I think you need to look at how playback is
started/restarted and ensure that, for example, the audio doesn't
start playing 20-30 frames ahead of the video (seen commonly here). It
is so obvious sometimes that the playback window is still showing when
the audio has started.

If that can be addressed, then the job of the main a/v sync code
becomes much easier - and the complexity that seems to be being
introduced can be avoided.

I would definitely suggest that adding a setting to work around a
semi-random/uncontrollable delay is a bad idea.

Regards,
Mark

On Thu, 14 Feb 2019 at 20:25, Peter Bennett <pb.mythtv@gmail.com> wrote:
>
> There is a new patch that adds the wait to channel change and "switch
> input".
>
> https://code.mythtv.org/trac/attachment/ticket/13383/20190214_1507_catchup_plus.patch
_______________________________________________
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 2/14/19 6:05 PM, Mark Kendall wrote:
> Peter,
>
> This discussion and the direction the code is going worries me.
>
> Firstly, as I've said recently, I never took any interest in the a/v
> sync code before because it just worked. It might have a jitter or two
> after a seek, channel change etc - but it always recovered.
> Over the last few weeks I've realised that just isn't the case any
> more - for 'old' avsync or avsync2. Both just get it wrong far too
> often and in the worst cases never recover and/or just lose the plot
> suddenly when playback has been fine and uninterrupted for minutes
> beforehand.
I have never noticed that - see the comment about Music Choice below.
> As far as I'm concerned this is a regression.
Please make sure you do not have the setting "Music Choice" checked.
This may cause out of sync playback, so preferably leave it turned off
if possible.

> Secondly and more importantly, I think you're fighting symptoms and
> not causes. I think David alluded too it in a previous email - but
> fundamentally the code is starting to control a/v sync after the
> battle has been lost. Audio and video are taking very different paths
> after being demuxed - and in the most common case, the far longer path
> is for video. I think you need to look at how playback is
> started/restarted and ensure that, for example, the audio doesn't
> start playing 20-30 frames ahead of the video (seen commonly here). It
> is so obvious sometimes that the playback window is still showing when
> the audio has started.
>
> If that can be addressed, then the job of the main a/v sync code
> becomes much easier - and the complexity that seems to be being
> introduced can be avoided.
Have you tried the latest patch? AVSync2 was designed to be smoother but
it was unfortunately taking a few seconds to get audio and video
synchronized at the start. The latest patch is primarily to address
that. It also addresses the problem of audio starting too soon.
> I would definitely suggest that adding a setting to work around a
> semi-random/uncontrollable delay is a bad idea.
David requested that. It defaults to zero. See if you can convince him :).

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

Note there is a serious, new regression with the 0214 patch described
at the end.

On Thu, Feb 14, 2019 at 07:00:43PM -0500, Peter Bennett wrote:
>
>
> On 2/14/19 6:05 PM, Mark Kendall wrote:
> > Peter,
> >
> > This discussion and the direction the code is going worries me.
> >
> > Firstly, as I've said recently, I never took any interest in the a/v
> > sync code before because it just worked. It might have a jitter or two
> > after a seek, channel change etc - but it always recovered.
> > Over the last few weeks I've realised that just isn't the case any
> > more - for 'old' avsync or avsync2. Both just get it wrong far too
> > often and in the worst cases never recover and/or

I've been happy with avsync2 (before the recent patches) *after* it's
synced. Using the actual timestamps for the audio and video seems
like the right answer. Using frame drop prediction works in many
cases but breaks down when there are variable frame rates.

You're right, though, that old avsync did well enough in the worst
cases like starting playback/live TV, skipping and changing channels.
That's why I asked for improvements in those areas.


> just lose the plot
> > suddenly when playback has been fine and uninterrupted for minutes
> > beforehand.
> I have never noticed that - see the comment about Music Choice below.

I have seen some cases of that but didn't bring them up because I
ddin't associate them with avsync2.

> > As far as I'm concerned this is a regression.
> Please make sure you do not have the setting "Music Choice" checked. This
> may cause out of sync playback, so preferably leave it turned off if
> possible.
>
> > Secondly and more importantly, I think you're fighting symptoms and
> > not causes. I think David alluded too it in a previous email - but
> > fundamentally the code is starting to control a/v sync after the
> > battle has been lost. Audio and video are taking very different paths
> > after being demuxed - and in the most common case, the far longer path
> > is for video. I think you need to look at how playback is
> > started/restarted and ensure that, for example, the audio doesn't
> > start playing 20-30 frames ahead of the video (seen commonly here). It
> > is so obvious sometimes that the playback window is still showing when
> > the audio has started.

To my naive mind, do something like this:

wait until you've got at least one audio and video frame each.

if audio is ahead of video, thow away audio as it comes in until
its timestamp is the same or close enough to the first video
timestamp.

if video is ahead of audio, thow away video as it comes in until
its timestamp is the same or close enough to the first audio
timestamp.

wait until enough audio and video has been decoded and start
playback.

I don't know the av code well enough to know if this is feasible or
would even work.

> > If that can be addressed, then the job of the main a/v sync code
> > becomes much easier - and the complexity that seems to be being
> > introduced can be avoided.
> Have you tried the latest patch? AVSync2 was designed to be smoother but it
> was unfortunately taking a few seconds to get audio and video synchronized
> at the start. The latest patch is primarily to address that. It also
> addresses the problem of audio starting too soon.
> > I would definitely suggest that adding a setting to work around a
> > semi-random/uncontrollable delay is a bad idea.
> David requested that. It defaults to zero. See if you can convince him :).

It was requested as a stopgap until a better solution could be found.
I'm a big proponent that things like this should work well in the
majority of cases without any configuration needed.

Here's the new, serious regression. Choose a theme with a video
window in the EPG (Blue Abstract should work). Set live TV wait to
1000ms (that's what I used). Start live TV. Bring up the EPG and use
it to change channels. Video playback continues in the small window
and never switches back to full screen.

David
--
David Engel
david@istwok.net
_______________________________________________
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 2/14/19 10:08 PM, David Engel wrote:
> Here's the new, serious regression. Choose a theme with a video
> window in the EPG (Blue Abstract should work). Set live TV wait to
> 1000ms (that's what I used). Start live TV. Bring up the EPG and use
> it to change channels. Video playback continues in the small window
> and never switches back to full screen.
I tried this with NVDEC on Linux with Steppes as well as Shield with
Steppes and I do not see it happen. I tried with both 1000 and 10000
delay. When I select a new channel the small TV view freezes for a
period of 1000 or 10000 ms but immediately goes back to full screen when
it starts playing again.

How do I recreate this?

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

On 2/14/19 10:08 PM, David Engel wrote:
> o my naive mind, do something like this:
>
> wait until you've got at least one audio and video frame each.
>
> if audio is ahead of video, thow away audio as it comes in until
> its timestamp is the same or close enough to the first video
> timestamp.
>
> if video is ahead of audio, thow away video as it comes in until
> its timestamp is the same or close enough to the first audio
> timestamp.
>
> wait until enough audio and video has been decoded and start
> playback.
>
> I don't know the av code well enough to know if this is feasible or
> would even work.
That is roughly what it does.

One theory - due to buffering each frame is not written to disk as it
comes in, they are physically written in bigger blocks. The frontend
tries to read them as they are written, but until a block is actually
written it is starved of data. It may have got a perfectly synchronized
audio and video frame a few milliseconds ago but when it looks for the
next one it is not there yet.

I have committed all of the changes except for the Live TV delay change.
There is a patch for that change in the ticket.

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

On Fri, Feb 15, 2019 at 01:55:27PM -0500, Peter Bennett wrote:
>
>
> On 2/14/19 10:08 PM, David Engel wrote:
> > Here's the new, serious regression. Choose a theme with a video
> > window in the EPG (Blue Abstract should work). Set live TV wait to
> > 1000ms (that's what I used). Start live TV. Bring up the EPG and use
> > it to change channels. Video playback continues in the small window
> > and never switches back to full screen.
> I tried this with NVDEC on Linux with Steppes as well as Shield with Steppes
> and I do not see it happen. I tried with both 1000 and 10000 delay. When I
> select a new channel the small TV view freezes for a period of 1000 or 10000
> ms but immediately goes back to full screen when it starts playing again.
>
> How do I recreate this?

Come to my house? :) Seriously, it was repeatable on my Shield with
slightly modified version of Blue Abstract. I didn't mod the EPG so I
very much doubt they had any effect. I will test again tonight with
the other latest changes.

David
--
David Engel
david@istwok.net
_______________________________________________
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 Fri, Feb 15, 2019 at 03:04:05PM -0600, David Engel wrote:
> On Fri, Feb 15, 2019 at 01:55:27PM -0500, Peter Bennett wrote:
> >
> >
> > On 2/14/19 10:08 PM, David Engel wrote:
> > > Here's the new, serious regression. Choose a theme with a video
> > > window in the EPG (Blue Abstract should work). Set live TV wait to
> > > 1000ms (that's what I used). Start live TV. Bring up the EPG and use
> > > it to change channels. Video playback continues in the small window
> > > and never switches back to full screen.
> > I tried this with NVDEC on Linux with Steppes as well as Shield with Steppes
> > and I do not see it happen. I tried with both 1000 and 10000 delay. When I
> > select a new channel the small TV view freezes for a period of 1000 or 10000
> > ms but immediately goes back to full screen when it starts playing again.
> >
> > How do I recreate this?
>
> Come to my house? :) Seriously, it was repeatable on my Shield with
> slightly modified version of Blue Abstract. I didn't mod the EPG so I
> very much doubt they had any effect. I will test again tonight with
> the other latest changes.

I just tried today's changes with my theme and also with official,
Blue Abstract. With live TV wait set to 0, it works as expected. If
live TV wait is set to 1000ms or more, the video never jumps back to
full size. About 500ms seems to be the value where things break. AT
<= 400ms, it usually works and at >= 600ms, it usually doesn't.
Again, this is with my Shield. I just tested on my Linux desktop with
OpenGL rendering and it did the same thing.

David
--
David Engel
david@istwok.net
_______________________________________________
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 2/15/19 10:14 PM, David Engel wrote:
> I just tried today's changes with my theme and also with official,
> Blue Abstract. With live TV wait set to 0, it works as expected. If
> live TV wait is set to 1000ms or more, the video never jumps back to
> full size. About 500ms seems to be the value where things break. AT
> <= 400ms, it usually works and at >= 600ms, it usually doesn't.
> Again, this is with my Shield. I just tested on my Linux desktop with
> OpenGL rendering and it did the same thing.
Today I do see the problem. Clearly this patch is not working as it should.

Is there a need to continue with this? The code that I have committed
works with Live TV and catches up over a minute or so. Mark K expressed
that he did not want the delay patch put in and you said it is only a
temporary thing.

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