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

On Sat, Feb 16, 2019 at 03:28:14PM -0500, Peter Bennett wrote:
> 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.

I'll have to test without the patch to see how it is. Before the all
of the other, recent changes, I don't recall the live TV case being
too bad. A minute of very minor judder is probably okay. If it's a
minute of more noticeable stuttering, I still think we should do
better.

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 Sat, Feb 16, 2019 at 04:00:45PM -0600, David Engel wrote:
> On Sat, Feb 16, 2019 at 03:28:14PM -0500, Peter Bennett wrote:
> > 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.
>
> I'll have to test without the patch to see how it is. Before the all
> of the other, recent changes, I don't recall the live TV case being
> too bad. A minute of very minor judder is probably okay. If it's a
> minute of more noticeable stuttering, I still think we should do
> better.

I compared some live TV cases (entering and changing channels) with
and without avsync2. Without avsync2, there were cases where the
audio and video would sync up fairly quickly. Most of the time,
though, it would take a little while to sync up. In those cases it
was comparable to avsync2. Avsync2 was pretty constant in that it
always took dozens of secongs to sync up.

I noticed a couple of other issues caused by avsync2 that I hadn't
previously tied to it. I have one, 1080i, h.264 channel that I watch
fairly regularly at >= 1.5x.

1. The avsync randomly goes out of phase for short periods (like Mark
Spieth mentioned). I figured the CPU load on my Shield was on the
edge and just couldn't quite keep at those times. The problem goes
away completely after I turn off avsync2. I suspect the logs would
show the same inabiltiy to correct that other logs have shown.

2. I have my fast forward speeds set to 10x, 20x, 60x and 180x. 10x
and 20x work normally. 60x and 180x have problems. A video frame is
displayed and then there is a very long pause before another video
frame is displayed. Basically those speeds are useless. Like above,
the problem goes away completely after I turn off avsync2. I can
provide logs for this if you want.

I've been using/testing avsync for long enough that I guess I'd gotten
used to it's quirks. After seeing the old avsync behavior again, I'm
inclined to go back. Skips and jump (which I do a lot of) feel like
they are slower than with avsync2 but the lack of the other issues
more than makes up for it.

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

The problems with AVSync that I tried to address with AVSync2 -
1. If the frame rate from ffmpeg is incorrect or the actual fra,e rate
rate changes, AVSync takes no heed of that, just uses the specified
frame rate. The only reason it actually gets it right in these cases is
because it doubles or drops frames to keep in sync with the audio. So if
a video is given as 30fps by ffmpeg but the time codes are actually 25
fps it will display as 30fps and then double some frames to keep up with
the audio. If there was a video without audio it would effectively
ignore video time stamps and play at the wrong rate.
2. When getting the video in sync with audio the only strategies it uses
are doubling or halving frame interval for selected frames.
3. If the audio device is unreliable at telling us how much audio is in
the buffer (e.g. OpenMax digital audio), avsync produces unacceptably
stuttery audio and video. This is addressed in avsync with a complex
arrangement of averaging the error over many frames if OpenMax audio is
in use.

Avsync2 addresses the problems in this way -
1. Uses individual frame timestamps to determine when to display frames,
rather than using the frame rate.
2. If audio and video are out of sync adjusts each frame by a small
amount (from settings - defaults to 10ms) until it gets in sync. This
solves problem 3 above without the complex averaging scheme.
3. Recent change - if audio and video are out by more than 200ms -
speeds up the correction so that it corrects over 15 frames at most.

On 2/17/19 2:03 PM, David Engel wrote:
> I compared some live TV cases (entering and changing channels) with
> and without avsync2. Without avsync2, there were cases where the
> audio and video would sync up fairly quickly. Most of the time,
> though, it would take a little while to sync up. In those cases it
> was comparable to avsync2. Avsync2 was pretty constant in that it
> always took dozens of secongs to sync up.
When starting Live TV there is a different problem from the normal
playback, that is the system being starved of audio and video data, and
stuttering while catching up. I don't know why that would be different
between avsync and avsync2, there is not much change in that area.
> I noticed a couple of other issues caused by avsync2 that I hadn't
> previously tied to it. I have one, 1080i, h.264 channel that I watch
> fairly regularly at >= 1.5x.
>
> 1. The avsync randomly goes out of phase for short periods (like Mark
> Spieth mentioned). I figured the CPU load on my Shield was on the
> edge and just couldn't quite keep at those times. The problem goes
> away completely after I turn off avsync2. I suspect the logs would
> show the same inabiltiy to correct that other logs have shown.
Comcast has no 1080i h264 channels. If you can give me more details, a
verbose playback log or sample video I can look into this. Does it
happen with Linux? Does it happen with mediacodec or software decode or
both?
> 2. I have my fast forward speeds set to 10x, 20x, 60x and 180x. 10x
> and 20x work normally. 60x and 180x have problems. A video frame is
> displayed and then there is a very long pause before another video
> frame is displayed. Basically those speeds are useless. Like above,
> the problem goes away completely after I turn off avsync2. I can
> provide logs for this if you want.
Is this only on shield? Where do you set these amounts? I seldom use
fast forward so I am not familiar with this.
> I've been using/testing avsync for long enough that I guess I'd gotten
> used to it's quirks. After seeing the old avsync behavior again, I'm
> inclined to go back. Skips and jump (which I do a lot of) feel like
> they are slower than with avsync2 but the lack of the other issues
> more than makes up for it.

General comment - If you are using mediacodec decoder with interlaced
content it automatically uses a frame doubling deinterlacer. In this
case it is not possible for MythTV to switch to a non-doubling
deinterlacer when using speedup, so it may work better to use software
decoding in that case, which will switch to a non-doubling deinterlacer
when speeding up.

Since I do not use speedup or fast forward, my testing in those areas
has been minimal. AVSync2 changes to improve smoothness are likely moot
when using speedup.

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 19, 2019 at 01:53:26PM -0500, Peter Bennett wrote:
> The problems with AVSync that I tried to address with AVSync2 -
> 1. If the frame rate from ffmpeg is incorrect or the actual fra,e rate rate
> changes, AVSync takes no heed of that, just uses the specified frame rate.
> The only reason it actually gets it right in these cases is because it
> doubles or drops frames to keep in sync with the audio. So if a video is
> given as 30fps by ffmpeg but the time codes are actually 25 fps it will
> display as 30fps and then double some frames to keep up with the audio. If
> there was a video without audio it would effectively ignore video time
> stamps and play at the wrong rate.
> 2. When getting the video in sync with audio the only strategies it uses are
> doubling or halving frame interval for selected frames.
> 3. If the audio device is unreliable at telling us how much audio is in the
> buffer (e.g. OpenMax digital audio), avsync produces unacceptably stuttery
> audio and video. This is addressed in avsync with a complex arrangement of
> averaging the error over many frames if OpenMax audio is in use.
>
> Avsync2 addresses the problems in this way -
> 1. Uses individual frame timestamps to determine when to display frames,
> rather than using the frame rate.
> 2. If audio and video are out of sync adjusts each frame by a small amount
> (from settings - defaults to 10ms) until it gets in sync. This solves
> problem 3 above without the complex averaging scheme.
> 3. Recent change - if audio and video are out by more than 200ms - speeds up
> the correction so that it corrects over 15 frames at most.

