Why is Avidemux so bad?

[deadrats]

the underlying sentiment still holds, even if it comes in portable form maybe some people don't want to have a dozen different folders each with a different app when just one will do.

do you also use half a dozen different browsers or do you just pick one and call it a day?

[hello_hello]

I tend to "install" portable programs all the time. Partly because I can't think of a more accurate word, but mainly because it's easier to say "installed' than "downloaded and extracted to my hard drive".

[DUDERANCH]

Sorry I was away that's why I didn't respond.

Link me to a raw video clip I can download (or I can make one myself) and give identical settings for Handbrake & Avidemux. Then I will do another test.

As I said in the OP... Avidemux took over 20+ minutes to render on an i7 with hyper-threading. That is just sad... Sorry but I see no excuse there regardless that it is an 'editor.'

I rendered on an i5 3570k, same settings, and it took only 9 minutes.

Can you explain that? An i7 will always beat an i5, even with hyper-threading disabled.

Also, by other free editing programs I meant something like Lightworks.

[gregalan]

I double checked with media info to make sure the x264 settings were the same in the output files, also the encoded file sizes were identical.

Identical?
In every way?
Do you know what the odds of that are?

I'd LOVE to see a screenshot of that.


Of course we will never see the screenshot.
We MAY see a MediaInfo text file but I'm SURE you won't edit it to make the two encodes identical....RIGHT?

I quess I should have said "virtually" the same size as there is a slight difference.

I rechecked the settings for x264 in avidemux and there was a lookahead setting I missed, I did the test again after correcting the setting and the speed difference was less, Avidemux was only around 16% slower.

I don't know, but it maybe the x264 versions have some impact on speed, I'm using Avidemux 2.5.6-1 with core 125 , and I compiled Ffmpeg with the newest x264 core 135 version.

Don't question my veracity again.

[hech54]

I quess I should have said "virtually" the same size as there is a slight difference.

But you didn't. You used the word "identical"......Then there is that little matter of VBR vs. CBR audio.

Don't question my veracity again.

I just did.....again.

Why anyone would fire up an editor just to transcode something is beyond me. I guess it's the same mentality many people have to fire up Nero to burn a VIDEO_TS folder or an .iso image of a DVD.....knowing full well that ImgBurn is better, faster and was designed solely for that purpose.....THEN come here to complain about the Nero disc not playing in some players.
I can't wait for your in-depth analysis of the transcoding speed of Sony Vegas or Adobe Premier Pro......or the soon-to-be-released GregalanFree Superfast Editor Transcoder Suite(?).

[hech54]

do you also use half a dozen different browsers or do you just pick one and call it a day?

I have 3 browsers.
Chrome works best with MEGA.
Opera is the best at circumventing GEMA's ridiculous tactics of blocking music and videos here in Germany.
Firefox is the easiest for plain old browsing.

HandBrake is best for transcoding to iPhone/iPod Touch.
AviDemux is best for replacing audio in videos and syncing audio WITHOUT effecting the video(or audio) quality and cutting MPEG2 files that contain LPCM without quality loss.
MPEGVCR gets me more accurate cuts in MPEG2 files(than Avidemux) but it cannot fix audio sync in the same process but I don't think it can pass-thru LPCM audio(at least I never found that setting).
VirtualDub can capture video, and I use it for simple filtering then frameserving.
DScaler is much easier to understand and has never dropped any frames when capturing(unlike the myriad of setting you need to go through in VDub to get it to stop dropping frames).
Magix Movie Edit works best when capturing straight to MPEG2 from my VCRs.
WinTV has the ability to capture PAL60 easily with only one extra step(but it lacks the fine-tuning like bitrate settings and audio capture settings that Magix has).


Starting to get the picture now?

[DB83]

@OP

I was hoping to see the comparisons based on your original 'RAW' video.

[DUDERANCH]

Settings:

Audio - AAC
Container - mp4
Codec - h264

