ActiveAE: compensate error for TrueHD passthrough

[thexai]

Description

ActiveAE: compensate error for TrueHD passthrough

Motivation and context

Apply what has been found in: https://forum.kodi.tv/showthread.php?tid=377117&pid=3198021#pid3198021

Basically due nature of TrueHD compressed audio, data is not received at regular intervals then the delay is not constant while handling TrueHD frames but it is once decoded to PCM. Since AE is handling compressed data, even it's not aware of this, is need a corrective factor in the error.

This is a very basic form of correction but effective since the variability is well limited.

We can try to find the correction value theoretically:

There is usually a maximum of 5 MAT frames queued, that is 5 * 20 ms = 100 ms plus another 100 ms due maxpassthroughoffsyncduration. In total is 200 ms.

This is the worst case and should be inside AE threshold of 100 ms. Then is need scale 200 ms to 100 ms

error = error * 0.50

0.45 is used to have some margin.

Another way to justify this value is empirically:

Normal error oscillation (noise) should be less than frame time (~42 ms at 23.976) to avoid accidental a/v sync corrections.

0.45 factor seems meets the two conditions in various videos tested. It may not be perfect but it is a great improvement over the current situation.

In a follow up PR should be revised self-learning algo to not exceed 2* frame time as this broke a/v sync correction.

Ideally error noise < frame time
self-learning or maxpassthroughoffsyncduration > error noise but less 2 * frame time.

Probably we can use constant value of 1.8 * frame time and remove "self-learning"....

How has this been tested?

Runtime Shield.

What is the effect on users?

• No more TrueHD dropouts even in very problematic sources as Cars (2006) when is used adequate maxpassthroughoffsyncduration value only.
• Seeks improved considerably: audio returns much faster after seek because there is less error and no additional corrections are necessary.

Tested Blu-Ray folder and also tested MKV created with MakeMKV v1.17.7
and
Blu-Ray to .m2ts with tsMuxer and .m2ts to MKV with mkvmerge v82.0

Screenshots (if appropriate):

No dropouts in 20 minutes of playback:

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

[fritsch]

Thanks - I followed the thread. All fine within the margin ... if we ever get the delay per packed packet exactly (changing value per packet), we can change this.