![]() ![]() There is no absolutely no excuse from that. I rendered with an i7 3770 on OS X Mountain Lion and Avidemux took 20+ minutes. Avidemux was faster, but still a bigger file size and encoded slower. I rendered the last tests on a 3570k on Windows 7 and Handbrake still won. Didn't I just say this in the last post too? Guess you missed that. 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. You are being a little child name calling. 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. and you are still bashing FREE SOFTWARE that you could not design, build, create of even improve by yourself 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.įrom 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. If you're using filtering though, it may be a different story. 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. ![]() ![]() I'd be tempted to disagree with Handbrake's output having flaws, at least if all it's doing is straight encoding. ![]() And I did disable Handbrake's decomb filter, or whatever High Profile enables. In my case I used a standard Xvid/AVI which I knew was progressive and wouldn't need any filtering. 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? 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). "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.īecause I use a GUI which doesn't enable stuff like that until you specifically tell it to, I kind of forget other GUIs do.Īnd the third "my bad' would be forgetting that by default High Profile includes the audio, and converts it, or something. Speaking of which, what is your source video? Do you have any filters enabled? 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. It may be Avidemux doesn't understand VFR and just assumes it's CFR. 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. 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. When I said use High Profile as it uses the x264 default settings, I was referring to x264 settings only. I'm not a Handbrake user myself, so the whole variable frame rate thing didn't occur to me. He said to use High Profile and I used all default settings - Variable Frame Rate being one of them. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |