Opened 22 months ago

Closed 10 months ago

Last modified 7 weeks ago

#13494 closed Patch - Feature (Won't Fix)

Add framerate-based sync setting

Reported by: madscientist159 Owned by: Peter Bennett
Priority: minor Milestone: unknown
Component: MythTV - Video Playback Version: v29-fixes
Severity: low Keywords:
Cc: Mark Kendall Ticket locked: no


I have a bit of an oddball setup* where the audio always leads the video by a specific number of frames, not by a fixed number of milliseconds. As I also use variable refresh rates (set automatically by the recording being played) this can range from annoying to completely unwatchable, unless one keeps a table of known offsets and adjusts the audio sync for each recording when it starts.

Needless to say this is a pain and makes MythTV nearly unusable. I've put together this patch to make it all work again -- it adds a new (hidden) per-frontend setting to the database called VideoSyncDelayFrames?, and automatically combines it with the existing audio sync setting.

It's fairly crude, this is my first time hacking on the MythTV codebase. If there's a better way to do what I'm trying to do suggestions are quite welcome -- at least my old TV recordings are watchable again in the meantime!

Note this has the side effect of showing the "base" A/V sync value when you go to the Adjust Audio Sync screen. I'm torn -- I like seeing the starting value, but at the same time it makes adjusting A/V sync more complex since you need to know the FPS of the recording to make an informed adjustment.

  • It's a projector and custom (homebrew) 8 channel speaker system hung directly off the frontend. The translator boxes between the frontend and the projector (and maybe the logic board in the projector too) are what seem to be buffering enough frames to cause a very noticeable A/V desync.

Attachments (1)

audio_frame_sync.patch (2.7 KB) - added by madscientist159 21 months ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 22 months ago by Peter Bennett

Component: MythTV - GeneralMythTV - Video Playback
Owner: set to Peter Bennett
Status: newassigned

comment:2 Changed 22 months ago by Peter Bennett

How many frames are you typically using for the adjustment?

comment:3 Changed 22 months ago by madscientist159

I need to run a full calibration, because the actual delay through the system is some function of (n / fps) + fixed_delay, where I don't (yet) know exact value of fixed_delay, but the number of frames of delay required is definitely somewhere between 3 and 6 inclusive. Given the hardware, I suspect it's either 3 or 4, but a setting 5 of frames of delay with a 50ms fixed delay on top has been working reasonably OK so far.

I still have to build a bit of custom equipment to try to accurately measure the delay before I can tune further. Homebrew equipment can be all kinds of fun! :)

Last edited 22 months ago by madscientist159 (previous) (diff)

Changed 21 months ago by madscientist159

Attachment: audio_frame_sync.patch added

comment:4 Changed 21 months ago by madscientist159

I've updated the patch to use the output framerate instead of the source framerate. This was messing up my initial analysis since MythTV can select 60Hz output rates for 30FPS content.

It looks like a small static delay (under 100ms) plus 6 frames of delay* just about handles the A/V sync problem completely when switching from 24FPS to 60FPS. I do use the GL renderer, so I wonder if there's some extra video buffering in the host stack as well that's contributing to the overall delay.

  • My setup is a bit more complex than even this -- direct measurement of the A/V sync as projected / played over audio shows a ~88ms audio delay and a 12 frame video delay from the source, so the exact parameters to fix the A/V sync permanently on my setup are 12 frames of video delay combined with -88ms of fixed audio delay. I seem to be cursed with the ability to see even a few dozen ms of delay, hence my wanting to fix this for good, but other people that have watched the same desynced video didn't notice anything amiss. It's very likely that the sub-100ms desync inherent in any modern split system (separate video path from audio path) was simply undetected by most MythTV users.
Last edited 21 months ago by madscientist159 (previous) (diff)

comment:5 Changed 21 months ago by Peter Bennett

Cc: Mark Kendall added

It appears you have video hardware that plays 6 frames behind real time. It seems to be a unique setup. I am not comfortable with making a change that is specifically for one user.

Version 30 has a new sync method (AVSYNC2) that is selectable from settings, as well as a new audio buffer setting, where you can increase audio buffering if needed. I do not believe these will fix your problem, but they may change things in a way that causes your patch to work incorrectly.

Version 31 will include rewritten rendering code that is currently being worked on, and that may further affect you. As MythTV developers, we have no way of testing your patch with new versions.

Perhaps another approach may be to add a setting for "additional audio sync" to the playback group feature. Could you setup your recordings so that they go into a different playback group based on their frame rate? Each program that you record will likely have the same framerate for all recordings. The playback group on existing recordings can easily be changed through the front end. This does have the problem that playback group settings apply across all frontends, whereas this setting is likely to be frontend specific.

comment:6 Changed 19 months ago by Mark Kendall

I agree with Peter - I'd rather not complicate the code and add new settings for what is, at the end of the day, clearly an unusual, if not unique, setup.

That said - is this system HDMI based? There is now code in master to parse the audio and video latencies from the EDID (what is known as 'HDMI lip sync/auto lip sync' in marketig terms). It is not used yet - and I have no idea whether it would be available, useful or meaningful in your situation.

comment:7 Changed 10 months ago by Peter Bennett

Resolution: Won't Fix
Status: assignedclosed

comment:8 Changed 7 weeks ago by Stuart Auchterlonie

Milestone: needs_triageunknown
Note: See TracTickets for help on using tickets.