I understand all that. Don't get me wrong. I am *very* much in favor
of what you're trying to do with avsync2. For example, my local, ABC
station broadcasts in 1080i (most ABC stations broadcast in 720p).
This station is also one of those that exposed the Nvidia/mpeg2
corruption issue. I do not know what else this station is doing but
The Good Doctor will only plya smoothly with avsync2. Also, all of
the movies I'm transcoding are being converted to 23.94 fps and they
need avsync2 to play smoothly. I want avsync2 to succeed. It's just
that the other issues (skips, ff/rew, randoms loss of sync) are
significant to me that avsync2 is not the clear winner, YET.

> On 2/17/19 2:03 PM, David Engel wrote:
> > I compared some live TV cases (entering and changing channels) with
> > and without avsync2. Without avsync2, there were cases where the
> > audio and video would sync up fairly quickly. Most of the time,
> > though, it would take a little while to sync up. In those cases it
> > was comparable to avsync2. Avsync2 was pretty constant in that it
> > always took dozens of secongs to sync up.
> When starting Live TV there is a different problem from the normal playback,
> that is the system being starved of audio and video data, and stuttering
> while catching up. I don't know why that would be different between avsync
> and avsync2, there is not much change in that area.
> > I noticed a couple of other issues caused by avsync2 that I hadn't
> > previously tied to it. I have one, 1080i, h.264 channel that I watch
> > fairly regularly at >= 1.5x.
> >
> > 1. The avsync randomly goes out of phase for short periods (like Mark
> > Spieth mentioned). I figured the CPU load on my Shield was on the
> > edge and just couldn't quite keep at those times. The problem goes
> > away completely after I turn off avsync2. I suspect the logs would
> > show the same inabiltiy to correct that other logs have shown.
> Comcast has no 1080i h264 channels. If you can give me more details, a
> verbose playback log or sample video I can look into this. Does it happen
> with Linux? Does it happen with mediacodec or software decode or both?

I'll get you a sample. I have not tried this on Linux. I will try
tonight. The problem is my only Linux frontend now is my development
desktop. It's not exactly comfortable to use for real watching.

> > 2. I have my fast forward speeds set to 10x, 20x, 60x and 180x. 10x
> > and 20x work normally. 60x and 180x have problems. A video frame is
> > displayed and then there is a very long pause before another video
> > frame is displayed. Basically those speeds are useless. Like above,
> > the problem goes away completely after I turn off avsync2. I can
> > provide logs for this if you want.
> Is this only on shield? Where do you set these amounts? I seldom use fast
> forward so I am not familiar with this.

Yes, like above, only tested on Shields.

There is no GUI for setting the ff/rew speeds. They were left as
Easter Eggs for the more adventurous to find. The setting names are
FFRewSpeed0 through FFRewSpeed7. Each successive press of ff/rew
increases or decreases the speed in the appropriate direction. Speeds
of 0 are ignored. Mine are set to 10, 20, 60, 180, 0, 0, 0, 0.

> > I've been using/testing avsync for long enough that I guess I'd gotten
> > used to it's quirks. After seeing the old avsync behavior again, I'm
> > inclined to go back. Skips and jump (which I do a lot of) feel like
> > they are slower than with avsync2 but the lack of the other issues
> > more than makes up for it.
>
> General comment - If you are using mediacodec decoder with interlaced
> content it automatically uses a frame doubling deinterlacer. In this case it
> is not possible for MythTV to switch to a non-doubling deinterlacer when
> using speedup, so it may work better to use software decoding in that case,
> which will switch to a non-doubling deinterlacer when speeding up.

I have been mainly using software decoding for several months. The
main reasons are the Nvidia/mpeg2 issue on one channel, the ff/rew
pauses that frequiently occur while the mediacodec decoder is reset
and the inability to timestretch 1089/h.264 at 2x without frequent
stuttering.

My movie transcodes are h.265 so will be using mediacode decoding more
going forward. I also mediacodec yesterday on 720p/mpeg2 at 1.75x and
1080i/h.264 at 1.5x. I hadn't done that in a while and wanted to
check it out. I didn't notice any of the ff/rew pauses. Maybe Nvidia
fixed something in their Oreo updates.

> Since I do not use speedup or fast forward, my testing in those areas has
> been minimal. AVSync2 changes to improve smoothness are likely moot when
> using speedup.

