VideoPlayerAudio: limit max allowed Out-Of-Sync for "self-learning" to 80 ms

[thexai]

Description

VideoPlayerAudio: limit max allowed Out-Of-Sync for "self-learning" to 80 ms

Motivation and context

As commented in #25229 recently found that use high values for maxpassthroughoffsyncduration e.g. 96 ms breaks a/v sync corrections because AE cannot correct error bigger that 2 * frame time. And since current "self-learning" algo calculates this value based in first seconds of stream is very influenced by bad a/v sync at start (and not yet corrected) and noise in error calculations (system clock irregularities, etc.).

With all this is possible too large values (even max. 100 ms) that cause error is accumulated and never corrected or too small values (25/30 ms) that may cause accidental corrections if error is bigger later (or noise in error only).

Then is better replace self-learning with a frame time based value, obtaining much more predictable operation.

1.5 * frame_time seems good value and has been well tested. Higher values could be used and up to 1.95 * frame_time has been tested to work well (a/v corrections occur when necessary) but not has much sense use high values now because the main use case is TrueHD (due error oscillation) but now this is mitigated in #25229 and no visible frame skips/repeats with 62 ms.

In general high values produces worse a/v sync because allows bigger stationary error (never corrected).

Users still may use high values via advancedsettings but a log warning is printed if value is > 1.95 * frame_time.

If any cases are discovered where accidental corrections continue to occur, instead of raising the threshold, the root cause should be investigated and reduce the error or noise in error, etc.

How has this been tested?

Runtime Shield

What is the effect on users?

For users who did not use advancedsettings it's a significant improvement because it prevents random problems because the value used could be too large or too low in specific (random) cases.

For users who use advancedsettings nothing changes but it is encouraged to use "better" values.

Screenshots (if appropriate):

Two very different cases in which the value of 1.5 * frame time works well:

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• Student submission (PR was done for educational purposes and will be treated as such)
• None of the above (please explain below)

Checklist:

• My code follows the Code Guidelines of this project
• My change requires a change to the documentation, either Doxygen or wiki
• I have updated the documentation accordingly
• I have read the Contributing document
• I have added tests to cover my change
• All new and existing tests passed

[thexai]

For now only I want fix unwanted behavior with default settings, then only limit self-learning to 80 ms. This in conjunction with error compensation (0.45 factor) is enough for TrueHD.

And backport these very small fixes to Omega.

[fritsch]

Thanks - small steps are good.