Add framerate-based sync setting

[madscientist159]

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.

[Peter Bennett]

How many frames are you typically using for the adjustment?

[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! :)

[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.

[Peter Bennett]

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.

[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.