Well that escal obsoleted quickly!
ffmpeg 7, released this week-end, encodes faster than the build I used for the timing (6.1).
Not unlikely because it now does some kind of multithreading. Not the encoding itself it seems, but between encoding and decoding - maybe that means it has a thread reading the WAVE before feeding it to its wavpack encoder.
I have no idea whether that is doing much work other than keeping the queue, so to say.
And so I don't know whether it is less or more apples-to-apples with ffmpeg 7 than with 6.1.1.
Also I found out that wavpack *.wav is a bit faster than a FOR loop. ffmpeg doesn't do wildcards. From a user perspective, that is "their loss" if user has to wait longer - but if you are interested in CPU efficiency, then what? If you run the CPU at full throttle, those small I/O-related pauses might just get something else done?
I am not going to try to run four or eight concurrent ffmpegs to time it. Getting those times reliable ... meh.
So here is a table for the comparable presets up to 4, using old and new ffmpeg, old and new WavPack - and with 5.7.0 both wildcarded and FOR looped. All with -y overwrites for each file, all on the same SSD as the .wav encoded. This time in seconds, because you are waiting in seconds not in percents I guess? Similar corpus.
Each row is about the same compression level, see previous post (0: ffmpeg compresses worse)
. | | 5.7.0 *.wav | | 5.7.0 FOR | 4.80 *.wav | FFmpeg 6.1.1 | FFmpeg 7.0 | remark |
0 | | 24 | | +1 | +6 | +15 | -0.3 | -f and compression_level 0 |
1 | | 49 | | +5 | +7 | +17 | -1.0 | -x and compression_level 1 |
2 | | 117 | | +9 | +7 | +37 | +5 | -hx2 and compression_level 2 |
3 | | 360 | | +8 | -1.4 | +68 | +21 | -hhx3 and compression_level 3 |
4 | | 1235 | | +9 | +12 | +402 | +354 | -hhx4 and compression_level 4 |
Less is better and plusses are worse.
5.7.0 *.wav column shows time in seconds. Other columns seconds difference relative to that. Why FOR looping makes very little difference for -f and more difference with higher modes ... who knows.
Anyway, the FF is now as fast as gets on compression_level 1, and faster than FOR-looped wavpack at 2. Results at level 4 are so clear that I'll happily leave it there rather than running the even slower ones.
BTW, both ffmpegs are MSYS2 project builds. Don't know if anything relevant has changed.
ffmpeg version 6.1.1-essentials_build-www.gyan.dev Copyright (c) 2000-2023 the FFmpeg developers
built with gcc 12.2.0 (Rev10, Built by MSYS2 project)
configuration: --enable-gpl --enable-version3 --enable-static --pkg-config=pkgconf --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-zlib --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-sdl2 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-dxva2 --enable-d3d11va --enable-libvpl --enable-libgme --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libtheora --enable-libvo-amrwbenc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-librubberband
libavutil 58. 29.100 / 58. 29.100
libavcodec 60. 31.102 / 60. 31.102
libavformat 60. 16.100 / 60. 16.100
libavdevice 60. 3.100 / 60. 3.100
libavfilter 9. 12.100 / 9. 12.100
libswscale 7. 5.100 / 7. 5.100
libswresample 4. 12.100 / 4. 12.100
libpostproc 57. 3.100 / 57. 3.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...
Use -h to get full help or, even better, run 'man ffmpeg'
--pkg-config=pkgconf has disappeared and gcc is newer. Then the following are added that make for some hardware acceleration, but not here?! Or?
--enable-d3d12va
--enable-vaapi
ffmpeg version 7.0-essentials_build-www.gyan.dev Copyright (c) 2000-2024 the FFmpeg developers
built with gcc 13.2.0 (Rev5, Built by MSYS2 project)
configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-zlib --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-sdl2 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-dxva2 --enable-d3d11va --enable-d3d12va --enable-ffnvcodec --enable-libvpl --enable-nvdec --enable-nvenc --enable-vaapi --enable-libgme --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libtheora --enable-libvo-amrwbenc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-librubberband
libavutil 59. 8.100 / 59. 8.100
libavcodec 61. 3.100 / 61. 3.100
libavformat 61. 1.100 / 61. 1.100
libavdevice 61. 1.100 / 61. 1.100
libavfilter 10. 1.100 / 10. 1.100
libswscale 8. 1.100 / 8. 1.100
libswresample 5. 1.100 / 5. 1.100
libpostproc 58. 1.100 / 58. 1.100
Universal media converter
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...
Use -h to get full help or, even better, run 'man ffmpeg'