Audio sync lost when forwarding & rewinding

[bib1963]

Take a recording.

Now use the keys to go forward and back a dozen times or so.

You will see the audio sync has been lost.

The more time you go forward and back, the audio sync becomes worse.

[Mark Kendall]

Tried on 4 very different systems with master and repeated those steps - can't see any issues here.

Logs? Version? System details? Anything...

[bib1963]

I've posted logs elsewhere and this is with the latest master head.

I find that if I set off a linux kernel build with MAKE="make -j<max threads>", then the FE will quite readily lose audio sync. This was tested with a ripped episode off a dvd of The IT Crowd, so there is no prospect of transmission errors.

Looking at a patch supplied a few days ago, MythPlayer: Increment m_framesPlayed when frame is dropped, and, MythPlayer: Don't reset m_framesPlayed based on current timestamp, I am wondering if this is any where near correct.

m_framesPlayed gets increased by 1, but what if multiple frames were dropped. What if, due to load, the section prior with "while (framedue == 0)" only fired once, when it should have fired multiple times.

And as I look at line 1639, - Get video in sync with audio - I am wondering why that section looks so convoluted.

[Mark Kendall]

Replying to bib1963:

I've posted logs elsewhere and this is with the latest master head.

If you want anyone to try and resolve this, you're going to need to post some logs.

m_framesPlayed gets increased by 1, but what if multiple frames were dropped. What if, due to load, the section prior with "while (framedue == 0)" only fired once, when it should have fired multiple times.

There is only 1 frame to drop - the one supplied to the function. It either gets displayed or it doesn't.

[bib1963]

Here's another log when running "mythfrontend -v all".

It's showing a 24m30s video ripped from a dvd.

At the time I am running 'make MAKE="make -j4"' on a linux kernel build.

This is on a 2c4t i3-4160 CPU @ 3.60GHz.

Less than 3 minutes into it, audio sync was lost, with audio always ahead of video.

The more concurrent jobs on the linux kernel build, the worse and quicker the sync loss.

Even if you then kill the linux build, the video never catches up with the audio.

It only seemed to start when the hardware interlacing was pulled into master.

[Mark Kendall]

Replying to bib1963:

Here's another log when running "mythfrontend -v all".

It's showing a 24m30s video ripped from a dvd.

At the time I am running 'make MAKE="make -j4"' on a linux kernel build.

This is on a 2c4t i3-4160 CPU @ 3.60GHz.

Less than 3 minutes into it, audio sync was lost, with audio always ahead of video.

The more concurrent jobs on the linux kernel build, the worse and quicker the sync loss.

Even if you then kill the linux build, the video never catches up with the audio.

It only seemed to start when the hardware interlacing was pulled into master.

OK - from the logs, you're using FFmpeg decoding and FFmpeg software deinterlacing.

What happens if you disable deinterlacing?

What happens if you enable shader deinterlacing in the video display profile code? (You'll need to go into the guts of the display profile settings pages to find 'Prefer OpenGL deinterlacers' settings for single rate and double rate)

Alternatively, is VAAPI usable on that system? Looks like it is failing for some reason.

[Mark Kendall]

OK - nevermind - found the problem. Just working on the most efficient fix.

[Mark Kendall]

This should be fixed in master. If there are no issues I'll push to 31/fixes

[bib1963]

Well, that does seem to have cured the audio sync issues, but boy has the CPU utilisation gone through the roof. For many years it would sit at around 20%, but now with this fix. it hits beyond 70%.