Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. MythTV>
  3. Dev
AVSync in master, Normal decoding, vga monitor and built-in audio analog stereo
johnpilk222 at gmail
Dec 9, 2019, 10:46 AM
Post #1 of 17 (3091 views)
Permalink
Hi Mark, Peter, Tim et al...

I'm now running b5edda1b06e, today's master, under el7 with hardware as
in the subject.

A recording that allows good sensory evaluation of a/v sync shows
noticeable drift that is not evident from the -v playback log.

The same recording plays with perfect a/v sync via the MythTV DLNA
server on my TV

This sample of the log shows a higher rate of frame-dropping than the
average for that recording. It suggests to me that the result of
dropping a frame may not be getting through to the sync filter input. I
first reported sync drift on 16 Nov, and IIRC I first noticed it a day
or two earlier. AVSync2 increment is 1 ms.

HTH,

John P

{{{

2019-12-09 18:19:49.635638 I Player(5): dropping frame to catch up,
lateness=39890 usec
2019-12-09 18:19:49.793242 I Player(5): dropping frame to catch up,
lateness=38490 usec
2019-12-09 18:19:49.832012 I Player(5): AV Sync: Audio ahead by 28 ms
2019-12-09 18:19:49.960731 I Player(5): dropping frame to catch up,
lateness=48985 usec
2019-12-09 18:19:49.988455 I Player(5): AV Sync: Audio ahead by 24 ms
2019-12-09 18:19:50.054778 I Player(5): AV Sync: Audio ahead by 24 ms
2019-12-09 18:19:50.116016 I Player(5): dropping frame to catch up,
lateness=47266 usec
2019-12-09 18:19:50.156979 I Player(5): AV Sync: Audio ahead by 33 ms
2019-12-09 18:19:50.216963 I Player(5): dropping frame to catch up,
lateness=30218 usec
2019-12-09 18:19:50.378709 I Player(5): dropping frame to catch up,
lateness=32955 usec
2019-12-09 18:19:50.542979 I Player(5): dropping frame to catch up,
lateness=38217 usec
2019-12-09 18:19:50.700887 I Player(5): dropping frame to catch up,
lateness=37134 usec
2019-12-09 18:19:50.861823 I Player(5): dropping frame to catch up,
lateness=39076 usec
2019-12-09 18:19:51.015041 I Player(5): dropping frame to catch up,
lateness=32288 usec
2019-12-09 18:19:51.172908 I Player(5): dropping frame to catch up,
lateness=31159 usec
2019-12-09 18:19:52.062073 I Player(5): AV Sync: Audio behind by 1 ms
2019-12-09 18:19:52.889115 I Player(5): AV Sync: Audio ahead by 24 ms
2019-12-09 18:19:52.921252 I Player(5): AV Sync: Audio ahead by 23 ms
2019-12-09 18:19:52.992925 I Player(5): FPS: 24.94 Mean: 40102
Std.Dev: 18410 CPUs: 91% 91%
2019-12-09 18:19:56.984290 I Player(5): FPS: 25.06 Mean: 39909
Std.Dev: 1221 CPUs: 81% 78%
2019-12-09 18:20:00.984315 I Player(5): FPS: 25.00 Mean: 39996
Std.Dev: 1200 CPUs: 80% 79%
2019-12-09 18:20:01.868788 I Player(5): dropping frame to catch up,
lateness=66031 usec
2019-12-09 18:20:01.901175 I Player(5): AV Sync: Audio ahead by 57 ms
2019-12-09 18:20:01.940942 I Player(5): AV Sync: Audio ahead by 39 ms
2019-12-09 18:20:01.977668 I Player(5): AV Sync: Audio ahead by 35 ms
2019-12-09 18:20:02.011394 I Player(5): AV Sync: Audio ahead by 29 ms
2019-12-09 18:20:02.045813 I Player(5): AV Sync: Audio ahead by 24 ms

)))
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: AVSync in master, Normal decoding, vga monitor and built-in audio analog stereo [ In reply to ]
pb.mythtv at gmail
Dec 9, 2019, 12:20 PM
Post #2 of 17 (3090 views)
Permalink
On 12/9/19 1:46 PM, John Pilkington wrote:
> Hi Mark, Peter, Tim et al...
>
> I'm now running b5edda1b06e, today's master, under el7 with hardware
> as in the subject.
>
> A recording that allows good sensory evaluation of a/v sync shows
> noticeable drift that is not evident from the -v playback log.
>
> The same recording plays with perfect a/v sync via the MythTV DLNA
> server on my TV
>
> This sample of the log shows a higher rate of frame-dropping than the
> average for that recording.  It suggests to me that the result of
> dropping a frame may not be getting through to the sync filter input. 
> I first reported sync drift on 16 Nov, and IIRC I first noticed it a
> day or two earlier.  AVSync2 increment is 1 ms.
>
> HTH,
>
> John P
>
> {{{
>
> 2019-12-09 18:19:49.635638 I  Player(5): dropping frame to catch up,
> lateness=39890 usec
> 2019-12-09 18:19:49.793242 I  Player(5): dropping frame to catch up,
> lateness=38490 usec
> 2019-12-09 18:19:49.832012 I  Player(5): AV Sync: Audio ahead by 28 ms
> 2019-12-09 18:19:49.960731 I  Player(5): dropping frame to catch up,
> lateness=48985 usec
> 2019-12-09 18:19:49.988455 I  Player(5): AV Sync: Audio ahead by 24 ms
> 2019-12-09 18:19:50.054778 I  Player(5): AV Sync: Audio ahead by 24 ms
> 2019-12-09 18:19:50.116016 I  Player(5): dropping frame to catch up,
> lateness=47266 usec
> 2019-12-09 18:19:50.156979 I  Player(5): AV Sync: Audio ahead by 33 ms
> 2019-12-09 18:19:50.216963 I  Player(5): dropping frame to catch up,
> lateness=30218 usec
> 2019-12-09 18:19:50.378709 I  Player(5): dropping frame to catch up,
> lateness=32955 usec
> 2019-12-09 18:19:50.542979 I  Player(5): dropping frame to catch up,
> lateness=38217 usec
> 2019-12-09 18:19:50.700887 I  Player(5): dropping frame to catch up,
> lateness=37134 usec
> 2019-12-09 18:19:50.861823 I  Player(5): dropping frame to catch up,
> lateness=39076 usec
> 2019-12-09 18:19:51.015041 I  Player(5): dropping frame to catch up,
> lateness=32288 usec
> 2019-12-09 18:19:51.172908 I  Player(5): dropping frame to catch up,
> lateness=31159 usec
> 2019-12-09 18:19:52.062073 I  Player(5): AV Sync: Audio behind by 1 ms
> 2019-12-09 18:19:52.889115 I  Player(5): AV Sync: Audio ahead by 24 ms
> 2019-12-09 18:19:52.921252 I  Player(5): AV Sync: Audio ahead by 23 ms
> 2019-12-09 18:19:52.992925 I  Player(5): FPS:   24.94 Mean: 40102
> Std.Dev: 18410 CPUs: 91% 91%
> 2019-12-09 18:19:56.984290 I  Player(5): FPS:   25.06 Mean: 39909
> Std.Dev:  1221 CPUs: 81% 78%
> 2019-12-09 18:20:00.984315 I  Player(5): FPS:   25.00 Mean: 39996
> Std.Dev:  1200 CPUs: 80% 79%
> 2019-12-09 18:20:01.868788 I  Player(5): dropping frame to catch up,
> lateness=66031 usec
> 2019-12-09 18:20:01.901175 I  Player(5): AV Sync: Audio ahead by 57 ms
> 2019-12-09 18:20:01.940942 I  Player(5): AV Sync: Audio ahead by 39 ms
> 2019-12-09 18:20:01.977668 I  Player(5): AV Sync: Audio ahead by 35 ms
> 2019-12-09 18:20:02.011394 I  Player(5): AV Sync: Audio ahead by 29 ms
> 2019-12-09 18:20:02.045813 I  Player(5): AV Sync: Audio ahead by 24 ms
>
> )))
> _______________________________________________