Probably 2/3 of what I watch is stretched to 1.25, 1.5, 1.75 and even
2x.

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/20/2019 7:13 AM, David Engel wrote:
> On Tue, Feb 19, 2019 at 01:53:26PM -0500, Peter Bennett wrote:
>> The problems with AVSync that I tried to address with AVSync2 -
>> 1. If the frame rate from ffmpeg is incorrect or the actual fra,e rate rate
>> changes, AVSync takes no heed of that, just uses the specified frame rate.
>> The only reason it actually gets it right in these cases is because it
>> doubles or drops frames to keep in sync with the audio. So if a video is
>> given as 30fps by ffmpeg but the time codes are actually 25 fps it will
>> display as 30fps and then double some frames to keep up with the audio. If
>> there was a video without audio it would effectively ignore video time
>> stamps and play at the wrong rate.
>> 2. When getting the video in sync with audio the only strategies it uses are
>> doubling or halving frame interval for selected frames.
>> 3. If the audio device is unreliable at telling us how much audio is in the
>> buffer (e.g. OpenMax digital audio), avsync produces unacceptably stuttery
>> audio and video. This is addressed in avsync with a complex arrangement of
>> averaging the error over many frames if OpenMax audio is in use.
>>
>> Avsync2 addresses the problems in this way -
>> 1. Uses individual frame timestamps to determine when to display frames,
>> rather than using the frame rate.
>> 2. If audio and video are out of sync adjusts each frame by a small amount
>> (from settings - defaults to 10ms) until it gets in sync. This solves
>> problem 3 above without the complex averaging scheme.
>> 3. Recent change - if audio and video are out by more than 200ms - speeds up
>> the correction so that it corrects over 15 frames at most.
> I understand all that. Don't get me wrong. I am *very* much in favor
> of what you're trying to do with avsync2. For example, my local, ABC
> station broadcasts in 1080i (most ABC stations broadcast in 720p).
> This station is also one of those that exposed the Nvidia/mpeg2
> corruption issue. I do not know what else this station is doing but
> The Good Doctor will only plya smoothly with avsync2. Also, all of
> the movies I'm transcoding are being converted to 23.94 fps and they
> need avsync2 to play smoothly. I want avsync2 to succeed. It's just
> that the other issues (skips, ff/rew, randoms loss of sync) are
> significant to me that avsync2 is not the clear winner, YET.
>
>> On 2/17/19 2:03 PM, David Engel wrote:
>>> I compared some live TV cases (entering and changing channels) with
>>> and without avsync2. Without avsync2, there were cases where the
>>> audio and video would sync up fairly quickly. Most of the time,
>>> though, it would take a little while to sync up. In those cases it
>>> was comparable to avsync2. Avsync2 was pretty constant in that it
>>> always took dozens of secongs to sync up.
>> When starting Live TV there is a different problem from the normal playback,
>> that is the system being starved of audio and video data, and stuttering
>> while catching up. I don't know why that would be different between avsync
>> and avsync2, there is not much change in that area.
>>> I noticed a couple of other issues caused by avsync2 that I hadn't
>>> previously tied to it. I have one, 1080i, h.264 channel that I watch
>>> fairly regularly at >= 1.5x.
>>>
>>> 1. The avsync randomly goes out of phase for short periods (like Mark
>>> Spieth mentioned). I figured the CPU load on my Shield was on the
>>> edge and just couldn't quite keep at those times. The problem goes
>>> away completely after I turn off avsync2. I suspect the logs would
>>> show the same inabiltiy to correct that other logs have shown.
>> Comcast has no 1080i h264 channels. If you can give me more details, a
>> verbose playback log or sample video I can look into this. Does it happen
>> with Linux? Does it happen with mediacodec or software decode or both?
> I'll get you a sample. I have not tried this on Linux. I will try
> tonight. The problem is my only Linux frontend now is my development
> desktop. It's not exactly comfortable to use for real watching.
>
>>> 2. I have my fast forward speeds set to 10x, 20x, 60x and 180x. 10x
>>> and 20x work normally. 60x and 180x have problems. A video frame is
>>> displayed and then there is a very long pause before another video
>>> frame is displayed. Basically those speeds are useless. Like above,
>>> the problem goes away completely after I turn off avsync2. I can
>>> provide logs for this if you want.
>> Is this only on shield? Where do you set these amounts? I seldom use fast
>> forward so I am not familiar with this.
> Yes, like above, only tested on Shields.
>
> There is no GUI for setting the ff/rew speeds. They were left as
> Easter Eggs for the more adventurous to find. The setting names are
> FFRewSpeed0 through FFRewSpeed7. Each successive press of ff/rew
> increases or decreases the speed in the appropriate direction. Speeds
> of 0 are ignored. Mine are set to 10, 20, 60, 180, 0, 0, 0, 0.
>
>>> I've been using/testing avsync for long enough that I guess I'd gotten
>>> used to it's quirks. After seeing the old avsync behavior again, I'm
>>> inclined to go back. Skips and jump (which I do a lot of) feel like
>>> they are slower than with avsync2 but the lack of the other issues
>>> more than makes up for it.
>> General comment - If you are using mediacodec decoder with interlaced
>> content it automatically uses a frame doubling deinterlacer. In this case it
>> is not possible for MythTV to switch to a non-doubling deinterlacer when
>> using speedup, so it may work better to use software decoding in that case,
>> which will switch to a non-doubling deinterlacer when speeding up.
> I have been mainly using software decoding for several months. The
> main reasons are the Nvidia/mpeg2 issue on one channel, the ff/rew
> pauses that frequiently occur while the mediacodec decoder is reset
> and the inability to timestretch 1089/h.264 at 2x without frequent
> stuttering.
>
> My movie transcodes are h.265 so will be using mediacode decoding more
> going forward. I also mediacodec yesterday on 720p/mpeg2 at 1.75x and
> 1080i/h.264 at 1.5x. I hadn't done that in a while and wanted to
> check it out. I didn't notice any of the ff/rew pauses. Maybe Nvidia
> fixed something in their Oreo updates.
>
>> Since I do not use speedup or fast forward, my testing in those areas has
>> been minimal. AVSync2 changes to improve smoothness are likely moot when
>> using speedup.
> Probably 2/3 of what I watch is stretched to 1.25, 1.5, 1.75 and even
> 2x.
>
Ive been playing with some mods to avsync2 too.

1. Changed time fetch to a QElapsedTimer. I think this solves the
sporadic crazyness that Ive seen. This uses Monotonic time on those
systems that support it so  no NTP non monotonicness

2. I tried mediacodec with 1920x1080@25i h264 broadcast shows. This
plays much nicer and does not have the occasional 1/2 frame rate that
S/W decoding (4 cpus) + S/W deint has.

3. Smoothing the av delta always. This results in less timing jitter
which may or may not have any effect.

4. WaitForTime delays using a 2ms usleep chunks. Probably has no effect.
I thought this may affect SW dec #2 above but probably not.

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 19, 2019 at 02:13:54PM -0600, David Engel wrote:
> On Tue, Feb 19, 2019 at 01:53:26PM -0500, Peter Bennett wrote:
> > > 1. The avsync randomly goes out of phase for short periods (like Mark
> > > Spieth mentioned). I figured the CPU load on my Shield was on the
> > > edge and just couldn't quite keep at those times. The problem goes
> > > away completely after I turn off avsync2. I suspect the logs would
> > > show the same inabiltiy to correct that other logs have shown.
> > Comcast has no 1080i h264 channels. If you can give me more details, a
> > verbose playback log or sample video I can look into this. Does it happen
> > with Linux? Does it happen with mediacodec or software decode or both?
>
> I'll get you a sample. I have not tried this on Linux. I will try
> tonight. The problem is my only Linux frontend now is my development
> desktop. It's not exactly comfortable to use for real watching.

Peter, you should receive a link to the sample shortly. I won't be
able to test tonight if this particular recording goes in an out of
sync. I will try to get to it tomorrow or the next day.

> > > 2. I have my fast forward speeds set to 10x, 20x, 60x and 180x. 10x
> > > and 20x work normally. 60x and 180x have problems. A video frame is
> > > displayed and then there is a very long pause before another video
> > > frame is displayed. Basically those speeds are useless. Like above,
> > > the problem goes away completely after I turn off avsync2. I can
> > > provide logs for this if you want.
> > Is this only on shield? Where do you set these amounts? I seldom use fast
> > forward so I am not familiar with this.
>
> Yes, like above, only tested on Shields.

I was able to test this on Linux tonight. It didn't happen so it
looks like it could be Shield specific.

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

Peter,
FYI
I just discovered that current master in my case has no audio at for any playback speed different than x1.0.
Switching from avsync2 to to original avsync fixes problem so issue is within avsync2.
Should I play with some knobs in myth config or rather this is kind of bug?

My hw is ION2 with SPDIF to amplituner.

_______________________________________________
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 20/02/2019 14:36, Piotr Oniszczuk wrote:
>
> Peter,
> FYI
> I just discovered that current master in my case has no audio at for any playback speed different than x1.0.
> Switching from avsync2 to to original avsync fixes problem so issue is within avsync2.
> Should I play with some knobs in myth config or rather this is kind of bug?
>
> My hw is ION2 with SPDIF to amplituner.
>

Just tried this. I had silence for speedup, sound with slowdown.
Increased audio readahead to 200 ms and speedup works, but not
immediately - there's a pause while things get back in sync.

nVidia GT710, 415.27 rpmfusion FC28 driver. Still getting wrong aspect
ratio though, with single xscreen and 2 devices edge-to-edge.

master 543965

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

> Wiadomo?? napisana przez John Pilkington <johnpilk222@gmail.com> w dniu 20.02.2019, o godz. 16:22:
>
>
> Just tried this. I had silence for speedup, sound with slowdown. Increased audio readahead to 200 ms and speedup works, but not immediately - there's a pause while things get back in sync.
>

John,

Thx!
Indeed 300ms helps for me :-)

br

_______________________________________________
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/17/19 2:03 PM, David Engel wrote:
> 2. I have my fast forward speeds set to 10x, 20x, 60x and 180x. 10x
> and 20x work normally. 60x and 180x have problems. A video frame is
> displayed and then there is a very long pause before another video
> frame is displayed. Basically those speeds are useless. Like above,
> the problem goes away completely after I turn off avsync2. I can
> provide logs for this if you want.
I have committed a fix for FF/REW. At 120X it now works the same in
avsync and avsync2. On the shield with software decode and with h264
there are still delays of up to 1 second between frames, because it
seems to take a long time to decode each piece, which can be seen in the
logs. It is much better at this with mediacodec. With mpeg2 it is also
much better at 120x with software decode.

I suggest set the playback profile to only select software decode for
mpeg2 - to cater for the pixellating problem, and use mediacodec for others.

If this is OK I will cherry-pick it to v30 in a few days.

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/19/19 3:13 PM, David Engel wrote:
>>> I noticed a couple of other issues caused by avsync2 that I hadn't
>>> previously tied to it. I have one, 1080i, h.264 channel that I watch
>>> fairly regularly at >= 1.5x.
>>>
>>> 1. The avsync randomly goes out of phase for short periods (like Mark
>>> Spieth mentioned). I figured the CPU load on my Shield was on the
>>> edge and just couldn't quite keep at those times. The problem goes
>>> away completely after I turn off avsync2. I suspect the logs would
>>> show the same inabiltiy to correct that other logs have shown.
>> Comcast has no 1080i h264 channels. If you can give me more details, a
>> verbose playback log or sample video I can look into this. Does it happen
>> with Linux? Does it happen with mediacodec or software decode or both?
> I'll get you a sample. I have not tried this on Linux. I will try
> tonight. The problem is my only Linux frontend now is my development
> desktop. It's not exactly comfortable to use for real watching.
>
I don't know what to look for. What are the symptoms of going out of
phase? Do I have to watch 30 minutes of skiing at 1.5x to see it? The
video you supplied seems fine from watching a bit at various speeds. Lip
sync on a skiing video is probably not relevant so I don't know what the
problem is.

Peter

On Sun, Feb 24, 2019 at 02:42:08PM -0500, Peter Bennett wrote:
>
>
> On 2/17/19 2:03 PM, David Engel wrote:
> > 2. I have my fast forward speeds set to 10x, 20x, 60x and 180x. 10x
> > and 20x work normally. 60x and 180x have problems. A video frame is
> > displayed and then there is a very long pause before another video
> > frame is displayed. Basically those speeds are useless. Like above,
> > the problem goes away completely after I turn off avsync2. I can
> > provide logs for this if you want.
> I have committed a fix for FF/REW. At 120X it now works the same in avsync
> and avsync2. On the shield with software decode and with h264 there are
> still delays of up to 1 second between frames, because it seems to take a
> long time to decode each piece, which can be seen in the logs. It is much
> better at this with mediacodec. With mpeg2 it is also much better at 120x
> with software decode.

I saw the fix and built it but haven't tested it yet.

> I suggest set the playback profile to only select software decode for mpeg2
> - to cater for the pixellating problem, and use mediacodec for others.

That's what I'm going to do.

> If this is OK I will cherry-pick it to v30 in a few days.

OK.

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 Sun, Feb 24, 2019 at 03:00:48PM -0500, Peter Bennett wrote:
>
>
> On 2/19/19 3:13 PM, David Engel wrote:
> > > > I noticed a couple of other issues caused by avsync2 that I hadn't
> > > > previously tied to it. I have one, 1080i, h.264 channel that I watch
> > > > fairly regularly at >= 1.5x.
> > > >
> > > > 1. The avsync randomly goes out of phase for short periods (like Mark
> > > > Spieth mentioned). I figured the CPU load on my Shield was on the
> > > > edge and just couldn't quite keep at those times. The problem goes
> > > > away completely after I turn off avsync2. I suspect the logs would
> > > > show the same inabiltiy to correct that other logs have shown.
> > > Comcast has no 1080i h264 channels. If you can give me more details, a
> > > verbose playback log or sample video I can look into this. Does it happen
> > > with Linux? Does it happen with mediacodec or software decode or both?
> > I'll get you a sample. I have not tried this on Linux. I will try
> > tonight. The problem is my only Linux frontend now is my development
> > desktop. It's not exactly comfortable to use for real watching.
> >
> I don't know what to look for. What are the symptoms of going out of phase?
> Do I have to watch 30 minutes of skiing at 1.5x to see it? The video you

