2.7.1 64 bit much slower in saving files than 2.6.11 64 bit

[GeorgeSK]

I have been using version 2.6.11 since it came out.

I don't know what happened after that release, if the codecs got slower or what, but each subsequent release was slower than 2.6.11 in saving files, that is why I always reverted to it after trying out new versions periodically.

I usually need only to trim some mp4 clips and concatinate/save them as one file. The old 2.6.11 does so at the speed of around 1400 fps, the newest 2.7.1 at around 560 fps for the same files, a 60% drop in speed, which is very noticeable - the same file in old version saves in around 30-40 seconds, the new version saves it in 2 minutes. Encode priority on both versions set at High.

First I thought it was a problem with my old hardware, but the same behaviour can be observed on my brand new laptop with a Core i5 8250U quad core CPU, 8 gigs RAM and 256 gig SSD.

Am I doing something wrong in the settings? Please help, I like the new version but the slowdown of file saves is very noticeable and if I cannot find a solution I will have to revert to 2.6.11 again.

[eumagga0x2a]

In copy mode, codecs are not involved in any way.

This is interesting, I checked the speed when saving a ~4 GiB mp4 file (H.264 FullHD video + AC3 audio) in copy mode with the MP4 muxer using a build from the current git master on Linux running on my pretty obsolete hardware (an AMD dual core which was mid-range 8 years ago, source video and target video on different HDDs): the average fps was 1476. It took 60 seconds to save the video while the optimization part (skipped on Windows) took slightly less than two minutes (~115 seconds).

If win64 builds are that much slower, it might be due to deficiencies of the build chain used for cross-compiling.

Could you please try the latest native Windows nightly build from https://avidemux.org/nightly/vsWin64/ in comparison with the latest available cross-build https://avidemux.org/nightly/win64/? While native builds are generated from the ffmpeg4x git branch vs the git master with older ffmpeg for cross-builds, this detail should not matter really much.

[GeorgeSK]

Your analysis was spot on. I couldn't believe my eyes, the difference between the native Windows build and the cross-build was like night and day, the Windows build saving the 309 MB test file almost instantaneously thanks to my SSD, at around 7000 fps, the cross-build trudged along at 1/10 of that.

Though I noticed one more difference - the latest nightly cross-build from 28/11/2018 still had 2 MP4 options, I used the MP4 v2 option for this test, but the latest nightly native Windows build only one. There are two screenshots in attachment, I tried to catch the same stage in saving.

Needless to say for now I am staying with the native Windows builds - 10x faster on my machine, plus a smaller installer, and I presume a smaller installed footprint also.

Thanks for your help, I can use the latest version now and forget about 2.6.11 for good.

[dosdan]

I have a 5.5yo I5-3470, 16GB, GT640. Using a SSD as the source and destination, and a 4GB MP4 with AAC in Copy/Copy mode, I couldn't notice much of a performance difference between VCC++ 181211 in vsWin64  and 181112 in Win64. Both are around 6000-7000fps, usually around 6900fps  It's happening pretty quickly, 7-9s, and the fps figures are jumping around, so you have to record just before the encode window closes. Caching may also be playing a part here.

Dan.

[eumagga0x2a]

Is there a speed difference in the cross build between MP4 and MP4v2? libmp4v2 doesn't seem to be actively developed anymore and the muxer plugin didn't get any attention since ages. The internal libavformat (MP4 without "v2") should be better in most use cases.

The installer is smaller because many features are missing in native builds.

I divided the number of frames by the time measured with a timer, so my fps value is solid.

[GeorgeSK]

Yes, there is a noticeable difference, the MP4 setting is almost as fast as the native Windows build, MP4v2 is slow - the same as before.

For some reason - at least on my machine - the native Windows build is still faster, though it depends on the test file - with a different file the difference was marginal, both builds going up to 20k fps in peak!!!

Again - your analysis was right, the libmp4v2 was the culprit.

[eumagga0x2a]

Does it mean, you always tried MP4v2 only? And with 2.6.11? Was MP4v2 not yet available there?

[GeorgeSK]

In 2.6.11 I also used MP4v2 only, but it worked a bit better than in later versions at 1400 fps. Most tutorials cite MP4v2 as better, having better comopatibility with iPhones, etc.

[eumagga0x2a]

Most tutorials cite MP4v2 as better, having better comopatibility with iPhones, etc.

Unfortunately, most tutorials related to Avidemux are terribly outdated and cause a lot of confusion.

Nevertheless, I wonder what might have caused such a significant performance regression with the libmp4v2 based muxer.

[eumagga0x2a]

On Linux, the MP4v2 muxer is exactly as fast saving video as the MP4 one, the total time is even much lower as the optimization step, which requires the file to be rewritten, is omitted. Can't test on Windows yet, will try later.