Expected behavior of the wanted feature
Sometimes we use audio filters for simple things like normalization, like:
af=lavfi=[loudnorm=I=-16:TP=-3:LRA=10]
On certain tracks, those filters can be applied in real time at custom playback speeds without causing any issue. But there are cases, specially for multichannel audio inputs, where trying to apply those filters at faster speeds will cause multiple problems, like stutters, buffering, de-synchronization, etc.
I can't confirm if the issue is global across different platforms because I only use Windows, and I acknowledge it may be a key factor.
I use a lua script to store the current applied filters and disabling them when playback speed is changed, and restore when back to 1x. I wanted to suggest this be a standard MPV behavior, either by default or through the passing of a custom argument in the conf file.
Alternative behavior of the wanted feature
No response
Log File
No response
Sample Files
No response
Expected behavior of the wanted feature
Sometimes we use audio filters for simple things like normalization, like:
af=lavfi=[loudnorm=I=-16:TP=-3:LRA=10]
On certain tracks, those filters can be applied in real time at custom playback speeds without causing any issue. But there are cases, specially for multichannel audio inputs, where trying to apply those filters at faster speeds will cause multiple problems, like stutters, buffering, de-synchronization, etc.
I can't confirm if the issue is global across different platforms because I only use Windows, and I acknowledge it may be a key factor.
I use a lua script to store the current applied filters and disabling them when playback speed is changed, and restore when back to 1x. I wanted to suggest this be a standard MPV behavior, either by default or through the passing of a custom argument in the conf file.
Alternative behavior of the wanted feature
No response
Log File
No response
Sample Files
No response