Avidemux finished in 9:13
Handbrake finished in 4:35

Avidemux File Size - 743mb
Handbrake File Size - 577mb

Handbrake was not even maxing out the CPU.

[hech54]

Settings:

Audio - AAC
Container - mp4
Codec - h264

Avidemux finished in 9:13
Handbrake finished in 4:35

Avidemux File Size - 743mb
Handbrake File Size - 577mb

Handbrake was not even maxing out the CPU.

Something isn't quite right here:

All settings are the same.

x264
container mp4
quality - 18

There is no excuse whatsoever for Avidemux taking 20+ minutes to render on an i7. Handbrake does it with proper times, Avidemux does not.

I've said it before and I'll say it again.
When you are in a hole......stop digging.

[DUDERANCH]

Settings:

Audio - AAC
Container - mp4
Codec - h264

Avidemux finished in 9:13
Handbrake finished in 4:35

Avidemux File Size - 743mb
Handbrake File Size - 577mb

Handbrake was not even maxing out the CPU.

Something isn't quite right here:

All settings are the same.

x264
container mp4
quality - 18

There is no excuse whatsoever for Avidemux taking 20+ minutes to render on an i7. Handbrake does it with proper times, Avidemux does not.

I've said it before and I'll say it again.
When you are in a hole......stop digging.

Please explain why an i5-3570k renders more than 12 minutes faster than an i7-3770 with hyper-threading in Avidemux? I would love to read your explanation...

Now I have done my part and uploaded proof.

If someone wants to give me their own video clip and specific settings I will happily do some more tests.

[hech54]

Please explain why you were comparing an editor to dedicated transcoding software.....and NOW....
Please explain why you now have abandoned that foolishness and are comparing processors.
Please explain why earlier you said you used quality - 18 in both softwares when your screenshot says Quantizer - 24.
Please explain (with a screenshot) what quality/quantizer Handbrake(remember Handbrake) was used during your "proof".
Please explain the difference between "Quality" and "Quantizer".
Please let us know when you release the free and super-fast DUDERANCHTranscoderEditorSuperTool so we can critique it.
Please keep digging that hole.

[hello_hello]

DUDERANCH,
Unfortunately posting screenshots of encoding times does nothing but prove the encoding time, which is meaningless unless the same settings are used.
Handbrake's normal profile doesn't use the default x264 settings. High Profile does. There's no way we can see what settings were used by Avidemux.
One of the main reasons I never got around to doing another comparison is I didn't think AviDemux wrote the x264 settings to the output file so I couldn't
confirm they were the same. After accidentally using AVI as the output container today I discovered it does, if the output container is AVI.
For some reason when outputting to MKV those settings are lost.
It took several attempts to confirm Avidemux was using the x264 defaults, but then I ran comparison encodes of a 4 minute video. Video only.
I selected copy for the audio using Avidemux as it doesn't seem to have an option not to include the audio.
Avidemux doesn't seem to give you access to x264's VBV settings whereas Handbrake's High Profile enforces them for Level 4.1 by default,
although I doubt they would have made any difference. I could at least use the same VBV settings and Level as Handbrake with MeGUI.
The encoder configuration also seems to have a few oddities. For instance the "fast skip detection on P frames" checkbox seems
to disable fast skip detection when it's checked so I think it should be correctly labelled "no fast skip detection on P frames".

Here's the resulting encoding times for each GUI along with the average bitrate according to MediaInfo (I used CRF18 each time).
Give or take a second or two. I used the info each GUI was displaying.

MeGUI: 1 minute 54 seconds, 1079 Kb/s
Handbrake: 1 minute 58 seconds, 1076 Kb/s
Avidemux: 1 minute 53 seconds, 1076 Kb/s

Each encode was run using my old E6750 dual core.
Here's the MediaInfo from each encode. I just posted the x264 settings so you can see they're the same.

MeGUI:


Handbrake:


Avidemux:

[hello_hello]

