Opened 6 months ago

Closed 6 months ago

#13579 closed Bug Report - General (Fixed)

Audio sync lost when forwarding & rewinding

Reported by: bib1963 Owned by: Mark Kendall
Priority: minor Milestone: 31.0
Component: MythTV - General Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

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.

Attachments (1)

mythfe.txt.zip (1.5 MB) - added by bib1963 6 months ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 6 months ago by Mark Kendall

Status: newinfoneeded_new

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

Logs? Version? System details? Anything...

comment:2 Changed 6 months ago by 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.

comment:3 in reply to:  2 Changed 6 months ago by 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.

comment:4 Changed 6 months ago by 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.

Changed 6 months ago by bib1963

Attachment: mythfe.txt.zip added

comment:5 in reply to:  4 Changed 6 months ago by 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.

comment:6 Changed 6 months ago by Mark Kendall

Milestone: needs_triage31.0
Owner: set to Mark Kendall
Status: infoneeded_newassigned

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

comment:7 Changed 6 months ago by Mark Kendall

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

comment:8 Changed 6 months ago by 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%.

comment:9 Changed 6 months ago by Mark Kendall

Resolution: Fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.