Please add support for multi-threads libavfilter processing

tramchamploo commented 5 days ago

Expected behavior of the wanted feature

Nowadays people like me use ffmpeg audio filter for upmixing, binauralizing and high quality resampling which in this case one core processing is not sufficient. I believe ffmpeg already support it and enable it by default. Somehow mpv only use 1 thread for filtering.

Alternative behavior of the wanted feature

User can specify threads for filtering or let ffmpeg do it automatically.

Log File

No response

Sample Files

No response

richardpl commented 4 days ago

Dunno what you complain about, command: "ffmpeg -h filter=" will list slice threading supported for audio filters. Such filter will use multiple threads for processing each input/output channel.

Do get more useful response, provide more detailed report.

And mpv by default automatically add threads for such filters, for finer tuning there is also threads= option that can be given into filter options.

tramchamploo commented 4 days ago

So I checked that most audio filters have no multithread support. I use ffmpeg swr resampler with a filter size of 8192, but if I use 16384, sound has to stop every now and then. I think 16384 is pretty reasonable when dealing with 192khz audio. I tried changing alsa buffer size but no luck. Command top shows that I have used one of my core to 100% usage. Any suggestions that I can optimize this?

richardpl commented 3 days ago

You are on your own with swr low quality messy resampler, I wonder where you got idea to use that excessive filter size for poor performed extremely low quality and unmaintained resampler.

Get at least build with soxr enabled swr resampler engine and use that with correct filter parameters specified.

Most audio filters have no multi-threading support?

Let me reality fact-check your claim:

In librempeg there are 274 filters with multi-threading (both Audio and Video) of 508 filters. That is more than half. And I did not removed filters that are not multi-threaded but are also not doing any real CPU work (either hwaccel or metadata passthrough).

tramchamploo commented 1 day ago

Extremely low quality and unmaintained? I don't think so. libswresample. As far as I know, sox is the one unmaintained:sox As for quality, comparison here shows it's not a bad resampler. And it's not that low noise sampler are always better. You have to take ringing into consideration for hifi listening.

richardpl commented 1 day ago

Ask yourself why swresample have SoX resampling engine named soxr. Libswresample is so bad that its aliasing is actually detectable by normal human hearing system. Libswresample is not maintaned really, also its conception is strange to say at best, as it is just uglier clone of now removed libavresample from old LibAV fork days.

Last significant and fairly recent critical improvement to swresample was made by myself, the path for 16bit->16bit resampling used only 16bit precision, yikes. So I'm clearly capable, well informed and skilled to say final word about this library net gain result, in my opinion its one of the worst open source implementations of resampling, there are for certain faster resamplers out there that give better quality at same or worse parameters than libswresample.

And if you closely inspect infinitewave output for swresampler native engine resampler you will see its aliasing is very strong. Also this have marginal importance and relevance for mpv project as aresample filter you use is not part of mpv, but part of FFmpeg project source code. PS: The goal of Librempeg project is to remove libswresample junk mess from its source code.

tramchamploo commented 2 hours ago

Thank you for your patience. The thinng I asked myself why swresample exists despite having argubly the best open source sampling filter sox. I know the aliasing but I only resample to 192khz so not a problem for me. As I said above, it has one of the cleanest impulse response. For hifi listening, it's hard to say which resampling filter is best, you kind of have to balance between different impulse responses, different bandpass ripple, faster or slower one and maybe as well as group delay. Since you have quite some knowledge on this old resampler. Can you elaborate me more on it that is it a minphase filter because of the phase_shift option it provides? Also if async is less equals 1, does it disable stretching even if I have min_comp > 0? The last one is kind of like a bug I suppose, which is if I downsample from dblp to s32 with improved_e_weighted dithering, the sound becomes wierd. triangular_hp works fine on this. I guess it is not where improved_e_weighted is supposed to work but maybe an error prompt or fallback?

mpv-player / mpv