View Profile
View Forum Posts
Private Message
But - Did you notice it get substantially faster than your previous tests on core 106 ?
You're still using older libx264 r2273 vs. r2189
If you look at the x264 changelog , there were a bunch of speed optimization commits during that time, also some affecting SandyBridge, IvyBridge AVX (not AVX2) sets
https://www.videohelp.com/tools/x264-Encoder/version-history#changelog
Try using the version hello_hello used . I'm not sure where he got it. It ended up slightly faster (ok, not really if you account error margin) and smaller filesize at the same settings
Guess what? If you use the exact same x264 revision - you will get the exact same encode, exact same speed - assuming all the other things like decoding, processing are the same
+ Reply to Thread
Results 61 to 90 of 104
-
-
Well then he is going to have to send me his version. I got the latest version so I am not sure how he could have something newer? Maybe he's using a Mac or Linux version?
I did some tests on Mac using an old version of Avidemux because the Mountain Lion version on the website did not work on Snow Leopard machines. -
He's on a PC .
You can try nightly builds, they usually are compiled with more recent libraries
Here are avidemux nightly builds for OSX
http://www.avidemux.org/nightly/osx/
Nightly handbrake builds (including OSX)
http://handbrake.fr/nightly.php
Note: more recent isn't always "better", often new bugs are introduced , hence these nightly builds are usually only used by beta testers
Unless you compile libx264 yourself , or use commandline x264.exe it's usually the only way of getting the newest latest and greatest patches for x264 . The "official" avidemux and handbrake builds are usually a few months (or sometimes years behind). I remember handbrake was stuck at an old version for a few years a while back -
From your MediaInfo I can also see that Handbrake is using VFR. Turn that off and try again.
In my experience, Handbrake trades off an almost imperceptible amount of quality for speed. Which is why for important transcodes like backups, I avoid Handbrake. If it's just for my mobile or tablet, Handbrake is fine. But not on an HD monitor, the flaws are apparent. You can tell if you look carefully, Handbrake's quality is slightly worse than other encoders with the benefit that it encodes slightly faster. It must be the settings are different. x264 has an alarming number of settings under the hood.
That said, it shouldn't be faster if you match the settings of other encoders exactly. I have never liked Avidemux as it has always been buggy and terrible at h264. Though I'll admit I haven't looked at recent builds.Last edited by blud7; 15th Aug 2013 at 15:35.
-
He said to use High Profile and I used all default settings - Variable Frame Rate being one of them.Originally Posted by blud7
-
I understand that. I'm pointing out that even Handbrake's High Profile setting is non-standard.Originally Posted by DUDERANCH
He said to use High Profile and I used all default settings - Variable Frame Rate being one of them.Originally Posted by blud7
If you want a true comparison, they have to be exact IMHO
-
That may be because we're using different versions of avidemux.Originally Posted by DUDERANCH
I thought I'd installed the latest version. I just checked and I'm using 2.6.1. I'm not sure how that happened, or how it appears to be using a later x264 revision than the version of Avidemux you're using. I'm 100% sure I downloaded Avidemux directly from this site a few days ago when all this started. I didn't look at the version number, I just used the direct download link.
I might try again later after installing the newer version, because 2.6.1 won't reload the x264 settings after I save them, which is damn annoying.
I minute and a half faster for a 13 minute encode is getting closer.Originally Posted by DUDERANCH
The audio is different. Did you re-encode it each time?
Ideally for the moment at least, you'd probably want to exclude the audio so it can't effect the result. Or copy it rather than re-encode it.
As long as another program isn't competing for CPU time the priority setting shouldn't make any difference.Originally Posted by DUDERANCH
Okay.... maybe that's my bad. I'm not a Handbrake user myself, so the whole variable frame rate thing didn't occur to me.Originally Posted by DUDERANCH
When I said use High Profile as it uses the x264 default settings, I was referring to x264 settings only.
Well I thought about it when I was running my own test encodes, but as I was using a constant frame rate source anyway, the setting doesn't make a difference.
Just because MediaInfo says one encode is VFR and the other CFR, it doesn't mean it made a big difference, but it could if the source video is VFR and Avidemux converted it to CFR. It may be Avidemux doesn't understand VFR and just assumes it's CFR. I don't know, but it'd be better to compare speed using a CFR source video so they're definitely both encoding the same number of frames.
Speaking of which, what is your source video? Do you have any filters enabled?
"My bad" again, but Handbrake's High Profile enables the decomb filter by default so you probably should disable it, at least if you're not using any filtering with Avidemux.
Because I use a GUI which doesn't enable stuff like that until you specifically tell it to, I kind of forget other GUIs do.
And the third "my bad' would be forgetting that by default High Profile includes the audio, and converts it, or something. I removed the audio when I was testing with Handbrake and copied it using Avidemux (as I couldn't work out how to not include it at all).
I asked about the source video, although as long as you're using the same each time and encoding using a constant frame rate it shouldn't matter, but have you tried a different source?
In my case I used a standard Xvid/AVI which I knew was progressive and wouldn't need any filtering. And I did disable Handbrake's decomb filter, or whatever High Profile enables.
I'd be tempted to disagree with Handbrake's output having flaws, at least if all it's doing is straight encoding.
When I compared MeGUI and Handbrake, the output file size and bitrate were almost identical (1kbps difference according to MediaInfo) and that was probably more to do with the different versions of x264 than using different GUIs. If you're using filtering though, it may be a different story.Last edited by hello_hello; 15th Aug 2013 at 20:18.
-
Did I mention I'm also using the 32 bit versions of both programs??
Okay.... now I know why I'm using version 2.6.1.
Being adverse to installing stuff, especially when it comes to programs which share tools and I don't quite know what the installer will do (and not being keen to make a mess of my PC for the sake of this thread), I always go for portable versions where I can. For whatever reason, the link to the download for the installer on this site is version 2.6.4, while the link for the portable 32 bit version is 2.6.1. I hadn't noticed originally.
I'm not having any luck finding a 32 portable version later than 2.6.1. Maybe it is the latest 32 bit portable version. -
Yes the audio was different in AVIDEMUX's favor. Both AAC, but 128kbps for Avidemux thus smaller file - but in turn Handbrake's file was still smaller.
What is the point of a portable version?
How can an older Avidemux have a better x264 version?
I am not using any filters. I am following your exact settings.
Give me your exact settings again if you don't believe me.
The file I am using is raw footage in .AVI. -
It's not so much the size of the audio but whether it's re-encoded and even if it uses the same encoder etc. Better to eliminate it when trying to test video encoding speed.Originally Posted by DUDERANCH
Handbrake producing a different file size and bitrate could mainly be due to it using variable frame rate encoding.
No need to install it. Just upzip it to a folder and go. Delete the folder to remove it.Originally Posted by DUDERANCH
I've no idea.Originally Posted by DUDERANCH
I even checked the "build info" text file included with the portable version and it confirms x264 r2230
I believe you, but you still need to make sure everything is equal (no audio, constant frame rate etc).Originally Posted by DUDERANCH
I'd also try another source file of a different type anyway (CFR) to help make sure there's no bottleneck on the decoding side.
Not that there's likely to be, but you never know. -
So far all this thread has proven is that Handbrake uses different and / or less rigorous settings which makes it encode faster.
A minute or two difference with comparable versions is not enough to proclaim Avidemux as "bad".
Just for fun I did a short encode myself of a 12 minute clip.
I used the latest nightly builds of both programs on an AMD 8350 processor.
Both Avidemux and Handbrake at the same settings, took 2:21 and 2:20 respectively.
Both produced files of roughly the same size.Last edited by blud7; 15th Aug 2013 at 23:24.
-
Seek immediate medical help if you experience an erection(while bashing FREE, USEFUL SOFTWARE) lasting more than 4 hours.Originally Posted by DUDERANCH
-
Sorry bud but if it takes 20+ minutes to render on an i7 and less than 3 on Handbrake that is a screw up on Avidemux's part.Originally Posted by hech54
Seek immediate medical help if you experience an erection(while bashing FREE, USEFUL SOFTWARE) lasting more than 4 hours.Originally Posted by DUDERANCH
From what I learned in the last few posts Avidemux is not even using the latest x264 so the Mountain Lion version of Avidemux is awful. -
You got your a§§ handed to you here:Originally Posted by DUDERANCH
https://forum.videohelp.com/threads/357985-Why-is-Avidemux-so-bad?p=2260394&viewfull=1#post2260394
...and you are still bashing FREE SOFTWARE that you could not design, build, create of even improve by yourself
if someone had a gun to your head.
You got your a§§ handed to you on the speed issue(at the same time you were caught LYING that you had the same exact settings as HandBrake) and now you are still digging to TRY to save face.
You are pathetic. -
lol... I am not going to argue with you. You are being a little child name calling.Originally Posted by hech54
You got your a§§ handed to you here:Originally Posted by DUDERANCH
https://forum.videohelp.com/threads/357985-Why-is-Avidemux-so-bad?p=2260394&viewfull=1#post2260394
...and you are still bashing FREE SOFTWARE that you could not design, build, create of even improve by yourself
if someone had a gun to your head.
You got your a§§ handed to you on the speed issue(at the same time you were caught LYING that you had the same exact settings as HandBrake) and now you are still digging to TRY to save face.
You are pathetic.
If you actually read anything in the last few posts, the guys explained to me that Avidemux is using an old version of x264 which can make it encode slower. Didn't I just say this in the last post too? Guess you missed that.
I rendered the last tests on a 3570k on Windows 7 and Handbrake still won. Avidemux was faster, but still a bigger file size and encoded slower.
I rendered with an i7 3770 on OS X Mountain Lion and Avidemux took 20+ minutes. There is no absolutely no excuse from that. I used the latest version from the website and the latest version of Handbrake. An i7 will always beat an i5. So the Avidemux version of Mountain Lion, albeit being new, is using an ancient version of x264 if it takes that long.
So these guys need to send me the exact versions they are using so I can see if I can get the same results. -
@OP
I will not join in with the name-calling but if you can not see that two different programs create files of significantly different sizes irrespective of the encoding times if ALL settings are the same then we are ALL wasting our time in this topic. -
I don't understand. If they're using the same encoder with the same settings, and the same video is being fed to the encoder, why should the file sizes be significantly different?Originally Posted by DB83
When I ran my test encodes of a 4 minute video, encoding times for each program were a few seconds apart (although I didn't time them exactly), but the resulting file sizes were virtually identical. According to MediaInfo the Avidemux and Handbrake encodes resulted in exactly the same average bitrate. The average bitrate for MeGUI's encode was only 3Kb/s higher. That could be due to the fact each program uses a different version of the x264 encoder, and the slight differences in encoding time/bitrate may even be due to slight differences on the decoding side. -
But that is not true.Originally Posted by DB83
https://forum.videohelp.com/threads/357985-Why-is-Avidemux-so-bad?p=2260394&viewfull=1#post2260394 -
@hech54
Methinks you misunderstand what I am saying (or trying to say). It has been proved that if the settings are the same then the file size will be almost if not the same. The OP has produced significant variations in file-sizes. I appreciate that his original claim concerned encoding times but even if there was a variance there then you should still get the same file size. All I can see from his is "I used the default settings for both". That is akin to comparing chalk with cheeae. -
Copied the same Avidemux settings again.
Set Handbrake to Constant Framerate and no Decomb filter. Also removed audio.
Tried to 'copy' audio in Avidemux and it said...
Unsupported
Only AAC & mpegaudio supported for audio
Muxer
Cannot Open
Failed
Was NOT saved correctly.
Never had this problem before choosing copy audio. Maybe the new version broke it...
So I just saved as AAC 128kbps again.
Handbrake - 6:09
Avidemux - 7:48
-
Looking at your previous screenshots I seem to have got it the wrong way around.Originally Posted by DUDERANCH
Avidemux produced the VFR output while Handbrake gave you CFR.
Odd, but it appears that's also what happened this time.
Why are you so determined to keep using the same source file?Originally Posted by DUDERANCH
Why not use something more standard with CFR video for testing?
Something you can remux first without the audio so the programs are only opening a source file containing video.
Handbrake's output didn't include the audio, Avidemux re-encoded it which I assume required CPU time,Originally Posted by DUDERANCH
the output frame rates are different and you're still using the two outputs to compare video encoding times and bitrates?
I don't get it.
Plus it'd still be nice to see a MediaInfo screenshot which shows all the x264 settings used.
Try MediaInfo's HTML view instead of Text view so the x264 settings don't extend off the page.Last edited by hello_hello; 16th Aug 2013 at 16:59.
-
Ok can you give me a source file then? I don't want to use my own if you guys think the results are in favor of Handbrake because of my recorded video clip.
I thought the text view would be easier to read. I will use html for you next time. -
-
1. Still different versions of x264
2. qpmin / qpmax different
3. Handbrake has nal_hrd explicitly disabled
4. Keyint is different
5. Handbrake is showing lower bits/pixel which would indicate lower quality (but not necessarily)
1 & 2 are the most important here. Especially 2. -
I copied the exact settings from hello_hello's post. So then there are some settings he didn't tell me...
He needs to send me his version of Avidemux. I have a newer version of Avidemux, but he has a better x264 version? It doesn't make sense.
Handbrake looks better quality to me. Avidemux is too dark. -
By different versions I don't mean different from what he has, I mean it's clear that the programs are using different versions of x264.Originally Posted by DUDERANCH
hello_hello has done great so far but x264 has many settings. It is easy to miss one.
I don't see how one output could be darker than the other unless you used a filter. Anyway, I did my own encode, copied audio.
I then remuxed both with mkvmerge to make sure of exact filesizes (muxing can alter file size as well)
avidemux 1:18:00
handbrake 1:23:07
Handbrake took about 5s longer to produce a marginally smaller file. (Before remuxing, file sizes were the same both 56.8 MB)
Look at the bit rates, they are near identical. (1856 vs 1852)
With bitrates that close, this can be attributed to some tiny variation, probably x264 version.
Both encodes look identical to me, none is darker or blurrier or anything.Last edited by blud7; 21st Aug 2013 at 20:06.
-
There's still variables not caused by encoder settings such as the variable frame rate output verses a constant frame rate.
To be honest I don't think the differences in encoder settings would effect the result too much, but I simply went to the
Avidemux page on this site, downloaded the portable 32 bit version, unzipped it to a folder and ran it.
If you want to use the same version of Avidemux as I did, that's the one.
Don't you have a standard Xvid/Avi you could use for re-encoding tests? Something which will have a constant frame rate to begin with?
The fact you're saying the encodes produced by each program have differences in terms of brightness/colour is also a problem,
at least when it comes to output file size. One of the goals of lossy encoders such as x264 is to hide the compression from you
as much as possible, so some areas of video (ie darker areas) may be compressed more, fast moving scenes might be compressed
differently as it's much harder to see any compression artefacts, even the x264 encoder itself is frame rate aware.....
you can take a video and encode it at 24fps, then encode it again while doing nothing but speeding it up to 25fps (same total
number of frames) and the output file size will be slightly different every time even if you're using the same x264 version and the same settings.
I can't remember if you are, but if you're converting captures from games, then the chances are the video needs to be converted to YUV for encoding.
If it's RGB it will, and the way it's converted can effect how it looks even before it's compressed, which in turn can effect how it's compressed.
It mightn't make much difference to encoding speed but it'd be likely to effect the bitrate/file size. If the input is RGB then you need to ensure
it's converted to YUV the same way each time, but to be honest that whole story is a complete topic of it's own.
When you re-encode "normal" video, it's already YUV so there's usually non of those issues. The existing video is decompressed,
it's fed to the encoder which re-compresses it, and the input and output should look the same (there's even colour issues to be aware of
when resizing HD video to SD and re-encoding it, but that's another topic again).
.Last edited by hello_hello; 21st Aug 2013 at 20:26.
-
Thinking about it, if you've got no other choice, take one of the encodes above (the one with the constant frame rate) and re-encode it with each
program instead of using the original video again. That should help level the playing field when it comes to frame rates, and my guess will be the
output from each program will then look the same in respect to brightness/colour.
And before you do, open it with MKVMergeGUI, deselect any audio streams within, and remux it as a new MKV containing only video.
That should remove any audio from the equation and you can use the new MKV containing only video as the source for re-encoding. -
I found Handbrake to be marginally slower too, or to a least take a little longer, but I put it downOriginally Posted by blud7
(possibly incorrectly) to "preparation". Every encoder GUI does things slightly differently and it seemed
to me Handbrake might take a few seconds longer to actually start encoding, hence the extra few seconds
of total "encoding time".
MeGUI seemed to be the fastest, but using it generally involves way more time "preparing" an encode
than the other programs before you get to start the encoding process. -
Why do I need to remove audio if they use the same audio settings? AAC (FAAC) 160kbps.
The footage is game play from Starcraft 2 record with Fraps. It is a uncompressed .avi. No quality loss and exact audio copy.
Quote
Similar Threads
-
Avidemux
By BaPW in forum EditingReplies: 7Last Post: 24th Jan 2012, 23:22 -
Avidemux aspect ratio question [from newbie to Avidemux]
By ANOther1676 in forum EditingReplies: 1Last Post: 20th Jan 2012, 20:07 -
I need help using AviDemux
By hardy in forum Newbie / General discussionsReplies: 4Last Post: 19th Jul 2010, 09:11 -
No Audio In Encore/Bad Aspect Ratio/Bad Files/Bad ISO/Bad Everything
By koberulz in forum Newbie / General discussionsReplies: 35Last Post: 24th Jan 2010, 04:48 -
Avidemux 2.5.2
By shivz@013.net in forum EditingReplies: 2Last Post: 16th Jan 2010, 08:40