Yep, watch and wait. There's not predicting when it will happen. It
just does.

David

> supplied seems fine from watching a bit at various speeds. Lip sync on a
> skiing video is probably not relevant so I don't know what the problem is.

There are occasionally interviews at the end.

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/24/19 7:02 PM, David Engel wrote:
>> I don't know what to look for. What are the symptoms of going out of phase?
>> Do I have to watch 30 minutes of skiing at 1.5x to see it? The video you
> Yep, watch and wait. There's not predicting when it will happen. It
> just does.
I don't know what I am looking for. What happens?
> David
>

On Mon, Feb 25, 2019 at 08:50:25AM -0500, Peter Bennett wrote:
>
>
> On 2/24/19 7:02 PM, David Engel wrote:
> > > I don't know what to look for. What are the symptoms of going out of phase?
> > > Do I have to watch 30 minutes of skiing at 1.5x to see it? The video you
> > Yep, watch and wait. There's not predicting when it will happen. It
> > just does.
> I don't know what I am looking for. What happens?

Playback gets stuttery for a short while. My assumption has been that
avsync2 just gets out of whack for whatever reason.

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/25/19 12:32 PM, David Engel wrote:
> On Mon, Feb 25, 2019 at 08:50:25AM -0500, Peter Bennett wrote:
>>
>> On 2/24/19 7:02 PM, David Engel wrote:
>>>> I don't know what to look for. What are the symptoms of going out of phase?
>>>> Do I have to watch 30 minutes of skiing at 1.5x to see it? The video you
>>> Yep, watch and wait. There's not predicting when it will happen. It
>>> just does.
>> I don't know what I am looking for. What happens?
> Playback gets stuttery for a short while. My assumption has been that
> avsync2 just gets out of whack for whatever reason.
>
> David
I watched that entire 30 minute video, part at 1.5x and part at 2x. I
did not see any stuttering. I assume by stuttering you refer to the
audio breaking up. I did not see anything unusual. I used software
decode (opengl slim) on the shield for this test.

Please make sure you have Music Choice unchecked.

Perhaps you can get a verbose playback log of when it happens.

Maybe you can give me more details - such as what does the video do and
what does the audio do, described as if to a small child without using
terms like stuttering or out of phase. does the video stop? does the
video go slower? does the video go slow then fast then slow again? same
sort of questions about the audio.

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 Mon, Feb 25, 2019 at 06:58:27PM -0500, Peter Bennett wrote:
>
>
> On 2/25/19 12:32 PM, David Engel wrote:
> > On Mon, Feb 25, 2019 at 08:50:25AM -0500, Peter Bennett wrote:
> > >
> > > On 2/24/19 7:02 PM, David Engel wrote:
> > > > > I don't know what to look for. What are the symptoms of going out of phase?
> > > > > Do I have to watch 30 minutes of skiing at 1.5x to see it? The video you
> > > > Yep, watch and wait. There's not predicting when it will happen. It
> > > > just does.
> > > I don't know what I am looking for. What happens?
> > Playback gets stuttery for a short while. My assumption has been that
> > avsync2 just gets out of whack for whatever reason.
> >
> > David
> I watched that entire 30 minute video, part at 1.5x and part at 2x. I did
> not see any stuttering. I assume by stuttering you refer to the audio
> breaking up. I did not see anything unusual. I used software decode (opengl
> slim) on the shield for this test.

The audio stays fine. It is the video that gets choppy. I almost
always use opengl normal (kernel deinterlacer).

> Please make sure you have Music Choice unchecked.

It's not checked.

> Perhaps you can get a verbose playback log of when it happens.

I have not watched that particular recording yet. I will this week.
When I do, I'll capture a log if I see the problem. I'll also let you
know if I don't see the problem with that recording.

> Maybe you can give me more details - such as what does the video do and what
> does the audio do, described as if to a small child without using terms like
> stuttering or out of phase. does the video stop? does the video go slower?
> does the video go slow then fast then slow again? same sort of questions
> about the audio.

The audio plays normally and the video gets choppy. By choppy, I mean
the video starts and stops and appears to skip small parts while the
autio keeps playing.

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 Mon, Feb 25, 2019 at 08:07:43PM -0600, David Engel wrote:
> On Mon, Feb 25, 2019 at 06:58:27PM -0500, Peter Bennett wrote:
> > I watched that entire 30 minute video, part at 1.5x and part at 2x. I did
> > not see any stuttering. I assume by stuttering you refer to the audio
> > breaking up. I did not see anything unusual. I used software decode (opengl
> > slim) on the shield for this test.
>
> The audio stays fine. It is the video that gets choppy. I almost
> always use opengl normal (kernel deinterlacer).
>
> > Please make sure you have Music Choice unchecked.
>
> It's not checked.
>
> > Perhaps you can get a verbose playback log of when it happens.
>
> I have not watched that particular recording yet. I will this week.
> When I do, I'll capture a log if I see the problem. I'll also let you
> know if I don't see the problem with that recording.
>
> > Maybe you can give me more details - such as what does the video do and what
> > does the audio do, described as if to a small child without using terms like
> > stuttering or out of phase. does the video stop? does the video go slower?
> > does the video go slow then fast then slow again? same sort of questions
> > about the audio.
>
> The audio plays normally and the video gets choppy. By choppy, I mean
> the video starts and stops and appears to skip small parts while the
> autio keeps playing.

I watched the whole recording I sent you last night and didn't see the
problem. The next time it happens, I will capture some logs and save
the recording for you.

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 3/1/2019 5:43 AM, David Engel wrote:
> On Mon, Feb 25, 2019 at 08:07:43PM -0600, David Engel wrote:
>> On Mon, Feb 25, 2019 at 06:58:27PM -0500, Peter Bennett wrote:
>>> I watched that entire 30 minute video, part at 1.5x and part at 2x. I did
>>> not see any stuttering. I assume by stuttering you refer to the audio
>>> breaking up. I did not see anything unusual. I used software decode (opengl
>>> slim) on the shield for this test.
>> The audio stays fine. It is the video that gets choppy. I almost
>> always use opengl normal (kernel deinterlacer).
>>
>>> Please make sure you have Music Choice unchecked.
>> It's not checked.
>>
>>> Perhaps you can get a verbose playback log of when it happens.
>> I have not watched that particular recording yet. I will this week.
>> When I do, I'll capture a log if I see the problem. I'll also let you
>> know if I don't see the problem with that recording.
>>
>>> Maybe you can give me more details - such as what does the video do and what
>>> does the audio do, described as if to a small child without using terms like
>>> stuttering or out of phase. does the video stop? does the video go slower?
>>> does the video go slow then fast then slow again? same sort of questions
>>> about the audio.
>> The audio plays normally and the video gets choppy. By choppy, I mean
>> the video starts and stops and appears to skip small parts while the
>> autio keeps playing.
> I watched the whole recording I sent you last night and didn't see the
> problem. The next time it happens, I will capture some logs and save
> the recording for you.