Audio ahead is worse for the user experience than audio behind. However,
per the wikipedia
(https://en.wikipedia.org/wiki/Audio-to-video_synchronization#Recommendations)
expert viewers could not detect anything less than 125ms behind to 45ms
ahead. Based in that I do not correct anything that is less than 40ms
off. You should not be able to detect errors of 39ms. I suspect that
your sound equipment or the linux alsa component may be giving incorrect
information back to mythtv about the state of audio output and amount of
audio being buffered.

With regard to dropping frames not getting through, each frame of audio
and each frame of video has a timestamp, and these are matched up. So
regardless of dropping video or audio, the timestamps of the following
frames will be used to sync up.

Peter
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: AVSync in master, Normal decoding, vga monitor and built-in audio analog stereo [ In reply to ]
gregorio.gervasio at gmail
Dec 9, 2019, 1:20 PM
Post #3 of 17 (3090 views)
Permalink
>>>>> John Pilkington writes:

> Hi Mark, Peter, Tim et al...
> I'm now running b5edda1b06e, today's master, under el7 with hardware
> as in the subject.

> A recording that allows good sensory evaluation of a/v sync shows
> noticeable drift that is not evident from the -v playback log.
[...]

At least for me, it seems like the sync problems (where audio
runs ahead of video) are only happening with 1080i (MPEG-2) content and
only when I use the double-rate software deinterlacers. If I disable
double-rate deinterlacing or if I enable "Prefer OpenGL deinterlacers",
I don't see the problem. I'll need to dig deeper into it to be sure,
though ...

--
Gregorio Gervasio Jr. gregorio.gervasio@gmail.com
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: AVSync in master, Normal decoding, vga monitor and built-in audio analog stereo [ In reply to ]
johnpilk222 at gmail
Dec 9, 2019, 1:21 PM
Post #4 of 17 (3090 views)
Permalink
On 09/12/2019 20:20, Peter Bennett wrote:
>
>
> On 12/9/19 1:46 PM, John Pilkington wrote:
>> Hi Mark, Peter, Tim et al...
>>
>> I'm now running b5edda1b06e, today's master, under el7 with hardware
>> as in the subject.
>>
>> A recording that allows good sensory evaluation of a/v sync shows
>> noticeable drift that is not evident from the -v playback log.
>>
>> The same recording plays with perfect a/v sync via the MythTV DLNA
>> server on my TV
>>
>> This sample of the log shows a higher rate of frame-dropping than the
>> average for that recording.  It suggests to me that the result of
>> dropping a frame may not be getting through to the sync filter input.
>> I first reported sync drift on 16 Nov, and IIRC I first noticed it a
>> day or two earlier.  AVSync2 increment is 1 ms.
>>
>> HTH,
>>
>> John P
>>
>> {{{
>>
>> 2019-12-09 18:19:49.635638 I  Player(5): dropping frame to catch up,
>> lateness=39890 usec
>> 2019-12-09 18:19:49.793242 I  Player(5): dropping frame to catch up,
>> lateness=38490 usec
>> 2019-12-09 18:19:49.832012 I  Player(5): AV Sync: Audio ahead by 28 ms
>> 2019-12-09 18:19:49.960731 I  Player(5): dropping frame to catch up,
>> lateness=48985 usec
>> 2019-12-09 18:19:49.988455 I  Player(5): AV Sync: Audio ahead by 24 ms
>> 2019-12-09 18:19:50.054778 I  Player(5): AV Sync: Audio ahead by 24 ms
>> 2019-12-09 18:19:50.116016 I  Player(5): dropping frame to catch up,
>> lateness=47266 usec
>> 2019-12-09 18:19:50.156979 I  Player(5): AV Sync: Audio ahead by 33 ms
>> 2019-12-09 18:19:50.216963 I  Player(5): dropping frame to catch up,
>> lateness=30218 usec
>> 2019-12-09 18:19:50.378709 I  Player(5): dropping frame to catch up,
>> lateness=32955 usec
>> 2019-12-09 18:19:50.542979 I  Player(5): dropping frame to catch up,
>> lateness=38217 usec
>> 2019-12-09 18:19:50.700887 I  Player(5): dropping frame to catch up,
>> lateness=37134 usec
>> 2019-12-09 18:19:50.861823 I  Player(5): dropping frame to catch up,
>> lateness=39076 usec
>> 2019-12-09 18:19:51.015041 I  Player(5): dropping frame to catch up,
>> lateness=32288 usec
>> 2019-12-09 18:19:51.172908 I  Player(5): dropping frame to catch up,
>> lateness=31159 usec
>> 2019-12-09 18:19:52.062073 I  Player(5): AV Sync: Audio behind by 1 ms
>> 2019-12-09 18:19:52.889115 I  Player(5): AV Sync: Audio ahead by 24 ms
>> 2019-12-09 18:19:52.921252 I  Player(5): AV Sync: Audio ahead by 23 ms
>> 2019-12-09 18:19:52.992925 I  Player(5): FPS:   24.94 Mean: 40102
>> Std.Dev: 18410 CPUs: 91% 91%
>> 2019-12-09 18:19:56.984290 I  Player(5): FPS:   25.06 Mean: 39909
>> Std.Dev:  1221 CPUs: 81% 78%
>> 2019-12-09 18:20:00.984315 I  Player(5): FPS:   25.00 Mean: 39996
>> Std.Dev:  1200 CPUs: 80% 79%
>> 2019-12-09 18:20:01.868788 I  Player(5): dropping frame to catch up,
>> lateness=66031 usec
>> 2019-12-09 18:20:01.901175 I  Player(5): AV Sync: Audio ahead by 57 ms
>> 2019-12-09 18:20:01.940942 I  Player(5): AV Sync: Audio ahead by 39 ms
>> 2019-12-09 18:20:01.977668 I  Player(5): AV Sync: Audio ahead by 35 ms
>> 2019-12-09 18:20:02.011394 I  Player(5): AV Sync: Audio ahead by 29 ms
>> 2019-12-09 18:20:02.045813 I  Player(5): AV Sync: Audio ahead by 24 ms
>>
>> )))
>> _______________________________________________
>
> Audio ahead is worse for the user experience than audio behind. However,
> per the wikipedia
> (https://en.wikipedia.org/wiki/Audio-to-video_synchronization#Recommendations)
> expert viewers could not detect anything less than 125ms behind to 45ms
> ahead. Based in that I do not correct anything that is less than 40ms
> off. You should not be able to detect errors of 39ms. I suspect that
> your sound equipment or the linux alsa component may be giving incorrect
> information back to mythtv about the state of audio output and amount of
> audio being buffered.
>
> With regard to dropping frames not getting through, each frame of audio
> and each frame of video has a timestamp, and these are matched up. So
> regardless of dropping video or audio, the timestamps of the following
> frames will be used to sync up.
>
> Peter

That is what I would hope to see, and I think the DLNA playback may well
be using it; but in this mythfrontend system I'm having to apply an
adjustment of around 2000 ms after playing for around 40 minutes,
starting from 0 ms. It's a new feature, perhaps designed to make me
watch election broadcasts :-)

John


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: AVSync in master, Normal decoding, vga monitor and built-in audio analog stereo [ In reply to ]
mark.kendall at gmail
Dec 9, 2019, 2:12 PM
Post #5 of 17 (3090 views)
Permalink
On Mon, 9 Dec 2019 at 21:21, Gregorio Gervasio Jr.
<gregorio.gervasio@gmail.com> wrote:
>
> >>>>> John Pilkington writes:
>
> > Hi Mark, Peter, Tim et al...
> > I'm now running b5edda1b06e, today's master, under el7 with hardware
> > as in the subject.
>
> > A recording that allows good sensory evaluation of a/v sync shows
> > noticeable drift that is not evident from the -v playback log.
> [...]
>
> At least for me, it seems like the sync problems (where audio
> runs ahead of video) are only happening with 1080i (MPEG-2) content and
> only when I use the double-rate software deinterlacers. If I disable
> double-rate deinterlacing or if I enable "Prefer OpenGL deinterlacers",
> I don't see the problem. I'll need to dig deeper into it to be sure,
> though ...

Gregorio

You may be on to something - I hadn't thought to look at the FFmpeg
deinterlacers. They manipulate timestamps when run at double rate and
as the filtering happens before the a/v sync - it could lead to drift
if there is any small loss in precision.

John - does that tie up with what you are seeing?

Thanks and regards
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: AVSync in master, Normal decoding, vga monitor and built-in audio analog stereo [ In reply to ]
johnpilk222 at gmail
Dec 9, 2019, 2:20 PM
Post #6 of 17 (3087 views)
Permalink
On 09/12/2019 21:20, Gregorio Gervasio Jr. wrote:
>>>>>> John Pilkington writes:
>
>> Hi Mark, Peter, Tim et al...
>> I'm now running b5edda1b06e, today's master, under el7 with hardware
>> as in the subject.
>
>> A recording that allows good sensory evaluation of a/v sync shows
>> noticeable drift that is not evident from the -v playback log.
> [...]
>
> At least for me, it seems like the sync problems (where audio
> runs ahead of video) are only happening with 1080i (MPEG-2) content and
> only when I use the double-rate software deinterlacers. If I disable
> double-rate deinterlacing or if I enable "Prefer OpenGL deinterlacers",
> I don't see the problem. I'll need to dig deeper into it to be sure,
> though ...
>

Thanks for that suggestion. I have increased the AVSync2 increment to 4
ms and selected the low quality deinterlace options, and the drift does
seem to have gone away.

I had gone to the 1 ms correction setting because the reported timing
StdDEv seems to track this value. Perhaps the lower setting prevents
tracking of the actual sync. There are still reports of frame dropping,
and the deinterlacer might not be good enough...

John
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: AVSync in master, Normal decoding, vga monitor and built-in audio analog stereo [ In reply to ]
johnpilk222 at gmail
Dec 10, 2019, 2:06 AM
Post #7 of 17 (3079 views)
Permalink
On 09/12/2019 22:12, Mark Kendall wrote:
> On Mon, 9 Dec 2019 at 21:21, Gregorio Gervasio Jr.
> <gregorio.gervasio@gmail.com> wrote:
>>
>>>>>>> John Pilkington writes:
>>
>>> Hi Mark, Peter, Tim et al...
>>> I'm now running b5edda1b06e, today's master, under el7 with hardware
>>> as in the subject.
>>
>>> A recording that allows good sensory evaluation of a/v sync shows
>>> noticeable drift that is not evident from the -v playback log.
>> [...]
>>
>> At least for me, it seems like the sync problems (where audio
>> runs ahead of video) are only happening with 1080i (MPEG-2) content and
>> only when I use the double-rate software deinterlacers. If I disable
>> double-rate deinterlacing or if I enable "Prefer OpenGL deinterlacers",
>> I don't see the problem. I'll need to dig deeper into it to be sure,
>> though ...
>
> Gregorio
>
> You may be on to something - I hadn't thought to look at the FFmpeg
> deinterlacers. They manipulate timestamps when run at double rate and
> as the filtering happens before the a/v sync - it could lead to drift
> if there is any small loss in precision.
>
> John - does that tie up with what you are seeing?
>
> Thanks and regards
> Mark

Hi Mark: As I said in my reply to Gregorio's post,

> I have increased the AVSync2 increment to 4 ms and selected the low quality deinterlace options, and the drift does seem to have gone away.

The root cause seems to be a systematic and cumulative difference
between what is being controlled and what ought to be being controlled,
and if the suggested new 'loop gain' approach works with the timestamps
as they actually reach the hardware that ought to improve things.

Testing of options is slow because the effects are slow to appear, and
I'm not sure what to try now.

I should make clear that I don't expect my windowed displays on monitors
to deliver the greatest AV experience. They're just tools in the chain.

Thanks again,

John



_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: AVSync in master, Normal decoding, vga monitor and built-in audio analog stereo [ In reply to ]
mark.kendall at gmail
Dec 10, 2019, 3:09 AM
Post #8 of 17 (3078 views)
Permalink
On Tue, 10 Dec 2019 at 10:07, John Pilkington <johnpilk222@gmail.com> wrote:
> Hi Mark: As I said in my reply to Gregorio's post,
>
> > I have increased the AVSync2 increment to 4 ms and selected the low quality deinterlace options, and the drift does seem to have gone away.
>
> The root cause seems to be a systematic and cumulative difference
> between what is being controlled and what ought to be being controlled,
> and if the suggested new 'loop gain' approach works with the timestamps
> as they actually reach the hardware that ought to improve things.
>
> Testing of options is slow because the effects are slow to appear, and
> I'm not sure what to try now.
>
> I should make clear that I don't expect my windowed displays on monitors
> to deliver the greatest AV experience. They're just tools in the chain.

John

Trying to join the dots on what may be happening.

Based on feedback from yourself and Gregorio, it looks like the issue
lies with the FFmpeg medium and high quality deinterlacers (yadif and
bwdif respectively).

Revisiting the mythtv code, we do not feed any timestamps into the
ffmpeg deinterlacing filters or use any timestamps that may be
returned. I *think* timestamps and hence the a/v sync code are
irrelevant.

What *may* be happening is that the deinterlacers are somehow not
dealing with discontinuities when a frame is dropped. Hence, for
whatever reason, the actual video frame returned does not physically
match the frame originally associated with the video timestamp. A
small difference is expected due to buffering in the filter (and there
is a todo on the render branch wiki page about handling that
difference). But what I believe you are seeing is the cumulative
effect over time of multiple frame drops. In your case, this is
exacerbated by the fact that it appears you are running at a very high
system load during playback (which will be partly due to the
deinterlacers themselves) and hence dropping frames regularly.

The solution may be to flush the deinterlacing filters when a
discontinuity is detected (i.e. a frame is dropped) - but that may
have a knock on effect on the quality of playback.

It may also be appropriate to explicitly pass the video timestamps
into the filter so it is itself aware of discontinuities - but my
understanding of the libavfilter internals is limited - so don't know
whether this would help.

What I will do is add some logging to the software deinterlacers to
show when a frame is not returned as expected - which should indicate
if/when it starts to run out of sync.

Regards
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: AVSync in master, Normal decoding, vga monitor and built-in audio analog stereo [ In reply to ]
mark.kendall at gmail
Dec 10, 2019, 4:49 AM
Post #9 of 17 (3078 views)
Permalink
On Tue, 10 Dec 2019 at 11:09, Mark Kendall <mark.kendall@gmail.com> wrote:

> What I will do is add some logging to the software deinterlacers to
> show when a frame is not returned as expected - which should indicate
> if/when it starts to run out of sync.

So the logging didn't prove useful but I've just pushed a change to
pass the video timecode into the FFmpeg deinterlacers and use the
returned timestamp for display. Fingers crossed this eliminates any
timestamp differences due to FFmpeg buffering.

Regards
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: AVSync in master, Normal decoding, vga monitor and built-in audio analog stereo [ In reply to ]
pb.mythtv at gmail
Dec 10, 2019, 7:31 AM
Post #10 of 17 (3077 views)
Permalink
On 12/10/19 6:09 AM, Mark Kendall wrote:
> Revisiting the mythtv code, we do not feed any timestamps into the
> ffmpeg deinterlacing filters or use any timestamps that may be
> returned. I*think* timestamps and hence the a/v sync code are
> irrelevant.
I have not looked at this is some time, but with some deinterlacers I
worked on,  the timestamps were messed up coming out of the deinterlacer
and I added code to copy the original timestamps onto the deinterlaced
frames, and interpolate the time stamps for the extra frames created. I
am not sure which deinterlacers had the problem, I think maybe the
NVIDIA Shield built in deinterlace was like 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
Re: AVSync in master, Normal decoding, vga monitor and built-in audio analog stereo [ In reply to ]
johnpilk222 at gmail
Dec 10, 2019, 8:15 AM
Post #11 of 17 (3077 views)
Permalink
On 10/12/2019 12:49, Mark Kendall wrote:
> On Tue, 10 Dec 2019 at 11:09, Mark Kendall <mark.kendall@gmail.com> wrote:
>
>> What I will do is add some logging to the software deinterlacers to
>> show when a frame is not returned as expected - which should indicate
>> if/when it starts to run out of sync.
>
> So the logging didn't prove useful but I've just pushed a change to
> pass the video timecode into the FFmpeg deinterlacers and use the
> returned timestamp for display. Fingers crossed this eliminates any
> timestamp differences due to FFmpeg buffering.
>
> Regards
> Mark

I have that ( bd4822a ) running in Fedora 30, using for comparison a
Normal profile with OpenGL YV12 and HQ deinterlacers, and see/hear no
sign of drift in a BBC1 SD recording. The reported AVSync is usually 1
or 2 ms with occasional single values around 45 ms.

The OSD shows MPEG-2 ffmpeg, Deint 2x CPU bwdif, and two CPUs at around 30%

The el7 box, with a similar CPU, still on yesterday's build, shows
MPEG-2 ffmpeg, 2x CPU onefield, but the CPUs are at around 85%. It's
not immediately clear why. I'll start building for that box now.

John




_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: AVSync in master, Normal decoding, vga monitor and built-in audio analog stereo [ In reply to ]
johnpilk222 at gmail
Dec 11, 2019, 1:14 AM
Post #12 of 17 (3074 views)
Permalink
On 10/12/2019 16:15, John Pilkington wrote:

> I have that ( bd4822a ) running in Fedora 30, using for comparison a
> Normal profile with OpenGL YV12 and HQ deinterlacers, and see/hear no
> sign of drift in a BBC1 SD recording.  The reported AVSync is usually 1
> or 2 ms with occasional single values around 45 ms.
>
> The OSD shows MPEG-2 ffmpeg, Deint 2x CPU bwdif, and two CPUs at around 30%
>

I have a build from the same commit on el7 now, and have settings with
which I don't see drift. There's still some jitter in the sync values
reported, the StdDevs are comparable with the larger AVSync2 increment
that seems to be needed, and the CPUs are busier than in F30. Perhaps
that's just progress.

In a post on 8 Dec Peter said:

> The audio time is taken from the audio sent to the sound card and adjusted for the amount of audio in the sound card buffer, as supplied by the operating system. Depending on the audio setup, this can be inaccurate and the figure obtained can jump around the correct value. I suspect that your playback problems may be caused by this, resulting in video playback slowing down and speeding up inconsistently. When this is the case, setting the audio adjustment to the smallest value is the best solution.

Is that buffering lag within the new loop, and is there a similarly
accessible lag on the video side? Just asking...

> John
>
>
>
>

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: AVSync in master, Normal decoding, vga monitor and built-in audio analog stereo [ In reply to ]
mark.kendall at gmail
Dec 13, 2019, 12:21 AM
Post #13 of 17 (3063 views)
Permalink
On Wed, 11 Dec 2019 at 09:15, John Pilkington <johnpilk222@gmail.com> wrote:
> I have a build from the same commit on el7 now, and have settings with
> which I don't see drift. There's still some jitter in the sync values
> reported, the StdDevs are comparable with the larger AVSync2 increment
> that seems to be needed, and the CPUs are busier than in F30. Perhaps
> that's just progress.

John

There is one potential 'gotcha' that probably applies to your systems
(as you are using predominantly software decoding).

With the conversion to use FFmpeg for deinterlacing, you may see
higher load with the medium and high quality deinterlacers. While I
would expect the low quality (onefield/bob) to be comparable to the
old mythtv equivalent filter, the medium uses yadif and the high
quality bwdif. The equivalent medium to high versions previously would
have been something like linearblend and yadif. This is because
FFmpeg/libavfilter doesn't offer anything that fits into the 'medium'
quality bracket - so I had to make do.

Regards
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: AVSync in master, Normal decoding, vga monitor and built-in audio analog stereo [ In reply to ]
johnpilk222 at gmail
Dec 13, 2019, 4:05 AM
Post #14 of 17 (3061 views)
Permalink
Re-sending to list.

On 13/12/2019 08:21, Mark Kendall wrote:
> On Wed, 11 Dec 2019 at 09:15, John Pilkington <johnpilk222@gmail.com> wrote:
>> I have a build from the same commit on el7 now, and have settings with
>> which I don't see drift. There's still some jitter in the sync values
>> reported, the StdDevs are comparable with the larger AVSync2 increment
>> that seems to be needed, and the CPUs are busier than in F30. Perhaps
>> that's just progress.
>
> John
>
> There is one potential 'gotcha' that probably applies to your systems
> (as you are using predominantly software decoding).
>
> With the conversion to use FFmpeg for deinterlacing, you may see
> higher load with the medium and high quality deinterlacers. While I
> would expect the low quality (onefield/bob) to be comparable to the
> old mythtv equivalent filter, the medium uses yadif and the high
> quality bwdif. The equivalent medium to high versions previously would
> have been something like linearblend and yadif. This is because
> FFmpeg/libavfilter doesn't offer anything that fits into the 'medium'
> quality bracket - so I had to make do.
>
> Regards
> Mark

Thanks Mark: The el7 system is now on 4fddad7097e, and sync seems to be
subjectively ok on the SD material that I have played on it. -v
playback AV Sync is usually around 25 ms, either ahead or behind, and
frames are still being dropped. It may be that the opposite isn't
logged. MPEG-2 ffmpeg, 2x CPU onefield. CPU around 2x 90% with the OSD
active, slightly lower without.

I now have a 4-core Fedora 30 box with nVidia GT_710 at 440.36 and an
hdmi connection and will try to find out what that can do. What has
puzzled me with nVidia in the past has been the slight loss of picture
rigidity during slow pans, and that's a different topic.

John




_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: AVSync in master, Normal decoding, vga monitor and built-in audio analog stereo [ In reply to ]
johnpilk222 at gmail
Dec 13, 2019, 6:12 AM
Post #15 of 17 (3061 views)
Permalink
> On 13/12/2019 08:21, Mark Kendall wrote:

>> There is one potential 'gotcha' that probably applies to your systems
>> (as you are using predominantly software decoding).
>>
>> With the conversion to use FFmpeg for deinterlacing, you may see
>> higher load with the medium and high quality deinterlacers. While I
>> would expect the low quality (onefield/bob) to be comparable to the
>> old mythtv equivalent filter, the medium uses yadif and the high
>> quality bwdif. The equivalent medium to high versions previously would
>> have been something like linearblend and yadif. This is because
>> FFmpeg/libavfilter doesn't offer anything that fits into the 'medium'
>> quality bracket - so I had to make do.
>>
>> Regards
>> Mark
>
> Thanks Mark:  The el7 system is now on 4fddad7097e, and sync seems to be
> subjectively ok on the SD material that I have played on it.  -v
> playback AV Sync is usually around 25 ms, either ahead or behind, and
> frames are still being dropped. It may be that the opposite isn't
> logged.  MPEG-2 ffmpeg, 2x CPU onefield.  CPU around 2x 90% with the OSD
> active, slightly lower without.

The last commit in that build was to 'fix deinterlacer changes when
changing speed', so I tried playing at 130% and 70%. With both, the CPU
load shown in the OSD was significantly less than when playing at normal
speed. Strange. The sync was ok.

John

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: AVSync in master, Normal decoding, vga monitor and built-in audio analog stereo [ In reply to ]
mark.kendall at gmail
Dec 13, 2019, 6:58 AM
Post #16 of 17 (3059 views)
Permalink
On Fri, 13 Dec 2019 at 14:13, John Pilkington <johnpilk222@gmail.com> wrote:

> The last commit in that build was to 'fix deinterlacer changes when
> changing speed', so I tried playing at 130% and 70%. With both, the CPU
> load shown in the OSD was significantly less than when playing at normal
> speed. Strange. The sync was ok.

When playing at anything other than normal speed, the deinterlacers
drop down to single rate.

I did play with enabling double rate as long as the display can
support it - but other issues cropped up.

Regards
Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: AVSync in master, Normal decoding, vga monitor and built-in audio analog stereo [ In reply to ]
johnpilk222 at gmail
Dec 13, 2019, 7:31 AM
Post #17 of 17 (3059 views)
Permalink
On 13/12/2019 14:58, Mark Kendall wrote:
> On Fri, 13 Dec 2019 at 14:13, John Pilkington <johnpilk222@gmail.com> wrote:
>
>> The last commit in that build was to 'fix deinterlacer changes when
>> changing speed', so I tried playing at 130% and 70%. With both, the CPU
>> load shown in the OSD was significantly less than when playing at normal
>> speed. Strange. The sync was ok.
>
> When playing at anything other than normal speed, the deinterlacers
> drop down to single rate.
>
> I did play with enabling double rate as long as the display can
> support it - but other issues cropped up.
>
> Regards
> Mark

Thanks. I should have noticed; the '2x' vanishes from the Deint name in
the OSD.


_______________________________________________
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

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal