News:

--

Main Menu

Encoding speed slower in 2.7.8 than 2.6.21

Started by Xaar, March 10, 2021, 12:16:51 PM

Previous topic - Next topic

Xaar

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.You cannot view this attachment.

With 2.6.21, I get 300+ frames/sec while encoding, please see the attached screenshotYou cannot view this attachment..
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.

eumagga0x2a

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.

szlldm

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

Xaar

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
You cannot view this attachment.
You cannot view this attachment.


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
You cannot view this attachment.

szlldm

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.

eumagga0x2a

Were you able to verify by benchmarking that decoding is the bottleneck?

szlldm

Using ultrafast preset, it looks like decoding is the botleneck.

eumagga0x2a

Could you please benchmark decoding only (i.e. using null encoder and Dummy output)?

szlldm

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.

eumagga0x2a

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

szlldm

I was pretty sure ffmpeg change was the cause  ;D

eumagga0x2a

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.

eumagga0x2a

Now it would be interesting to compare MinGW with VC++.

szlldm

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)

eumagga0x2a

Benchmarked on Linux?

I get moderately faster results with 2.7.1v2 for the clip I mentioned earlier, ~ 550 fps.