I watched too last night with the patch using mediacodec however I had
it on old AVSync but the finish early issue still existed which is
strange too.

Will have to repeat tonight with AVSync2.

I can make some programs available again if it helps Peter. Use my
previous link but use recordings/1020_20190228080000.ts (news last
night) or some of the other recent ones. The one listed is guaranteed to
show the issue. 1020 is HD and 1021 is SD.

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/28/19 4:10 PM, Mark Spieth wrote:
> I watched too last night with the patch using mediacodec however I had
> it on old AVSync but the finish early issue still existed which is
> strange too.
>
The "finish early" fix only applies to AVSync2. See comment 1 in the ticket.
> Will have to repeat tonight with AVSync2.
>
> I can make some programs available again if it helps Peter. Use my
> previous link but use recordings/1020_20190228080000.ts (news last
> night) or some of the other recent ones. The one listed is guaranteed
> to show the issue. 1020 is HD and 1021 is SD.

I will try that one. Does it always glitch in the same place?

I did see a period of stuttery playback during David's recording while I
was testing the finish earky fix. The thing is, during the stuttery
playback the system was unresponsive to the remote. This indicates that
something on the system was pre-empting mythfrontend.

What springs to mind is that it may have been doing a java full garbage
collect operation. My experience with java (non-android) is you need to
be careful to avoid full garbage collect operations during a real-time
process like playback. Mediacodec decoding goes through java code so it
may be a possibility. I don't know how you adjust the garbage collect
settings on android, on regular systems it is via parameters on the java
command line.

Do you notice that it is unresponsive to the remote while the stuttering
takes place?

Peter

On 3/2/2019 7:21 AM, Peter Bennett wrote:
>
>
> On 2/28/19 4:10 PM, Mark Spieth wrote:
>> I watched too last night with the patch using mediacodec however I
>> had it on old AVSync but the finish early issue still existed which
>> is strange too.
>>
> The "finish early" fix only applies to AVSync2. See comment 1 in the
> ticket.
>> Will have to repeat tonight with AVSync2.
>>
>> I can make some programs available again if it helps Peter. Use my
>> previous link but use recordings/1020_20190228080000.ts (news last
>> night) or some of the other recent ones. The one listed is guaranteed
>> to show the issue. 1020 is HD and 1021 is SD.
>
> I will try that one. Does it always glitch in the same place?

I dont see any glitches at all during playback of any of these programs.
The time is just wrong but this also does not happen linearly. My test
last night with AVSync2 worked well except I had mythcommflag suck 21g
out of my ram bringing the whole backend to a grinding halt until I
deleted the errant process, but thats another/different problem.
Playback on the shield paused at that period but the timestamp was
correct at that point. I thought originally that the deletemap search
for the timestamp had an infinite loop but I suspect that is wrong, but
more testing will ensue today.

There are others too. anything with a channel number in 10xx is a dvbt
recording. I have left some around for this purpose (testing/validation).

>
> I did see a period of stuttery playback during David's recording while
> I was testing the finish earky fix. The thing is, during the stuttery
> playback the system was unresponsive to the remote. This indicates
> that something on the system was pre-empting mythfrontend.
>
I had a different problem the other day where with mediacodec with both
AVSync and AVSync2, both exhibited a play 1sec then skip 1 sec type
behaviour which was really weird. Unfortunately I deleted that without
thinking after playing successfuly with SW decode. This may be the same
as the stuttery playback but not sure. Only ever happened once, on a
program I watch weekly.

> What springs to mind is that it may have been doing a java full
> garbage collect operation. My experience with java (non-android) is
> you need to be careful to avoid full garbage collect operations during
> a real-time process like playback. Mediacodec decoding goes through
> java code so it may be a possibility. I don't know how you adjust the
> garbage collect settings on android, on regular systems it is via
> parameters on the java command line.
I dont either, but if this was a problem, other apps would have seen
this too. Unlikely cause.
>
> Do you notice that it is unresponsive to the remote while the
> stuttering takes place?
>
No. But I have only seen it once.

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 3/1/19 5:28 PM, Mark Spieth wrote:
> On 3/2/2019 7:21 AM, Peter Bennett wrote:
>>
>>
>> On 2/28/19 4:10 PM, Mark Spieth wrote:
>>> I watched too last night with the patch using mediacodec however I
>>> had it on old AVSync but the finish early issue still existed which
>>> is strange too.
>>>
>> The "finish early" fix only applies to AVSync2. See comment 1 in the
>> ticket.
>>> Will have to repeat tonight with AVSync2.
>>>
>>> I can make some programs available again if it helps Peter. Use my
>>> previous link but use recordings/1020_20190228080000.ts (news last
>>> night) or some of the other recent ones. The one listed is
>>> guaranteed to show the issue. 1020 is HD and 1021 is SD.
>>
>> I will try that one. Does it always glitch in the same place?
>
> I dont see any glitches at all during playback of any of these
> programs. The time is just wrong but this also does not happen
> linearly. My test last night with AVSync2 worked well except I had
> mythcommflag suck 21g out of my ram bringing the whole backend to a
> grinding halt until I deleted the errant process, but thats
> another/different problem. Playback on the shield paused at that
> period but the timestamp was correct at that point. I thought
> originally that the deletemap search for the timestamp had an infinite
> loop but I suspect that is wrong, but more testing will ensue today.
>
> There are others too. anything with a channel number in 10xx is a dvbt
> recording. I have left some around for this purpose (testing/validation).
>
>>
>> I did see a period of stuttery playback during David's recording
>> while I was testing the finish earky fix. The thing is, during the
>> stuttery playback the system was unresponsive to the remote. This
>> indicates that something on the system was pre-empting mythfrontend.
>>
> I had a different problem the other day where with mediacodec with
> both AVSync and AVSync2, both exhibited a play 1sec then skip 1 sec
> type behaviour which was really weird. Unfortunately I deleted that
> without thinking after playing successfuly with SW decode. This may be
> the same as the stuttery playback but not sure. Only ever happened
> once, on a program I watch weekly.
>
>> What springs to mind is that it may have been doing a java full
>> garbage collect operation. My experience with java (non-android) is
>> you need to be careful to avoid full garbage collect operations
>> during a real-time process like playback. Mediacodec decoding goes
>> through java code so it may be a possibility. I don't know how you
>> adjust the garbage collect settings on android, on regular systems it
>> is via parameters on the java command line.
> I dont either, but if this was a problem, other apps would have seen
> this too. Unlikely cause.
>>
>> Do you notice that it is unresponsive to the remote while the
>> stuttering takes place?
>>
> No. But I have only seen it once.
>
> Mark
>
>
I tried your news program at 1.5x. At 6:42 the audio became way out of
sync with the video. Repeating the test and going to 6:42 did not show
it again, so it is not something special in the video causing it.  I
will try it again and see if I can track down the problem.

