LigH
12th September 2024, 15:38
During the last week(s) a problem started compiling ffmpeg including a patch to implement an alternative demultiplexer for VapourSynth.
This patch may be obsolete now, since there was some development in ffmpeg to allow dynamic linking of VapourSynth libraries in static builds, and some multi-threading optimizations.
To check whether the alternative demultiplexer can be removed as obsolete, it would be lovely if some people actually using VapourSynth under Windows could test these three builds I made (https://www.ligh.de/test/ffmpeg-vpy.7z); the latest EXE was built without the patch, the older two still contain it (they were built with MABS when there was no linker error yet). An additional task would be to benchmark the direct VPY source input versus piping from vspipe.
Your results will help deciding whether it is safe or not to exclude the alternative demultiplexer from building in MABS (https://github.com/m-ab-s/media-autobuild_suite/issues/2766) or possibly even disable VapourSynth support because there is not much advantage over piping.
This patch may be obsolete now, since there was some development in ffmpeg to allow dynamic linking of VapourSynth libraries in static builds, and some multi-threading optimizations.
To check whether the alternative demultiplexer can be removed as obsolete, it would be lovely if some people actually using VapourSynth under Windows could test these three builds I made (https://www.ligh.de/test/ffmpeg-vpy.7z); the latest EXE was built without the patch, the older two still contain it (they were built with MABS when there was no linker error yet). An additional task would be to benchmark the direct VPY source input versus piping from vspipe.
Your results will help deciding whether it is safe or not to exclude the alternative demultiplexer from building in MABS (https://github.com/m-ab-s/media-autobuild_suite/issues/2766) or possibly even disable VapourSynth support because there is not much advantage over piping.