First of all, Thanks for a great piece of software.
I am trying to compress some presentation videos to x264 format, comprising of mostly animated slides with voice-over, on Windows 10 64bit. My video encoding configuration screenshot is attached.x264 encoding config.PNG
With 2.6.21, I get 300+ frames/sec while encoding, please see the attached screenshotencoding speed.PNG.
This drops to about 200 with 2.7.8 downloaded from http://www.avidemux.org/nightly/win64/
With release version 2.7.6, it drops to 70 frames per second, and quantiser is between 20-30, with same encoding settings.
Any idea why the drop in performance over old version?
I am keen to use newer version for - 1. better file loading speed, 2. better scripting support.
Dozens of issues are fixed in the latest release compared to 2.7.6, much more issues were solved and features added compared to the 2.6.x generation. I don't think that using anything older than 2.7.8 can be even remotely considered.
I can only speculate about the reason why the "ultrafast" x264 preset in 2.6.21 was that fast. You could provide admlog.txt from encoding one and the same file with 2.6.21 and with 2.7.8.
By the way, the MP4v2 (libmp4v2) muxer is deprecated and effectively unsupported. All improvements go into the actively developed MP4 (libavformat) muxer.
Tested with the same settings, encoding fps is the same in 2.7.8 and 2.6.20 (almost 21 :) ).
What codec the source has? I did notice MPEG 1/2 decoding is faster in the old version, but modern codec decoding is significantly faster in 2.7.8
Thank you for your replies.
Quote from: eumagga0x2a on March 10, 2021, 05:06:37 PMDozens of issues are fixed in the latest release compared to 2.7.6, much more issues were solved and features added compared to the 2.6.x generation. I don't think that using anything older than 2.7.8 can be even remotely considered.
I can only speculate about the reason why the "ultrafast" x264 preset in 2.6.21 was that fast. You could provide admlog.txt from encoding one and the same file with 2.6.21 and with 2.7.8.
By the way, the MP4v2 (libmp4v2) muxer is deprecated and effectively unsupported. All improvements go into the actively developed MP4 (libavformat) muxer.
Here are the logs for the same file encoded by 2.6.21 and 2.7.8
admlog-2-6-21-x264-AAC-fdk-MP4.txt
admlog-2-7-8-x264-AAC-fdk-MP4.txt
Quote from: szlldm on March 10, 2021, 06:46:44 PMTested with the same settings, encoding fps is the same in 2.7.8 and 2.6.20 (almost 21 :) ).
What codec the source has? I did notice MPEG 1/2 decoding is faster in the old version, but modern codec decoding is significantly faster in 2.7.8
Here is the source codec info from VLC
source file codec.PNG
It looks like decoding of older MPEG4 codecs (DivX, Xvid, etc.) is slower.
In 2.7.1v2 the decoding is as fast as in 2.6.20.
In 2.7.2 the decoding is significantly slower (almost half fps).
In the new 2.7.8 the multithreaded decoding helps a lot, but still somewhat slower.
Even so, i suggest using 2.7.8.
Were you able to verify by benchmarking that decoding is the bottleneck?
Using ultrafast preset, it looks like decoding is the botleneck.
Could you please benchmark decoding only (i.e. using null encoder and Dummy output)?
QuoteIt looks like decoding of older MPEG4 codecs (DivX, Xvid, etc.) is slower.
In 2.7.1v2 the decoding is as fast as in 2.6.20.
In 2.7.2 the decoding is significantly slower (almost half fps).
In the new 2.7.8 the multithreaded decoding helps a lot, but still somewhat slower.
Thanks, I didn't miss that info, but it was not clear that you used null + dummy.
2.7.1 --> 2.7.2 is FFmpeg 3.x --> 4.x
I was pretty sure ffmpeg change was the cause ;D
I've just benchmarked the legacy-compat branch (ffmpeg 3.3.9) and the current git master (ffmpeg 4.2.4) on Linux. With multi-threading disabled, I get fps ~ 500 with both, with a minimal advantage for 4.2.4 (maybe around 10 fps more). With multi-threading enabled on git master, I get a... significant (~30) fps drop!
Tested with a 856x480 divx clip about 8 min in duration.
Now it would be interesting to compare MinGW with VC++.
720p .mov file, fourCC DIVX
2.7.1v2 --> 690 fps
2.7.2 --> 390 fps
2.7.8 w/o MT --> 380 fps
2.7.8 w MT --> 510 fps
(2.7.8 buit from source)
Benchmarked on Linux?
I get moderately faster results with 2.7.1v2 for the clip I mentioned earlier, ~ 550 fps.
I'm going to create a 1280x720 sample and retry. The size can actually matter.
With a 1280x720 sample of ~10 minutes duration, I can fully confirm your findings.
| 2.7.8 with MT: | 222 fps |
| 2.7.8 w/o MT: | 174 fps |
| 2.7.1 MT n/a: | 309 fps |
Pretty remarkable.
So, any suggestion to make 2.7.8 as fast as 2.6.21?
No, the performance degradation seems to be related to upstream changes in FFmpeg during the 3.x.x --> 4.0 transition. It is beyond my skills to investigate this and the importance of the issue cannot be lower (the output is not corrupted, the speed is still good, the affected codecs are obsolete).
Unless a future update to FFmpeg 4.4 or 4.3.x improves the speed, I don't think I am going to take any action.