It may be something that goes away when we have direct rendering. It
could be related to the fact that some 75 frames per second are being
copied into memory. Even with some frames being skipped on display to
keep up, it remains that they are still all copied to memory. I had
thought of inserting some code into the decoder so that frames that are
destined to be skipped are not copied to memory, but if we get direct
rendering that would become moot, so I decided to wait for direct rendering.

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 3/2/2019 10:50 AM, Peter Bennett wrote:
>
>
> On 3/1/19 5:28 PM, Mark Spieth wrote:
>> On 3/2/2019 7:21 AM, Peter Bennett wrote:
>>>
>>>
>>> On 2/28/19 4:10 PM, Mark Spieth wrote:
>>>> I watched too last night with the patch using mediacodec however I
>>>> had it on old AVSync but the finish early issue still existed which
>>>> is strange too.
>>>>
>>> The "finish early" fix only applies to AVSync2. See comment 1 in the
>>> ticket.
>>>> Will have to repeat tonight with AVSync2.
>>>>
>>>> I can make some programs available again if it helps Peter. Use my
>>>> previous link but use recordings/1020_20190228080000.ts (news last
>>>> night) or some of the other recent ones. The one listed is
>>>> guaranteed to show the issue. 1020 is HD and 1021 is SD.
>>>
>>> I will try that one. Does it always glitch in the same place?
>>
>> I dont see any glitches at all during playback of any of these
>> programs. The time is just wrong but this also does not happen
>> linearly. My test last night with AVSync2 worked well except I had
>> mythcommflag suck 21g out of my ram bringing the whole backend to a
>> grinding halt until I deleted the errant process, but thats
>> another/different problem. Playback on the shield paused at that
>> period but the timestamp was correct at that point. I thought
>> originally that the deletemap search for the timestamp had an
>> infinite loop but I suspect that is wrong, but more testing will
>> ensue today.
>>
>> There are others too. anything with a channel number in 10xx is a
>> dvbt recording. I have left some around for this purpose
>> (testing/validation).
>>
>>>
>>> I did see a period of stuttery playback during David's recording
>>> while I was testing the finish earky fix. The thing is, during the
>>> stuttery playback the system was unresponsive to the remote. This
>>> indicates that something on the system was pre-empting mythfrontend.
>>>
>> I had a different problem the other day where with mediacodec with
>> both AVSync and AVSync2, both exhibited a play 1sec then skip 1 sec
>> type behaviour which was really weird. Unfortunately I deleted that
>> without thinking after playing successfuly with SW decode. This may
>> be the same as the stuttery playback but not sure. Only ever happened
>> once, on a program I watch weekly.
>>
>>> What springs to mind is that it may have been doing a java full
>>> garbage collect operation. My experience with java (non-android) is
>>> you need to be careful to avoid full garbage collect operations
>>> during a real-time process like playback. Mediacodec decoding goes
>>> through java code so it may be a possibility. I don't know how you
>>> adjust the garbage collect settings on android, on regular systems
>>> it is via parameters on the java command line.
>> I dont either, but if this was a problem, other apps would have seen
>> this too. Unlikely cause.
>>>
>>> Do you notice that it is unresponsive to the remote while the
>>> stuttering takes place?
>>>
>> No. But I have only seen it once.
>>
>> Mark
>>
>>
> I tried your news program at 1.5x. At 6:42 the audio became way out of
> sync with the video. Repeating the test and going to 6:42 did not show
> it again, so it is not something special in the video causing it.  I
> will try it again and see if I can track down the problem.
>
> It may be something that goes away when we have direct rendering. It
> could be related to the fact that some 75 frames per second are being
> copied into memory. Even with some frames being skipped on display to
> keep up, it remains that they are still all copied to memory. I had
> thought of inserting some code into the decoder so that frames that
> are destined to be skipped are not copied to memory, but if we get
> direct rendering that would become moot, so I decided to wait for
> direct rendering.

The time issue happens at the same rate irrespective of the playback
speed. I suspect your problem may be an NTP twiddle which would stuff
things right up since I think only video uses system time. Thats why I
implemented QElapseTimer to do timing since it uses monotonic CPU time.
I can post a patch if you like.

Also I have a stuttering program again. Its recording right now. When
complete it will be 6.5h but is only 25m in ATM. I can keep it if you
want but normally I delete straight after watching, which I'm doing now.

1013_20190302020000.ts

Stuttering occurs right at the start of the program with mediacodec
decoder. SW dec is fine. Either avsync method exhibits this so its
mediacodec related.

HTH

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 3/1/19 9:32 PM, Mark Spieth wrote:
> The time issue happens at the same rate irrespective of the playback
> speed. I suspect your problem may be an NTP twiddle which would stuff
> things right up since I think only video uses system time. Thats why I
> implemented QElapseTimer to do timing since it uses monotonic CPU
> time. I can post a patch if you like.
>
Please post a patch or email it.
> Also I have a stuttering program again. Its recording right now. When
> complete it will be 6.5h but is only 25m in ATM. I can keep it if you
> want but normally I delete straight after watching, which I'm doing now.
>
> 1013_20190302020000.ts
>
> Stuttering occurs right at the start of the program with mediacodec
> decoder. SW dec is fine. Either avsync method exhibits this so its
> mediacodec related.
>
I am hoping that the direct render fixes it. Mark K said that he will be
looking into direct render. Anyway I will download some of that file and
see if I can do anything to understand what is happening,

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 Sat, Mar 2, 2019, 3:31 PM Peter Bennett <pb.mythtv@gmail.com> wrote:

> > Stuttering occurs right at the start of the program with mediacodec
> > decoder. SW dec is fine. Either avsync method exhibits this so its
> > mediacodec related.
> >
> I am hoping that the direct render fixes it. Mark K said that he will be
> looking into direct render. Anyway I will download some of that file and
> see if I can do anything to understand what is happening,
>