Please explain why earlier you said you used quality - 18 in both softwares when your screenshot says Quantizer - 24.

Avidemux seems to display the quantizer value currently being used regardless of the encoding method.

[badyu17]

Someone tell a use for this program. I really liked it at first for it's simplicity until I found out these astonishing results.

I can tell you that I use this program for TWO things that are really usefull for me. I can edit (remove unwanted stuff) from .ts or mkv files and save it back to mkv. VideoReDo also does this stuff and it's got better gui but sometimes I have problems with edited files. Also avidemux never caused syncing issues even with two audio tracks.

The second feature that I like is that I can see the timecode AND the type of the frame of decoded video so that I can easily use that as visual reference for creation of chapter files in mkvmerge GUI. Yes, I like to join many videos in one and make chapter points.

So there, I didn't follow the rest of the discussion here but even though I don't use it for encoding of filtering I have some really useful things from this free app.

[DUDERANCH]

Please explain why you were comparing an editor to dedicated transcoding software.....and NOW....
Please explain why you now have abandoned that foolishness and are comparing processors.
Please explain why earlier you said you used quality - 18 in both softwares when your screenshot says Quantizer - 24.
Please explain (with a screenshot) what quality/quantizer Handbrake(remember Handbrake) was used during your "proof".
Please explain the difference between "Quality" and "Quantizer".
Please let us know when you release the free and super-fast DUDERANCHTranscoderEditorSuperTool so we can critique it.
Please keep digging that hole.

You may be an expert on videos, but if you think it's normal that an i7 3770 is slower than a 3570k even with hyper-threading off you are very mistaken.

[hello_hello]

It'd be perfectly normal if the x264 settings aren't the same. Why not use MediaInfo to post screenshots of the settings from each encode so we can see what they are?
And at the same time run the encodes using the same PC and post the encoding times.
You haven't as yet posted anything which really proves Avidemux is slower than Handbrake when all is equal.

[_Al_]

Avidemux File Size - 743mb
Handbrake File Size - 577mb

You test the same codec, so you should get the same size. You got different volume and that means different settings were used.

[DUDERANCH]

I did test the same codec.

Give me the exact settings then and I will do the test again.

I did the Handbrake High Profile test and the file was only 2mb bigger and only took 9 seconds longer to render. Same quality and still faster than Avidemux.

[Steve(MS)]

DUDERANCH, download mediainfo then display (tree view) both program's files.
As mentioned, you must use the same computer, not 2 different ones since there is need to take out variables.
Since you are insistent that it is not good for anything perhaps use other progs of your choice, no one is making you use it.
There are many programs and we can pick and choose what we want.

Even if Avidemux is slower, it has been around for a long time, likely many of us who have used it have chucked rocks at it for various reasons yet there are things that it can do, for instance change wrappers, even edit roughly in the meantime... and convert.
It would take a long writeup to state all this program can do.

[DUDERANCH]

I am using the same computer... I did both tests on the same computer - 3570k.

Secondly Avidemux might be a fine basic editing program. I was using it to shorten clips when I first signed up on this forum.

Then I tried out Handbrake, which I hadn't used in years... It demolished Avidemux in encode times.

So give me the exact Avidemux settings. I have Handbrake set to High Profile and quality 18, touching nothing else.

Then I will get this mediainfo and post screenshots.

[hech54]

Then I will get this mediainfo and post screenshots.

Beware of MediaInfo, the latest version is loaded with toolbars and shit.

[Steve(MS)]

Then I will get this mediainfo and post screenshots.

Beware of MediaInfo, the latest version is loaded with toolbars and shit.

I found a portable version somewhere late last year, that is what I am using.

[hello_hello]

The problem with Avidemux is it doesn't seem to automatically save the current encoder settings when you close it,
instead reverting back to the settings it uses by default, so all the work I did configuring the encoder the other day was lost.

So give me the exact Avidemux settings. I have Handbrake set to High Profile and quality 18, touching nothing else.
Then I will get this mediainfo and post screenshots.

