One ffmpeg instance/build is 3x slower than my other ffmpeg instance/build. Why?
I have 2 separate ffmpeg instances on my macOS machine (10.14.2 Mojave and Intel Core i5-8259U Quad-core CPU @ 2.30GHz, if that helps):
1 - Installed with brew (and linked with my local dylib's)
2 - A static build downloaded from Zeranoe's ffmpeg builds
Both are v4.1. But, when transcoding the same file (OGG -> MP3) with the same command options, with the same system load, and everything else being equal ... instance #1 is roughly 3x faster than instance #2. I need to know why because I need to bundle a static ffmpeg build with my app, and it needs to perform optimally. See command output below:
The faster instance of ffmpeg (Note the speed is 46.5x):
$ ffmpeg -v quiet -stats -i ~/Reiki2.ogg -vn -sn ~/Reiki2.mp3
size= 26290kB time=00:28:02.54 bitrate= 128.0kbits/s speed=46.5x
The slower ffmpeg instance (Note the speed is 17.2x)
$ ./ffmpeg -v quiet -stats -i ~/Reiki2.ogg -vn -sn ./Reiki2.mp3
size= 26290kB time=00:28:02.54 bitrate= 128.0kbits/s speed=17.2x
Why the huge difference in performance ???
If I figure this out, I can then build ffmpeg myself with optimized performance matching my faster installed ffmpeg (i.e. #1).
Is it how the two instances were configured prior to make ? Do you see any significant configuration options that are the reason for this huge difference in performance ?
I am dying to know this since my app depends on ffmpeg performance. I would really appreciate any insights. Thanks in advance !
Instance #1 (faster) was configured as follows:
ffmpeg version 4.1 Copyright (c) 2000-2018 the FFmpeg developers
built with Apple LLVM version 10.0.0 (clang-1000.11.45.5)
configuration: --prefix=/usr/local/Cellar/ffmpeg/4.1 --enable-shared
--enable-pthreads --enable-version3 --enable-hardcoded-tables
--enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-ffplay
--enable-gpl --enable-libmp3lame --enable-libopus --enable-libsnappy
--enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264
--enable-libx265 --enable-libxvid --enable-lzma --enable-opencl
--enable-videotoolbox
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
Instance #2 (slower) was configured as follows:
ffmpeg version 4.1 Copyright (c) 2000-2018 the FFmpeg developers
built with Apple LLVM version 10.0.0 (clang-1000.11.45.5)
configuration: --enable-gpl --enable-version3 --enable-sdl2
--enable-fontconfig --enable-gnutls --enable-iconv --enable-libass
--enable-libbluray --enable-libfreetype --enable-libmp3lame
--enable-libopencore-amrnb --enable-libopencore-amrwb
--enable-libopenjpeg --enable-libopus --enable-libshine
--enable-libsnappy --enable-libsoxr --enable-libtheora
--enable-libtwolame --enable-libvpx --enable-libwavpack
--enable-libwebp --enable-libx264 --enable-libx265
--enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib
--enable-gmp --enable-libvidstab --enable-libvorbis
--enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex
--enable-libxvid --enable-libaom --enable-appkit
--enable-avfoundation --enable-coreimage --enable-audiotoolbox
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
------ UPDATE: ------
1 - I tried building libmp3lame myself with --enable-nasm and then ffmpeg using that built lame. No difference noticed ... still slow.
2 - I ran the same transcoding tests on a much older Mac, and the results were nearly identical (scaled down because it's a slower computer).
i.e. libmp3lame is definitely the problem !
So, I have decided, for my app, that I will use a workaround - I will simply prefer transcoding to AAC instead of MP3. AAC transcoding is lightning fast on all my ffmpeg instances and my app supports AAC well. I will also continue to investigate the libmp3lame slowness problem, but for now, I am unblocked wrt my app.
Thanks to all for the help ! (Special thanks to @Gyan and @
llogan)
ffmpeg
asked Dec 19 '18 at 9:20
waldenCalmswaldenCalms
205
|
show 10 more comments
I have 2 separate ffmpeg instances on my macOS machine (10.14.2 Mojave and Intel Core i5-8259U Quad-core CPU @ 2.30GHz, if that helps):
1 - Installed with brew (and linked with my local dylib's)
2 - A static build downloaded from Zeranoe's ffmpeg builds
Both are v4.1. But, when transcoding the same file (OGG -> MP3) with the same command options, with the same system load, and everything else being equal ... instance #1 is roughly 3x faster than instance #2. I need to know why because I need to bundle a static ffmpeg build with my app, and it needs to perform optimally. See command output below:
The faster instance of ffmpeg (Note the speed is 46.5x):
$ ffmpeg -v quiet -stats -i ~/Reiki2.ogg -vn -sn ~/Reiki2.mp3
size= 26290kB time=00:28:02.54 bitrate= 128.0kbits/s speed=46.5x
The slower ffmpeg instance (Note the speed is 17.2x)
$ ./ffmpeg -v quiet -stats -i ~/Reiki2.ogg -vn -sn ./Reiki2.mp3
size= 26290kB time=00:28:02.54 bitrate= 128.0kbits/s speed=17.2x
Why the huge difference in performance ???
If I figure this out, I can then build ffmpeg myself with optimized performance matching my faster installed ffmpeg (i.e. #1).
Is it how the two instances were configured prior to make ? Do you see any significant configuration options that are the reason for this huge difference in performance ?
I am dying to know this since my app depends on ffmpeg performance. I would really appreciate any insights. Thanks in advance !
Instance #1 (faster) was configured as follows:
ffmpeg version 4.1 Copyright (c) 2000-2018 the FFmpeg developers
built with Apple LLVM version 10.0.0 (clang-1000.11.45.5)
configuration: --prefix=/usr/local/Cellar/ffmpeg/4.1 --enable-shared
--enable-pthreads --enable-version3 --enable-hardcoded-tables
--enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-ffplay
--enable-gpl --enable-libmp3lame --enable-libopus --enable-libsnappy
--enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264
--enable-libx265 --enable-libxvid --enable-lzma --enable-opencl
--enable-videotoolbox
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
Instance #2 (slower) was configured as follows:
ffmpeg version 4.1 Copyright (c) 2000-2018 the FFmpeg developers
built with Apple LLVM version 10.0.0 (clang-1000.11.45.5)
configuration: --enable-gpl --enable-version3 --enable-sdl2
--enable-fontconfig --enable-gnutls --enable-iconv --enable-libass
--enable-libbluray --enable-libfreetype --enable-libmp3lame
--enable-libopencore-amrnb --enable-libopencore-amrwb
--enable-libopenjpeg --enable-libopus --enable-libshine
--enable-libsnappy --enable-libsoxr --enable-libtheora
--enable-libtwolame --enable-libvpx --enable-libwavpack
--enable-libwebp --enable-libx264 --enable-libx265
--enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib
--enable-gmp --enable-libvidstab --enable-libvorbis
--enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex
--enable-libxvid --enable-libaom --enable-appkit
--enable-avfoundation --enable-coreimage --enable-audiotoolbox
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
------ UPDATE: ------
1 - I tried building libmp3lame myself with --enable-nasm and then ffmpeg using that built lame. No difference noticed ... still slow.
2 - I ran the same transcoding tests on a much older Mac, and the results were nearly identical (scaled down because it's a slower computer).
i.e. libmp3lame is definitely the problem !
So, I have decided, for my app, that I will use a workaround - I will simply prefer transcoding to AAC instead of MP3. AAC transcoding is lightning fast on all my ffmpeg instances and my app supports AAC well. I will also continue to investigate the libmp3lame slowness problem, but for now, I am unblocked wrt my app.
Thanks to all for the help ! (Special thanks to @Gyan and @
llogan)
ffmpeg
asked Dec 19 '18 at 9:20
waldenCalmswaldenCalms
205
1
Odd. Everything looks identical and there are no meaningful differences. I was wondering if it could be CPU optimisation but cannot find any evidence of the encoder or decoder using SIMD.
– Mokubai♦
Dec 19 '18 at 11:58
1
Have you tried other encoders -aac? Also, video encoding?
– Gyan
Dec 19 '18 at 12:29
1
AIFF isn't very instructive, as default codec is uncompressed. Try AAC and video transcoding. The aim is to identify the issue; doesn't matter if you won't be actually doing video stuff.
– Gyan
Dec 19 '18 at 12:43
1
Right. So looks to be a libmp3lame issue. Compile LAME and ffmpeg yourself and check.
– Gyan
Dec 19 '18 at 13:28
1
The command is using the inbuilt decoder, so not libvorbis.
– Gyan
Dec 19 '18 at 17:32
|
show 10 more comments
I have 2 separate ffmpeg instances on my macOS machine (10.14.2 Mojave and Intel Core i5-8259U Quad-core CPU @ 2.30GHz, if that helps):
1 - Installed with brew (and linked with my local dylib's)
2 - A static build downloaded from Zeranoe's ffmpeg builds
Both are v4.1. But, when transcoding the same file (OGG -> MP3) with the same command options, with the same system load, and everything else being equal ... instance #1 is roughly 3x faster than instance #2. I need to know why because I need to bundle a static ffmpeg build with my app, and it needs to perform optimally. See command output below:
The faster instance of ffmpeg (Note the speed is 46.5x):
$ ffmpeg -v quiet -stats -i ~/Reiki2.ogg -vn -sn ~/Reiki2.mp3
size= 26290kB time=00:28:02.54 bitrate= 128.0kbits/s speed=46.5x
The slower ffmpeg instance (Note the speed is 17.2x)
$ ./ffmpeg -v quiet -stats -i ~/Reiki2.ogg -vn -sn ./Reiki2.mp3
size= 26290kB time=00:28:02.54 bitrate= 128.0kbits/s speed=17.2x
Why the huge difference in performance ???
If I figure this out, I can then build ffmpeg myself with optimized performance matching my faster installed ffmpeg (i.e. #1).
Is it how the two instances were configured prior to make ? Do you see any significant configuration options that are the reason for this huge difference in performance ?
I am dying to know this since my app depends on ffmpeg performance. I would really appreciate any insights. Thanks in advance !
Instance #1 (faster) was configured as follows:
ffmpeg version 4.1 Copyright (c) 2000-2018 the FFmpeg developers
built with Apple LLVM version 10.0.0 (clang-1000.11.45.5)
configuration: --prefix=/usr/local/Cellar/ffmpeg/4.1 --enable-shared
--enable-pthreads --enable-version3 --enable-hardcoded-tables
--enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-ffplay
--enable-gpl --enable-libmp3lame --enable-libopus --enable-libsnappy
--enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264
--enable-libx265 --enable-libxvid --enable-lzma --enable-opencl
--enable-videotoolbox
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
Instance #2 (slower) was configured as follows:
ffmpeg version 4.1 Copyright (c) 2000-2018 the FFmpeg developers
built with Apple LLVM version 10.0.0 (clang-1000.11.45.5)
configuration: --enable-gpl --enable-version3 --enable-sdl2
--enable-fontconfig --enable-gnutls --enable-iconv --enable-libass
--enable-libbluray --enable-libfreetype --enable-libmp3lame
--enable-libopencore-amrnb --enable-libopencore-amrwb
--enable-libopenjpeg --enable-libopus --enable-libshine
--enable-libsnappy --enable-libsoxr --enable-libtheora
--enable-libtwolame --enable-libvpx --enable-libwavpack
--enable-libwebp --enable-libx264 --enable-libx265
--enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib
--enable-gmp --enable-libvidstab --enable-libvorbis
--enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex
--enable-libxvid --enable-libaom --enable-appkit
--enable-avfoundation --enable-coreimage --enable-audiotoolbox
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
------ UPDATE: ------
1 - I tried building libmp3lame myself with --enable-nasm and then ffmpeg using that built lame. No difference noticed ... still slow.
2 - I ran the same transcoding tests on a much older Mac, and the results were nearly identical (scaled down because it's a slower computer).
i.e. libmp3lame is definitely the problem !
So, I have decided, for my app, that I will use a workaround - I will simply prefer transcoding to AAC instead of MP3. AAC transcoding is lightning fast on all my ffmpeg instances and my app supports AAC well. I will also continue to investigate the libmp3lame slowness problem, but for now, I am unblocked wrt my app.
Thanks to all for the help ! (Special thanks to @Gyan and @
llogan)
ffmpeg
asked Dec 19 '18 at 9:20
waldenCalmswaldenCalms
205
I have 2 separate ffmpeg instances on my macOS machine (10.14.2 Mojave and Intel Core i5-8259U Quad-core CPU @ 2.30GHz, if that helps):
1 - Installed with brew (and linked with my local dylib's)
2 - A static build downloaded from Zeranoe's ffmpeg builds
Both are v4.1. But, when transcoding the same file (OGG -> MP3) with the same command options, with the same system load, and everything else being equal ... instance #1 is roughly 3x faster than instance #2. I need to know why because I need to bundle a static ffmpeg build with my app, and it needs to perform optimally. See command output below:
The faster instance of ffmpeg (Note the speed is 46.5x):
$ ffmpeg -v quiet -stats -i ~/Reiki2.ogg -vn -sn ~/Reiki2.mp3
size= 26290kB time=00:28:02.54 bitrate= 128.0kbits/s speed=46.5x
The slower ffmpeg instance (Note the speed is 17.2x)
$ ./ffmpeg -v quiet -stats -i ~/Reiki2.ogg -vn -sn ./Reiki2.mp3
size= 26290kB time=00:28:02.54 bitrate= 128.0kbits/s speed=17.2x
Why the huge difference in performance ???
If I figure this out, I can then build ffmpeg myself with optimized performance matching my faster installed ffmpeg (i.e. #1).
Is it how the two instances were configured prior to make ? Do you see any significant configuration options that are the reason for this huge difference in performance ?
I am dying to know this since my app depends on ffmpeg performance. I would really appreciate any insights. Thanks in advance !
Instance #1 (faster) was configured as follows:
ffmpeg version 4.1 Copyright (c) 2000-2018 the FFmpeg developers
built with Apple LLVM version 10.0.0 (clang-1000.11.45.5)
configuration: --prefix=/usr/local/Cellar/ffmpeg/4.1 --enable-shared
--enable-pthreads --enable-version3 --enable-hardcoded-tables
--enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-ffplay
--enable-gpl --enable-libmp3lame --enable-libopus --enable-libsnappy
--enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264
--enable-libx265 --enable-libxvid --enable-lzma --enable-opencl
--enable-videotoolbox
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
Instance #2 (slower) was configured as follows:
ffmpeg version 4.1 Copyright (c) 2000-2018 the FFmpeg developers
built with Apple LLVM version 10.0.0 (clang-1000.11.45.5)
configuration: --enable-gpl --enable-version3 --enable-sdl2
--enable-fontconfig --enable-gnutls --enable-iconv --enable-libass
--enable-libbluray --enable-libfreetype --enable-libmp3lame
--enable-libopencore-amrnb --enable-libopencore-amrwb
--enable-libopenjpeg --enable-libopus --enable-libshine
--enable-libsnappy --enable-libsoxr --enable-libtheora
--enable-libtwolame --enable-libvpx --enable-libwavpack
--enable-libwebp --enable-libx264 --enable-libx265
--enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib
--enable-gmp --enable-libvidstab --enable-libvorbis
--enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex
--enable-libxvid --enable-libaom --enable-appkit
--enable-avfoundation --enable-coreimage --enable-audiotoolbox
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
------ UPDATE: ------
1 - I tried building libmp3lame myself with --enable-nasm and then ffmpeg using that built lame. No difference noticed ... still slow.
2 - I ran the same transcoding tests on a much older Mac, and the results were nearly identical (scaled down because it's a slower computer).
i.e. libmp3lame is definitely the problem !
So, I have decided, for my app, that I will use a workaround - I will simply prefer transcoding to AAC instead of MP3. AAC transcoding is lightning fast on all my ffmpeg instances and my app supports AAC well. I will also continue to investigate the libmp3lame slowness problem, but for now, I am unblocked wrt my app.
Thanks to all for the help ! (Special thanks to @Gyan and @
llogan)
ffmpeg
ffmpeg
asked Dec 19 '18 at 9:20
waldenCalmswaldenCalms
205
asked Dec 19 '18 at 9:20
waldenCalmswaldenCalms
205
edited Dec 20 '18 at 21:34
waldenCalms
asked Dec 19 '18 at 9:20
waldenCalmswaldenCalms
205
asked Dec 19 '18 at 9:20
waldenCalmswaldenCalms
205
asked Dec 19 '18 at 9:20
waldenCalmswaldenCalms
205
205
1
Odd. Everything looks identical and there are no meaningful differences. I was wondering if it could be CPU optimisation but cannot find any evidence of the encoder or decoder using SIMD.
– Mokubai♦
Dec 19 '18 at 11:58
1
Have you tried other encoders -aac? Also, video encoding?
– Gyan
Dec 19 '18 at 12:29
1
AIFF isn't very instructive, as default codec is uncompressed. Try AAC and video transcoding. The aim is to identify the issue; doesn't matter if you won't be actually doing video stuff.
– Gyan
Dec 19 '18 at 12:43
1
Right. So looks to be a libmp3lame issue. Compile LAME and ffmpeg yourself and check.
– Gyan
Dec 19 '18 at 13:28
1
The command is using the inbuilt decoder, so not libvorbis.
– Gyan
Dec 19 '18 at 17:32
|
show 10 more comments
1
Odd. Everything looks identical and there are no meaningful differences. I was wondering if it could be CPU optimisation but cannot find any evidence of the encoder or decoder using SIMD.
– Mokubai♦
Dec 19 '18 at 11:58
1
Have you tried other encoders -aac? Also, video encoding?
– Gyan
Dec 19 '18 at 12:29
1
AIFF isn't very instructive, as default codec is uncompressed. Try AAC and video transcoding. The aim is to identify the issue; doesn't matter if you won't be actually doing video stuff.
– Gyan
Dec 19 '18 at 12:43
1
Right. So looks to be a libmp3lame issue. Compile LAME and ffmpeg yourself and check.
– Gyan
Dec 19 '18 at 13:28
1
The command is using the inbuilt decoder, so not libvorbis.
– Gyan
Dec 19 '18 at 17:32
1
1
Odd. Everything looks identical and there are no meaningful differences. I was wondering if it could be CPU optimisation but cannot find any evidence of the encoder or decoder using SIMD.
– Mokubai♦
Dec 19 '18 at 11:58
Odd. Everything looks identical and there are no meaningful differences. I was wondering if it could be CPU optimisation but cannot find any evidence of the encoder or decoder using SIMD.
– Mokubai♦
Dec 19 '18 at 11:58
1
1
Have you tried other encoders -
aac? Also, video encoding?– Gyan
Dec 19 '18 at 12:29
Have you tried other encoders -
aac? Also, video encoding?– Gyan
Dec 19 '18 at 12:29
1
1
AIFF isn't very instructive, as default codec is uncompressed. Try AAC and video transcoding. The aim is to identify the issue; doesn't matter if you won't be actually doing video stuff.
– Gyan
Dec 19 '18 at 12:43
AIFF isn't very instructive, as default codec is uncompressed. Try AAC and video transcoding. The aim is to identify the issue; doesn't matter if you won't be actually doing video stuff.
– Gyan
Dec 19 '18 at 12:43
1
1
Right. So looks to be a libmp3lame issue. Compile LAME and ffmpeg yourself and check.
– Gyan
Dec 19 '18 at 13:28
Right. So looks to be a libmp3lame issue. Compile LAME and ffmpeg yourself and check.
– Gyan
Dec 19 '18 at 13:28
1
1
The command is using the inbuilt decoder, so not libvorbis.
– Gyan
Dec 19 '18 at 17:32
The command is using the inbuilt decoder, so not libvorbis.
– Gyan
Dec 19 '18 at 17:32
|
show 10 more comments
1 Answer
1
active
oldest
votes
This is likely a bug from LAME
#491 lame 3.100 slower than 3.99.5
I informed Zeranoe and johnvansickle.com about this. John said this will be fixed with his git release on 20 December. He said he compiled lame with CFLAGS="-O3" CPPFLAGS="-DNDEBUG" resulting in a 3x speedup.
Be aware of nasm
Enabling nasm seems to make a significant difference for 3.100 compared to 3.99.5 in my lazy test on Arch Linux.
Both Zeranoe and John compile lame with --enable-nasm, so the slowness in their builds is due to the previously mentioned bug.
answered Dec 19 '18 at 19:08
lloganllogan
25.2k54577
Thanks a lot for this information and for doing the testing ! I will try this out and report back. BTW, if possible, could you update your post with the command output from your test runs ? I'm curious about the details. (Upvoted your answer but it won't show coz I'm a new user.)
– waldenCalms
Dec 19 '18 at 23:32
I built libmp3lame myself, with --enable-nasm ... no difference observed :( However, I found a workaround (read updated original post). Thanks !
– waldenCalms
Dec 20 '18 at 3:26
1
@waldenCalms I updated the answer. It's a bug.
– llogan
Dec 20 '18 at 19:16
Wow, thank you, Sir ! You are awesome :) Will look out for the fixed libmp3lame build and re-test with it !!! I will have to wait for Zeranoe because I'm on macOS, not Linux.
– waldenCalms
Dec 20 '18 at 20:57
1
@waldenCalms I recommend continuing using AAC if it is acceptable for you. Generally, it's usually a little better quality per bitrate (depends on the encoder and settings of course). And if you're muxing into MP4 then AAC is better supported than MP3.
– llogan
Dec 20 '18 at 21:10
|
show 1 more comment
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1385850%2fone-ffmpeg-instance-build-is-3x-slower-than-my-other-ffmpeg-instance-build-why%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
This is likely a bug from LAME
#491 lame 3.100 slower than 3.99.5
I informed Zeranoe and johnvansickle.com about this. John said this will be fixed with his git release on 20 December. He said he compiled lame with CFLAGS="-O3" CPPFLAGS="-DNDEBUG" resulting in a 3x speedup.
Be aware of nasm
Enabling nasm seems to make a significant difference for 3.100 compared to 3.99.5 in my lazy test on Arch Linux.
Both Zeranoe and John compile lame with --enable-nasm, so the slowness in their builds is due to the previously mentioned bug.
answered Dec 19 '18 at 19:08
lloganllogan
25.2k54577
Thanks a lot for this information and for doing the testing ! I will try this out and report back. BTW, if possible, could you update your post with the command output from your test runs ? I'm curious about the details. (Upvoted your answer but it won't show coz I'm a new user.)
– waldenCalms
Dec 19 '18 at 23:32
I built libmp3lame myself, with --enable-nasm ... no difference observed :( However, I found a workaround (read updated original post). Thanks !
– waldenCalms
Dec 20 '18 at 3:26
1
@waldenCalms I updated the answer. It's a bug.
– llogan
Dec 20 '18 at 19:16
Wow, thank you, Sir ! You are awesome :) Will look out for the fixed libmp3lame build and re-test with it !!! I will have to wait for Zeranoe because I'm on macOS, not Linux.
– waldenCalms
Dec 20 '18 at 20:57
1
@waldenCalms I recommend continuing using AAC if it is acceptable for you. Generally, it's usually a little better quality per bitrate (depends on the encoder and settings of course). And if you're muxing into MP4 then AAC is better supported than MP3.
– llogan
Dec 20 '18 at 21:10
|
show 1 more comment
This is likely a bug from LAME
#491 lame 3.100 slower than 3.99.5
I informed Zeranoe and johnvansickle.com about this. John said this will be fixed with his git release on 20 December. He said he compiled lame with CFLAGS="-O3" CPPFLAGS="-DNDEBUG" resulting in a 3x speedup.
Be aware of nasm
Enabling nasm seems to make a significant difference for 3.100 compared to 3.99.5 in my lazy test on Arch Linux.
Both Zeranoe and John compile lame with --enable-nasm, so the slowness in their builds is due to the previously mentioned bug.
answered Dec 19 '18 at 19:08
lloganllogan
25.2k54577
Thanks a lot for this information and for doing the testing ! I will try this out and report back. BTW, if possible, could you update your post with the command output from your test runs ? I'm curious about the details. (Upvoted your answer but it won't show coz I'm a new user.)
– waldenCalms
Dec 19 '18 at 23:32
I built libmp3lame myself, with --enable-nasm ... no difference observed :( However, I found a workaround (read updated original post). Thanks !
– waldenCalms
Dec 20 '18 at 3:26
1
@waldenCalms I updated the answer. It's a bug.
– llogan
Dec 20 '18 at 19:16
Wow, thank you, Sir ! You are awesome :) Will look out for the fixed libmp3lame build and re-test with it !!! I will have to wait for Zeranoe because I'm on macOS, not Linux.
– waldenCalms
Dec 20 '18 at 20:57
1
@waldenCalms I recommend continuing using AAC if it is acceptable for you. Generally, it's usually a little better quality per bitrate (depends on the encoder and settings of course). And if you're muxing into MP4 then AAC is better supported than MP3.
– llogan
Dec 20 '18 at 21:10
|
show 1 more comment
This is likely a bug from LAME
#491 lame 3.100 slower than 3.99.5
I informed Zeranoe and johnvansickle.com about this. John said this will be fixed with his git release on 20 December. He said he compiled lame with CFLAGS="-O3" CPPFLAGS="-DNDEBUG" resulting in a 3x speedup.
Be aware of nasm
Enabling nasm seems to make a significant difference for 3.100 compared to 3.99.5 in my lazy test on Arch Linux.
Both Zeranoe and John compile lame with --enable-nasm, so the slowness in their builds is due to the previously mentioned bug.
answered Dec 19 '18 at 19:08
lloganllogan
25.2k54577
This is likely a bug from LAME
#491 lame 3.100 slower than 3.99.5
I informed Zeranoe and johnvansickle.com about this. John said this will be fixed with his git release on 20 December. He said he compiled lame with CFLAGS="-O3" CPPFLAGS="-DNDEBUG" resulting in a 3x speedup.
Be aware of nasm
Enabling nasm seems to make a significant difference for 3.100 compared to 3.99.5 in my lazy test on Arch Linux.
Both Zeranoe and John compile lame with --enable-nasm, so the slowness in their builds is due to the previously mentioned bug.
answered Dec 19 '18 at 19:08
lloganllogan
25.2k54577
edited Dec 20 '18 at 19:53
answered Dec 19 '18 at 19:08
lloganllogan
25.2k54577
answered Dec 19 '18 at 19:08
lloganllogan
25.2k54577
answered Dec 19 '18 at 19:08
lloganllogan
25.2k54577
25.2k54577
Thanks a lot for this information and for doing the testing ! I will try this out and report back. BTW, if possible, could you update your post with the command output from your test runs ? I'm curious about the details. (Upvoted your answer but it won't show coz I'm a new user.)
– waldenCalms
Dec 19 '18 at 23:32
I built libmp3lame myself, with --enable-nasm ... no difference observed :( However, I found a workaround (read updated original post). Thanks !
– waldenCalms
Dec 20 '18 at 3:26
1
@waldenCalms I updated the answer. It's a bug.
– llogan
Dec 20 '18 at 19:16
Wow, thank you, Sir ! You are awesome :) Will look out for the fixed libmp3lame build and re-test with it !!! I will have to wait for Zeranoe because I'm on macOS, not Linux.
– waldenCalms
Dec 20 '18 at 20:57
1
@waldenCalms I recommend continuing using AAC if it is acceptable for you. Generally, it's usually a little better quality per bitrate (depends on the encoder and settings of course). And if you're muxing into MP4 then AAC is better supported than MP3.
– llogan
Dec 20 '18 at 21:10
|
show 1 more comment
Thanks a lot for this information and for doing the testing ! I will try this out and report back. BTW, if possible, could you update your post with the command output from your test runs ? I'm curious about the details. (Upvoted your answer but it won't show coz I'm a new user.)
– waldenCalms
Dec 19 '18 at 23:32
I built libmp3lame myself, with --enable-nasm ... no difference observed :( However, I found a workaround (read updated original post). Thanks !
– waldenCalms
Dec 20 '18 at 3:26
1
@waldenCalms I updated the answer. It's a bug.
– llogan
Dec 20 '18 at 19:16
Wow, thank you, Sir ! You are awesome :) Will look out for the fixed libmp3lame build and re-test with it !!! I will have to wait for Zeranoe because I'm on macOS, not Linux.
– waldenCalms
Dec 20 '18 at 20:57
1
@waldenCalms I recommend continuing using AAC if it is acceptable for you. Generally, it's usually a little better quality per bitrate (depends on the encoder and settings of course). And if you're muxing into MP4 then AAC is better supported than MP3.
– llogan
Dec 20 '18 at 21:10
Thanks a lot for this information and for doing the testing ! I will try this out and report back. BTW, if possible, could you update your post with the command output from your test runs ? I'm curious about the details. (Upvoted your answer but it won't show coz I'm a new user.)
– waldenCalms
Dec 19 '18 at 23:32
Thanks a lot for this information and for doing the testing ! I will try this out and report back. BTW, if possible, could you update your post with the command output from your test runs ? I'm curious about the details. (Upvoted your answer but it won't show coz I'm a new user.)
– waldenCalms
Dec 19 '18 at 23:32
I built libmp3lame myself, with --enable-nasm ... no difference observed :( However, I found a workaround (read updated original post). Thanks !
– waldenCalms
Dec 20 '18 at 3:26
I built libmp3lame myself, with --enable-nasm ... no difference observed :( However, I found a workaround (read updated original post). Thanks !
– waldenCalms
Dec 20 '18 at 3:26
1
1
@waldenCalms I updated the answer. It's a bug.
– llogan
Dec 20 '18 at 19:16
@waldenCalms I updated the answer. It's a bug.
– llogan
Dec 20 '18 at 19:16
Wow, thank you, Sir ! You are awesome :) Will look out for the fixed libmp3lame build and re-test with it !!! I will have to wait for Zeranoe because I'm on macOS, not Linux.
– waldenCalms
Dec 20 '18 at 20:57
Wow, thank you, Sir ! You are awesome :) Will look out for the fixed libmp3lame build and re-test with it !!! I will have to wait for Zeranoe because I'm on macOS, not Linux.
– waldenCalms
Dec 20 '18 at 20:57
1
1
@waldenCalms I recommend continuing using AAC if it is acceptable for you. Generally, it's usually a little better quality per bitrate (depends on the encoder and settings of course). And if you're muxing into MP4 then AAC is better supported than MP3.
– llogan
Dec 20 '18 at 21:10
@waldenCalms I recommend continuing using AAC if it is acceptable for you. Generally, it's usually a little better quality per bitrate (depends on the encoder and settings of course). And if you're muxing into MP4 then AAC is better supported than MP3.
– llogan
Dec 20 '18 at 21:10
|
show 1 more comment
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1385850%2fone-ffmpeg-instance-build-is-3x-slower-than-my-other-ffmpeg-instance-build-why%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Odd. Everything looks identical and there are no meaningful differences. I was wondering if it could be CPU optimisation but cannot find any evidence of the encoder or decoder using SIMD.
– Mokubai♦
Dec 19 '18 at 11:58
1
Have you tried other encoders -
aac? Also, video encoding?– Gyan
Dec 19 '18 at 12:29
1
AIFF isn't very instructive, as default codec is uncompressed. Try AAC and video transcoding. The aim is to identify the issue; doesn't matter if you won't be actually doing video stuff.
– Gyan
Dec 19 '18 at 12:43
1
Right. So looks to be a libmp3lame issue. Compile LAME and ffmpeg yourself and check.
– Gyan
Dec 19 '18 at 13:28
1
The command is using the inbuilt decoder, so not libvorbis.
– Gyan
Dec 19 '18 at 17:32