Has anyone tried increasing the number of mediacodec video buffers? Its
only 8 at the moment. I had similar problems with VideoToolBox decoding
this week and increasing the buffer count was the key. 8 gives you very
little headroom for the simplest of system glitches.

Direct render is getting there - only problem is it crashes as soon as it
tries to display anything:)

Regards, Mark

>

On 3/3/2019 2:58 AM, Mark Kendall wrote:
>
>
> On Sat, Mar 2, 2019, 3:31 PM Peter Bennett <pb.mythtv@gmail.com
> <mailto:pb.mythtv@gmail.com>> wrote:
>
> > Stuttering occurs right at the start of the program with mediacodec
> > decoder. SW dec is fine. Either avsync method exhibits this so its
> > mediacodec related.
> >
> I am hoping that the direct render fixes it. Mark K said that he
> will be
> looking into direct render. Anyway I will download some of that
> file and
> see if I can do anything to understand what is happening,
>
>
> Has anyone tried increasing the number of mediacodec video buffers?
> Its only 8 at the moment. I had similar problems with VideoToolBox
> decoding this week and increasing the buffer count was the key. 8
> gives you very little headroom for the simplest of system glitches.
>
> Direct render is getting there - only problem is it crashes as soon as
> it tries to display anything:)
>
Mark,

I have tried to find this but failed :-(. where is this
constant/setting? I would like to try it as I suspect it fixes the
timing issue we are currently seeing with mediacodec.

Thanks

Mark

On 3/2/19 10:58 AM, Mark Kendall wrote:
>
>
> On Sat, Mar 2, 2019, 3:31 PM Peter Bennett <pb.mythtv@gmail.com
> <mailto:pb.mythtv@gmail.com>> wrote:
>
> > Stuttering occurs right at the start of the program with mediacodec
> > decoder. SW dec is fine. Either avsync method exhibits this so its
> > mediacodec related.
> >
> I am hoping that the direct render fixes it. Mark K said that he
> will be
> looking into direct render. Anyway I will download some of that
> file and
> see if I can do anything to understand what is happening,
>
>
> Has anyone tried increasing the number of mediacodec video buffers?
> Its only 8 at the moment. I had similar problems with VideoToolBox
> decoding this week and increasing the buffer count was the key. 8
> gives you very little headroom for the simplest of system glitches.
>
> Direct render is getting there - only problem is it crashes as soon as
> it tries to display anything:)
>
> Regards, Mark
>
> _______________________________________________
>
I tried the video that gives the problem. It is H264 interlaced.
Normally, mediacodec on shield should deinterlace it and hand it to
MythTV as progressive. MythTV is seeing this as progressive switching to
interlaced and back to progressive again about once every second. This
causes the OpenGL rendering and deinterlacing to be re-initialized twice
every second. It is not surprising that this results in jerky playback.

I will trace through it and see whether ffmpeg is actually switching it
back and forth between interlaced and progressive, and whether anything
can be done about it.

Regarding the video buffers - I had to set that low value, otherwise
playback would be terminated by android on the shield. Android has very
restrictive memory usage rules, and does not hesitate to shut down any
process that uses more than it thinks is reasonable. 8 buffers seemed to
be the best value that worked well. I do not think the video buffers are
the cause of the jerkiness.

Peter

On 3/2/19 5:03 PM, Mark Spieth wrote:
> On 3/3/2019 2:58 AM, Mark Kendall wrote:
>>
>>
>> On Sat, Mar 2, 2019, 3:31 PM Peter Bennett <pb.mythtv@gmail.com
>> <mailto:pb.mythtv@gmail.com>> wrote:
>>
>> > Stuttering occurs right at the start of the program with
>> mediacodec
>> > decoder. SW dec is fine. Either avsync method exhibits this so its
>> > mediacodec related.
>> >
>> I am hoping that the direct render fixes it. Mark K said that he
>> will be
>> looking into direct render. Anyway I will download some of that
>> file and
>> see if I can do anything to understand what is happening,
>>
>>
>> Has anyone tried increasing the number of mediacodec video buffers?
>> Its only 8 at the moment. I had similar problems with VideoToolBox
>> decoding this week and increasing the buffer count was the key. 8
>> gives you very little headroom for the simplest of system glitches.
>>
>> Direct render is getting there - only problem is it crashes as soon
>> as it tries to display anything:)
>>
> Mark,
>
> I have tried to find this but failed :-(. where is this
> constant/setting? I would like to try it as I suspect it fixes the
> timing issue we are currently seeing with mediacodec.
>
> Thanks
>
> Mark
>
>

It is in VideoOutputOpenGL::CreateBuffers - however as I mentioned in my
previous email, it seems the problem is with mis-detection of interlaced
versus progressive, and changing the video buffers will likely cause
android to terminate the app

On 3/2/19 5:35 PM, Peter Bennett wrote:
>
>
> On 3/2/19 5:03 PM, Mark Spieth wrote:
>> On 3/3/2019 2:58 AM, Mark Kendall wrote:
>>>
>>>
>>> On Sat, Mar 2, 2019, 3:31 PM Peter Bennett <pb.mythtv@gmail.com
>>> <mailto:pb.mythtv@gmail.com>> wrote:
>>>
>>> > Stuttering occurs right at the start of the program with
>>> mediacodec
>>> > decoder. SW dec is fine. Either avsync method exhibits this so
>>> its
>>> > mediacodec related.
>>> >
>>> I am hoping that the direct render fixes it. Mark K said that he
>>> will be
>>> looking into direct render. Anyway I will download some of that
>>> file and
>>> see if I can do anything to understand what is happening,
>>>
>>>
>>> Has anyone tried increasing the number of mediacodec video buffers?
>>> Its only 8 at the moment. I had similar problems with VideoToolBox
>>> decoding this week and increasing the buffer count was the key. 8
>>> gives you very little headroom for the simplest of system glitches.
>>>
>>> Direct render is getting there - only problem is it crashes as soon
>>> as it tries to display anything:)
>>>
>> Mark,
>>
>> I have tried to find this but failed :-(. where is this
>> constant/setting? I would like to try it as I suspect it fixes the
>> timing issue we are currently seeing with mediacodec.
>>
>> Thanks
>>
>> Mark
>>
>>
>
> It is in VideoOutputOpenGL::CreateBuffers - however as I mentioned in
> my previous email, it seems the problem is with mis-detection of
> interlaced versus progressive, and changing the video buffers will
> likely cause android to terminate the app
I found the problem with the car racing video from Mark - misdetection
of frame rate - see patch in ticket
https://code.mythtv.org/trac/ticket/13419
Peter