I matched Avidemuix's encoder settings with Handbrake's, by running a small encode with each, noting the settings with MediaInfo,
changing the appropriate settings in Avidemux and running another small encode, changing whatever I got wrong,
running another encode etc..... until I got them to match.
I guess as I've already done the work once though it shouldn't take me too long to do it a second time.

I'm pretty sure this will give you the equivalent to Handbrake's High Profile preset, assuming you're using
the latest version of Handbrake and assuming you haven't fiddled with it. If you have, reset it first.
I'm also using the current version of Avidemux. Judging from the x264 build in one of your earlier MediaInfo screenshots, I don't think you are.
You will see some differences. Handbrake applies VBV settings automatically whereas Avidemux doesn't seem to let you use them,
but they shouldn't make any difference for the purpose of the exercise.
The keyint values might be a little different as Handbrake doesn't give you access to them (or automatically sets them
according to the frame rate) but once again it shouldn't effect an encoding speed test.

Someone may be able to see if I've missed anything, but from what I can tell using MediaInfo the settings below are
the same as Handbrake's High Profile which is the same as using the x264 defaults.
Except the CRF value and AVC level. Handbrake's High Profile defaults to CRF 20 whereas the default for x264 is 23, and it uses
High Profile, Level 4.1 so I set the same for Avidemux.

[DUDERANCH]

I copied your exact settings. I even left default quality @ 20.

The only thing I had to change in all of those settings was in the partition tab. I had to check the second and third check boxes and uncheck the fourth.

Handbrake gave me a smaller file size and also rendered more than a minute and a half faster.

Avidemux was faster this time, but Handbrake still won.

Also with Avidemux I set priority to 'High' and opposed to normal or the default option which is lowest. I assume Handbrake gets all priority so I thought that would make it even.

[poisondeathray]

Try using a newer avidemux version

Some of the difference might be "core 106" according to mediainfo which is quite dated - It correlates to libx264 about 2 years old r1773

Same with handbrake, r2273 is newer than the version of libx264 used by your old avidemux build, but still "older" in that it's not taking advantage of AVX2 instruction sets on Haswell

[DUDERANCH]

I rendered these tests on 3570k which is Ivy Bridge and has AVX, not AVX 2.0.

The i7 3770 is also Ivy Bridge.

My Handbrake version cannot be old... I downloaded it a few days ago from the Handbrake website.

The Avidemux is version 2.6.3 - according to the website the newest version is 2.6.4. I have only been using Avidemux since I signed up on this forum in April.

[poisondeathray]

OK, it won't matter for Ivy Bridge, I think handbrake nightlies have updated x264 versions with the new instruction sets. It's about 5-6% faster

Maybe mediainfo is wrong then? Or you mixed up the results ?

Avidemux versions 2.6.x print the r2xxx along with the core number. "Core 106" is definitely old


The "heavy lifting" is all done by x264 (or libx264) . Avidemux and handbrake are just GUI's. If you use the same pre processing, same filters, the same settings - you will encode the same speed if you use the same libx264 version.

[DUDERANCH]

versions

[poisondeathray]

Try updating avidemux to the newest one ; it might have been compiled with the wrong libx264

Look at hello hello's screenshots, it says core 129 r2230 in the version he was using . His encodes were about the same +/- a percent or two



The reason it makes a difference - x264 encoding speed over the years is about 13-15x faster than r1 . Small speed improvement increments , new instruction sets here and there 1% here, 1% there add up to something substantial. When you use and older libx264 about 2 years old, chances are it's going to be slower and produce somewhat lower quality

You need to compare apples and apples



Your question was "why is avidemux so bad" - that's probably at least part of the answer

[DUDERANCH]

Newest version from the site - 2.6.4.

The Core says 123 where Handbrake says Core 130.

Also in that test I rendered the audio bite rate in 128kbs with Avidemux instead of 160 like Handbrake. Avidemux file size was still bigger.