View Full Version : Avidemux (with emphasis on x264/h264 GUI)
LoRd_MuldeR
11th July 2011, 16:10
libx264 SVN-r2019:
libx264-r2019, MinGW GCC 4.5.3, optimized for Core 2 (http://www.mediafire.com/file/rvdwfl68svt377m/libx264-116-r2019M-gcc453-core2-fprofiled.7z)
libx264-r2019, MinGW GCC 4.5.3, optimized for K10 (http://www.mediafire.com/file/e6m2mx8l31m961d/libx264-116-r2019M-gcc453-amdfam10-fprofiled.7z)
libx264-r2019, MinGW GCC 4.5.3, optimized for Pentium III (http://www.mediafire.com/file/sogdxraycnx9s0b/libx264-116-r2019M-gcc453-pentium3-fprofiled.7z)
libx264-r2019, MinGW GCC 4.5.3, generic build (http://www.mediafire.com/file/t3sonau0nt61fqx/libx264-116-r2019M-gcc453-i686-fprofiled.7z)
libx264-r2019, MinGW GCC 4.5.3, without ASM (slow!) (http://www.mediafire.com/file/ztppq3d04g8ny4u/libx264-116-r2019M-gcc453-noasm-fprofiled.7z)
(Click here for the complete list) (http://www.mediafire.com/?qb41e246epm7u)
libx264 SVN-r2019 library pack:
libx264 SVN-r2019 complete "all-in-one" library pack (mirror #1) (http://code.google.com/p/mulder/downloads/detail?name=libx264-116-r2019M-win32.7z&can=2&q=)
libx264 SVN-r2019 complete "all-in-one" library pack (mirror #2) (http://www.mediafire.com/file/djzvax8yr8a3a5z/libx264-116-r2019M-win32.7z)
These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r7317 (http://forum.doom9.org/showpost.php?p=1512732&postcount=1650) or later now!
Romario
24th July 2011, 04:03
Dear LoRd_MuldeR, please update libx264 with build 2037. :)
LoRd_MuldeR
24th July 2011, 16:52
Dear LoRd_MuldeR, please update libx264 with build 2037. :)
We'll need to wait for Avidemux to be updated for Sub-ME 11 support...
Romario
26th July 2011, 19:33
Ohh, ok ok, I understand. But I don't understand, what Sub-ME 11 brings to us ? Quality improvments or speed ?
LoRd_MuldeR
26th July 2011, 20:17
Ohh, ok ok, I understand. But I don't understand, what Sub-ME 11 brings to us ? Quality improvments or speed ?
Sube-ME 11 is even slower than Sub-ME 10 - not really surprising - and gives a minor compression improvement.
(AFAIU this is mainly a preparation for a future trellis mode decision/motion estimation patch)
Romario
29th July 2011, 00:47
Well, they can only develop Partition Search 2x2 and 1x1 intra prediction Blocks. :p
I am joking,but who knows what future will bring to us. :)
LoRd_MuldeR
10th August 2011, 20:54
Avidemux 2.5.4 r7389 (2011-08-05)
http://www.avidemux.org/
Revision 7389 (05 Aug 2011)
Updated libogg to version 1.3.0.
Updated libvpx to version 0.9.7.
Updated x264 to r2044.
7389 - [ffmpeg] remove ffmpeg 0.8 build kludge
7388 - [ffmpeg] upgrade ffmpeg to 0.8.1
7387 - [mswin] update build scripts
7386 - [qt] fix appending video with drag and drop (regression introduced 7317)
7326 - [mkv/read] In case a mkv has a zero frequency, replace it by 48 khz. Ugly hack, just so that it does not crash, it is still incomplete.
7325 - [build] Update patch to lav* so that it compiles with 0.8
7324 - [cmake] we are now 2.5.5
Download Mirror #1: http://mulder.googlecode.com/ (http://code.google.com/p/mulder/downloads/detail?name=Avidemux.2011-08-05.Win32.exe&can=2&q=)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)
LoRd_MuldeR
11th August 2011, 00:27
libx264 SVN-r2057:
libx264-r2057, MinGW GCC 4.5.3, optimized for Core 2 (http://www.mediafire.com/file/0k5sh52cnywph9c/libx264-116-r2057M-gcc453-core2-fprofiled.7z)
libx264-r2057, MinGW GCC 4.5.3, optimized for K10 (http://www.mediafire.com/file/iunoiskqsut5us5/libx264-116-r2057M-gcc453-amdfam10-fprofiled.7z)
libx264-r2057, MinGW GCC 4.5.3, optimized for Pentium III (http://www.mediafire.com/file/xr3afzp90y71lzq/libx264-116-r2057M-gcc453-pentium3-fprofiled.7z)
libx264-r2057, MinGW GCC 4.5.3, generic build (http://www.mediafire.com/file/c7z1j2cjrfhjr55/libx264-116-r2057M-gcc453-i686-fprofiled.7z)
libx264-r2057, MinGW GCC 4.5.3, without ASM (slow!) (http://www.mediafire.com/file/5nz3aukke8ip1xr/libx264-116-r2057M-gcc453-noasm-fprofiled.7z)
(Click here for the complete list) (http://www.mediafire.com/?w0w7b90a4i0j8)
libx264 SVN-r2057 library pack:
libx264 SVN-r2057 complete "all-in-one" library pack (mirror #1) (http://code.google.com/p/mulder/downloads/detail?name=libx264-116-r2057M-win32.7z&can=2&q=)
libx264 SVN-r2057 complete "all-in-one" library pack (mirror #2) (http://www.mediafire.com/file/wqb9357w8ad72rf/libx264-116-r2057M-win32.7z)
These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r7389 (http://forum.doom9.org/showthread.php?p=1518791#post1518791) or later now!
Cornelis
18th August 2011, 20:17
Ahhh!
THERE it is. I always looked for the word "deblock". :)
Woohoo! And after deactivating the additional deblocking in the postprocessing tab
the output finally looks like the input. :)
Thank you!
At Last!!!!
I was wondering why my videos looked so blurry and then I found out that deblocking is activated by default on my Avidemux 2.5 r2700 release.I'm glad that I stumbled unto your post otherwise I never would've known how to fix the problem.
:thanks:
LoRd_MuldeR
18th August 2011, 20:27
It is highly recommended to not turn off the In-Loop Deblocking feature of x264. It's turned on by default for a good reason, not only in Avidemux ;)
You may want to lower the Deblocking values to something like -1:-1 (as in x264' "Film" tuning) or even -2:-2 though.
Also be aware that there is a "Post-processing" filter with Deblocking/Deringing in Avidemux, which is not related to x264 at all and which you should turn off - except for poor quality sources!
The In-Loop Deblocking feature of x264 prevents new blocks caused by the H.264 encoding. The "Post-processing" filter tries to smooth out existing blocks in the source/input...
Cornelis
18th August 2011, 20:58
It is highly recommended to not turn off the In-Loop Deblocking feature of x264. It's turned on by default for a good reason, not only in Avidemux ;)
You may want to lower the Deblocking values to something like -1:-1 (as in x264' "Film" tuning) or even -2:-2 though.
Also be aware that there is a "Post-processing" filter with Deblocking/Deringing in Avidemux, which is not related to x264 at all and which you should turn off - except for poor quality sources!
The In-Loop Deblocking feature of x264 prevents new blocks caused by the H.264 encoding. The "Post-processing" filter tries to smooth out existing blocks in the source/input...
Sorry LoRd_MuldeR, I need to explain myself more clearly:
I'm referring to the "Post-processing" filter with Deblocking/Deringing which is activated by default on my Aviemux 2.5 r2700 release which means that I was encoding my dvd's without knowing that the filter is on by default with the result not being up to standard. I am deactivating this filter manually every time I start Avidemux and the quality of my videos are up to standard again.
Thank you for all your hard work in maintaining this brilliant piece of software
LoRd_MuldeR
18th August 2011, 21:00
BTW: You can change the default setting for the "Post-Processing" filter in the Avidemux preferences.
Cornelis
18th August 2011, 21:02
Thanks I will do it!
LoRd_MuldeR
5th September 2011, 15:36
libx264 SVN-r2074:
libx264-r2074, MinGW GCC 4.5.3, optimized for Core 2 (http://www.mediafire.com/file/f594rom6b09d16a/libx264-116-r2074M-gcc453-core2-fprofiled.7z)
libx264-r2074, MinGW GCC 4.5.3, optimized for K10 (http://www.mediafire.com/file/u0k4cd8hcj5cnws/libx264-116-r2074M-gcc453-amdfam10-fprofiled.7z)
libx264-r2074, MinGW GCC 4.5.3, optimized for Pentium III (http://www.mediafire.com/file/7ko9206v46a2b87/libx264-116-r2074M-gcc453-pentium3-fprofiled.7z)
libx264-r2074, MinGW GCC 4.5.3, generic build (http://www.mediafire.com/file/j2jh7y3byw1hgm1/libx264-116-r2074M-gcc453-i686-fprofiled.7z)
libx264-r2074, MinGW GCC 4.5.3, without ASM (slow!) (http://www.mediafire.com/file/g2wmle2kap7v979/libx264-116-r2074M-gcc453-noasm-fprofiled.7z)
(Click here for the complete list) (http://www.mediafire.com/?aahlxg5iatn25)
libx264 SVN-r2074 library pack:
libx264 SVN-r2074 complete "all-in-one" library pack (mirror #1) (http://code.google.com/p/mulder/downloads/detail?name=libx264-116-r2074M-win32.7z&can=2&q=)
libx264 SVN-r2074 complete "all-in-one" library pack (mirror #2) (http://www.mediafire.com/file/j23st7kjjrkcusq/libx264-116-r2074M-win32.7z)
These builds will NOT work with Avidemux 2.5.4 or older. Please update to Avidemux 2.5.5 r7428 (http://code.google.com/p/mulder/downloads/list?can=2&q=Avidemux&sort=-uploaded&colspec=Filename%20Summary%20Type%20Uploaded%20Size%20DownloadCount) or later now!
cord-factor
11th September 2011, 11:53
Why avidemux uses only one core during playback of HDV (MPEG2/MPEG-TS) files?
So what's the library used for this (libmpeg2?)? Can it be changed to lavc for Multi-threading usage?
Thanx
LoRd_MuldeR
11th September 2011, 11:59
It uses libavcodec. And multi-threading for libavcodec can be configured in the Avidemux preferences.
However not all decoders in libavcodec are multi-threaded. The setting only applies to those that are.
LoRd_MuldeR
15th September 2011, 12:04
Avidemux 2.5.5 r7515 (2011-09-12)
http://www.avidemux.org/
Revision 7515 (12 Sep 2011)
# Updated Qt to version 4.7.4.
# Updated x264 to r2074.
# Updated libvpx to version 0.9.7-p1.
# Updated NSPR to version 4.8.9.
7515 - [ffmpeg] upgrade ffmpeg to 0.8.3
7502 - [js] update width test
7501 - [js] update framecount test
7500 - [js] update fcc test
7499 - [js] update testfps
7428 - [ffmpeg] upgrade ffmpeg to 0.8.2
Download Mirror #1: http://mulder.googlecode.com/ (http://code.google.com/p/mulder/downloads/detail?name=Avidemux.2011-09-12.Win32.exe&can=2&q=)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)
flapane
18th September 2011, 09:41
I've compressed some videos using MPEG4-AVC and I saved them with .mp4 extension.
However I forgot to select "MP4" in "Format" option, and left "AVI".
The videos play well in VLC, but I get black screen in MPC-HC and I can't see the thumbnail previews in Explorer.
Any way to fix it without recompressing them?
Thanks
wonkey_monkey
18th September 2011, 11:58
Drag the .mp4 back into AviDemux (you might have to remain it to .avi), leave Video and Audio on Copy, select an MKV container and save, and it should repack the streams without re-encoding.
David
flapane
18th September 2011, 12:03
I get an "error while coding" pop-up (r7296 version, the same happens with the latest version posted above)
LoRd_MuldeR
18th September 2011, 13:00
I've compressed some videos using MPEG4-AVC and I saved them with .mp4 extension.
However I forgot to select "MP4" in "Format" option, and left "AVI".
The videos play well in VLC, but I get black screen in MPC-HC and I can't see the thumbnail previews in Explorer.
Any way to fix it without recompressing them?
Thanks
Then you got an AVI file containing MPEG-4 AVC video, only with a "wrong" .mp4 extension ;)
Actually MPC-HC should play MPEG-4 AVC in AVI just fine, but the .mp4 extension may confuse DirectShow to select the wrong splitter.
So, first of all, rename your file to the "correct" .avi extension. If not done already, you must configure Windows Explorer to not hide the file extension!
In the next step, you can re-mux your AVI file to MP4 or to MKV with the help of MP4Box/YAMB or MKVToolnix/AVIMuxGUI...
(You will probably have to extract the "raw" streams from the AVI file first, then re-mux them into MP4 or MKV with the suitable muxing tool)
flapane
18th September 2011, 17:11
Your algorithm sounds great. Thank you as usual. ;)
LoRd_MuldeR
25th September 2011, 21:49
Avidemux 2.5.5 r7573 (2011-09-22)
http://www.avidemux.org/
Revision 7573 (22 Sep 2011)
# Updated x264 to r2085.
7573 - [ffmpeg] upgrade ffmpeg to 0.8.4
7567 - [i18n] Greek translation part2
7561 - [i18n] It translation update by zoppo
7547 - [i18n] German translation (patch by darkshadow)
7546 - [gtk] Job dialog window size (patch by darkshadow)
7545 - [gtk] Encoding window auto sized (patch by darkshadow)
7544 - [i18n] Green translation update by nikos_02
Download Mirror #1: http://mulder.googlecode.com/ (http://code.google.com/p/mulder/downloads/detail?name=Avidemux.2011-09-22.Win32.exe&can=2&q=)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)
LoRd_MuldeR
25th September 2011, 21:53
libx264 SVN-r2085:
libx264-r2085, MinGW GCC 4.5.3, optimized for Core 2 (http://www.mediafire.com/file/dyk8ecsz1cvp056/libx264-118-r2085M-gcc453-core2-fprofiled.7z)
libx264-r2085, MinGW GCC 4.5.3, optimized for K10 (http://www.mediafire.com/file/yc3uj4d3lxalpv9/libx264-118-r2085M-gcc453-amdfam10-fprofiled.7z)
libx264-r2085, MinGW GCC 4.5.3, optimized for Pentium III (http://www.mediafire.com/file/4qr9np76f86fj1n/libx264-118-r2085M-gcc453-pentium3-fprofiled.7z)
libx264-r2085, MinGW GCC 4.5.3, generic build (http://www.mediafire.com/file/0z9grdk8507jz86/libx264-118-r2085M-gcc453-i686-fprofiled.7z)
libx264-r2085, MinGW GCC 4.5.3, without ASM (slow!) (http://www.mediafire.com/file/ggnj8vkhvpr1x1r/libx264-118-r2085M-gcc453-noasm-fprofiled.7z)
(Click here for the complete list) (http://www.mediafire.com/?avv0q91mkqjja)
libx264 SVN-r2085 library pack:
libx264 SVN-r2085 complete "all-in-one" library pack (mirror #1) (http://code.google.com/p/mulder/downloads/detail?name=libx264-118-r2085M-win32.7z&can=2&q=)
libx264 SVN-r2085 complete "all-in-one" library pack (mirror #2) (http://www.mediafire.com/file/0xl8bqqyrhrxmit/libx264-118-r2085M-win32.7z)
These builds will NOT work with Avidemux 2.5.4 or older. Please update to Avidemux 2.5.5 r7573 (http://code.google.com/p/mulder/downloads/detail?name=Avidemux.2011-09-22.Win32.exe&can=2&q=) or later now!
Darkwhisperer
29th September 2011, 15:31
Im trying to use avidemux (command-line) to convert to MKV (x264 & AAC).
I've seen the tutorials where you use the scripting functionality to specify your settings, but I would prefer to use the command-line purely. Is there a way to pass app.video.codec values in the command-line? Especially the codec settings?
Also, how does the --codec-conf command work? It takes a configuration file, but what needs to be in that file, and in what format? I tried looking for an example, but no luck.
Thanks!
LoRd_MuldeR
29th September 2011, 16:06
Please refer to the Avidemux Wiki:
* http://avidemux.org/admWiki/doku.php?id=using:command_line_usage
* http://avidemux.org/admWiki/doku.php?id=using:scripting
* http://avidemux.org/admWiki/doku.php?id=tutorial:scripting_tutorial
* http://avidemux.org/admWiki/doku.php?id=using:avsproxy
And I think some operations can only be done by script. But you can call (and even create!) the script by command-line.
XMEN3
6th October 2011, 14:48
Stright copy A/V from vob, mp2/ac3 audio with negative delay is muxed with positive delay in the output mpeg-ps.
Mediainfo and dgindex report -144.
Compared with audition the outputed mp2 is 144ms longer than the input.
So new frames are written?
The track sould be cutted of -144ms or I'm wrong?
Also in the audio/main_track is reported s/144 shift.
thanks
cord-factor
13th October 2011, 10:16
Stright copy A/V from vob, mp2/ac3 audio with negative delay is muxed with positive delay in the output mpeg-ps.
Mediainfo and dgindex report -144.
Compared with audition the outputed mp2 is 144ms longer than the input.
So new frames are written?
The track sould be cutted of -144ms or I'm wrong?
Also in the audio/main_track is reported s/144 shift.
thanks
See faq,
Why do my MPEG-2 files get out of sync when I cut/edit them in Avidemux?
Captured MPEG files are generally from DVB S/T (in MPEG TS format) or from IVTV based cards or any other card with hardware MPEG-2 encoding (in MPEG PS format). These captures often contain transmission errors which end up as missing or broken frames! A video player (MPC, MPlayer, xine, VLC, etc.) will constantly re-sync the streams using the timing information embedded in the stream. Avidemux will not! Apart from the constant shift, which is easily recoverable using the timeshift filter, it will result in a growing synchronisation issue when encoding or transcoding. Even saving without re-encoding will be async! MythTV recordings are a prime example of this problem: The audio will be offset by approximately -330 ms at the start of the recording and the drift throughout the duration of the recording. Please note that not all MythTV recordings have this problem, just some depending on the software and hardware configuration. The only 100% reliable way to fix your MPEG-2 files is to use ProjectX. You can get ProjectX from http://project-x.sourceforge.net/, a tutorial can be found at http://www.avidemux.org/admWiki/index.php?title=Project_X
XMEN3
13th October 2011, 14:04
See faq,
Why do my MPEG-2 files get out of sync when I cut/edit them in Avidemux?
Captured MPEG files are generally from DVB S/T (in MPEG TS format) or from IVTV based cards or any other card with hardware MPEG-2 encoding (in MPEG PS format). These captures often contain transmission errors which end up as missing or broken frames! A video player (MPC, MPlayer, xine, VLC, etc.) will constantly re-sync the streams using the timing information embedded in the stream. Avidemux will not! Apart from the constant shift, which is easily recoverable using the timeshift filter, it will result in a growing synchronisation issue when encoding or transcoding. Even saving without re-encoding will be async! MythTV recordings are a prime example of this problem: The audio will be offset by approximately -330 ms at the start of the recording and the drift throughout the duration of the recording. Please note that not all MythTV recordings have this problem, just some depending on the software and hardware configuration. The only 100% reliable way to fix your MPEG-2 files is to use ProjectX. You can get ProjectX from http://project-x.sourceforge.net/, a tutorial can be found at http://www.avidemux.org/admWiki/index.php?title=Project_X
sure i know that problem on transport stream with package lost in DVB...
but im talking about vob files from dvd and without any package lost...
if u read i'm talking about the detected delay that is detected properly as value but not as symbol...
ex...
the audio stream has -200ms of delay that mediainfo and dgindex recognise properly.
Avidemux detect this delay right as 200 but positive and add 200ms to the track istead of removing.
The problem is the initial delay detected wrongly, not the out of sync in later position.
To avoid this i need to fill manually a shift value twice (-400ms for the last example).
LoRd_MuldeR
1st November 2011, 16:05
libx264 SVN-r2106:
libx264-r2106, MinGW GCC 4.5.3, optimized for Core 2 (http://www.mediafire.com/file/h12i89zc2kfpsho/libx264-118-r2106M-gcc453-core2-fprofiled.7z)
libx264-r2106, MinGW GCC 4.5.3, optimized for K10 (http://www.mediafire.com/file/a0qvzqznsrkkupu/libx264-118-r2106M-gcc453-amdfam10-fprofiled.7z)
libx264-r2106, MinGW GCC 4.5.3, optimized for Pentium III (http://www.mediafire.com/file/pdxn0w1om3ml6a5/libx264-118-r2106M-gcc453-pentium3-fprofiled.7z)
libx264-r2106, MinGW GCC 4.5.3, generic build (http://www.mediafire.com/file/f6slqbl8sqsc2w1/libx264-118-r2106M-gcc453-i686-fprofiled.7z)
libx264-r2106, MinGW GCC 4.5.3, without ASM (slow!) (http://www.mediafire.com/file/8497s4i6gimg6yc/libx264-118-r2106M-gcc453-noasm-fprofiled.7z)
(Click here for the complete list) (http://www.mediafire.com/?4dmfsqq3dy8yb)
libx264 SVN-r2106 library pack:
libx264 SVN-r2106 complete "all-in-one" library pack (mirror #1) (http://code.google.com/p/mulder/downloads/detail?name=libx264-118-r2106M-win32.7z&can=2&q=)
libx264 SVN-r2106 complete "all-in-one" library pack (mirror #2) (http://www.mediafire.com/file/gu8i1hrnu9yikhe/libx264-118-r2106M-win32.7z)
These builds will NOT work with Avidemux 2.5.4 or older. Please update to Avidemux 2.5.5 r7573 (http://code.google.com/p/mulder/downloads/detail?name=Avidemux.2011-09-22.Win32.exe&can=2&q=) or later now!
flapane
3rd November 2011, 15:18
Any way to do a 7/8hours x264 1st pass encoding, and than do the 2nd pass encoding the next day?
LoRd_MuldeR
3rd November 2011, 15:21
Any way to do a 7/8hours x264 1st pass encoding, and than do the 2nd pass encoding the next day?
Sure. Hiberanation :)
You can also abort the second pass. In that case Avidemux will keep the stats file from the first pass. If you then start antother 2-Pass encode and save to the exatcly same output file, Avidemux will suggest skipping the first pas and re-using the existing stats file. I'd recommend to test this, before doing an 8 hours encode though...
flapane
3rd November 2011, 15:23
Thanks, I'll do a couple of short tests using the stats file created after the 1st pass. :)
Pulstar
4th November 2011, 04:47
Hello LoRd_MuldeR, why can't I get better CPU utilisation from Avidemux x64 for x264 encodes? I'm barely getting +50% on a Core i3.. should I change affinity settings? Btw using r7200
LoRd_MuldeR
4th November 2011, 10:16
Probably bottlenecked by slow input or slow filters...
Pulstar
5th November 2011, 02:04
Still not having much luck even with SD sources.. maybe certain x264 "look-ahead" settings affect this? Oh and is there a reason why we can't get AAC LC with SBR is it a licensing issues?
LoRd_MuldeR
5th November 2011, 12:15
Still not having much luck even with SD sources.. maybe certain x264 "look-ahead" settings affect this?
Maybe you are using encoder settings that simply are too "fast".
Usually the "parallel" parts of x264 (i.e. calculations that can be distributed on multiple threads) will dominate, which allows for efficient multi-threading.
If, however, you're using very fast settings, the "sequential" parts (i.e. calculations which can not be parallelized at all) can become more influential - and thus bottleneck the rest!
Also be aware that the first pass of a 2-Pass encode always uses very fast settings! So wait for the second pass, before you rate the CPU utilization...
Oh and is there a reason why we can't get AAC LC with SBR is it a licensing issues?
It's due to the lack of a "decent" OpenSource AAC encoder. FAAC, the (as far as I know) only OpenSource AAC encoder, is not "state of the art" anymore and it doesn't support HE-AAC (AAC+SBR).
There are "freeware" alternatives, such as the Nero AAC encoder or the FGH AAC encoder.
But they either are not available as a library (which is required for Avidemux), not available on all platforms (also required for Avidemux) or don't allow redistribution (makes things complicated).
Pulstar
5th November 2011, 16:30
Thanks for the clarification. :)
LoRd_MuldeR
7th November 2011, 14:32
Avidemux 2.5.5 r7643 (2011-09-22)
http://www.avidemux.org/
Updated LAME to version 3.99.
Updated x264 to r2106.
7643 - [cmake] stamp application with last svn commit revision rather than current revision
7642 - [mswin] misc changes to build scripts
7634 - [audioDevice/OSX] More patch by nibbles
7633 - [i18n] hu update by Laszlo Andrassy
7616 - [audioCoreDevice] Update to newer audioDevice api, patch by Nibbles
7615 - [audioCoreDevice] Patch by Nibbles
7614 - [audioCore] Re-add audioCore audio device, untested
7609 - [ffmpeg] upgrade ffmpeg to 0.8.5
7608 - [mswin] upgrade build scripts to support multilib compiler
7606 - [mswin] unix fix
7605 - [mswin] update Windows 7 taskbar with encoding progress
Download Mirror #1: http://mulder.googlecode.com/ (http://code.google.com/p/mulder/downloads/detail?name=Avidemux.2011-11-01.Win32.exe&can=2&q=)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)
Sparktank
8th November 2011, 02:21
Avidemux 2.5.5 r7643 (2011-09-22)
http://www.avidemux.org/
Download Mirror #1: http://mulder.googlecode.com/ (http://code.google.com/p/mulder/downloads/detail?name=Avidemux.2011-11-01.Win32.exe&can=2&q=)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)
False Positive Note: AVG got paranoid over this. I trust it's fine, it's just AVG >.>
Avira liked it though.
AVG reported the .dll's inside as infected with a Win32/Heur.
But that's mainly because, I believe, the .dll's are modified/created in a way that AVG doesn't normally like.
Malwarebyte's Anti-Malware liked it too.
Thanks for this :)
Will have to add it to exceptions list.
LoRd_MuldeR
8th November 2011, 10:00
False Positive Note: AVG got paranoid over this. I trust it's fine, it's just AVG >.>
Avira liked it though.
AVG reported the .dll's inside as infected with a Win32/Heur.
But that's mainly because, I believe, the .dll's are modified/created in a way that AVG doesn't normally like.
Malwarebyte's Anti-Malware liked it too.
Thanks for this :)
Will have to add it to exceptions list.
As always in this situation: Please report the FALSE POSITIVE to the developer of your Anti-Virus software, so they can fix the bug in their software!
Nobody else can do anything about the issue :rolleyes:
And, if you continue to get FALSE POSITIVES with your Anti-Virus software after having reported the issue, switch to a better product....
Pulstar
9th November 2011, 14:42
Hehe AV softies are so twitchy with their precious false positive
Btw I know you've been asked this but is OpenCL on the card and if so how much encoding performance gains can be expected? :)
LoRd_MuldeR
10th November 2011, 00:37
As far as I know, Avidemux already supports GPU decoding via VDPAU on the Linux platform (I primarily use Windows, so I didn't check out that feature yet). VDPAU, of course, works with NVidia cards only. And it doesn't actually use the GPU, but the graphic card's built-in "video decoding engine" (called "PureVideo HD" in NVidia jargon). GPU encoding is another topic: There are some (commercial) GPU encoders available and their developers always emphasize how fast they are. But the truth is: The quality of the available GPU-based encoding solutions isn't anywhere near the state-of-the-art CPU encoders (such as x264)! Also CPU encoders can be very fast too, if you tweak them for speed (rather than quality) - and then the speed advantage of the GPU encoders vanishes. So unless we finally see a useful GPU encoder (i.e. one that can keep up with the best CPU encoders quality-wise and still encodes faster), GPU-based encoding remains an advertising gimmick...
Pulstar
10th November 2011, 21:10
Thanks again for taking the time to clear the picture. GPU processing has been receiving a lot of hype recently.
LoRd_MuldeR
6th December 2011, 22:16
Avidemux 2.5.5 r7694 (2011-12-05)
http://www.avidemux.org/
Compiled with GCC 4.6.2.
Windows XP 32-bit stability issues should now be fixed.
Updated LAME to version 3.99.
Updated x264 to r2106.
7694 - [mswin] add library dependency to support r7605 properly
7693 - [mswin] update build scripts to make life a bit easier
7692 - [audioencoder] stack isn't aligned properly on x86 systems supporting SSE2 when -ftree-vectorize (i.e. -O3) is used.
7689 - [opengl] realign the runtime stack of paint function so it operates on 32-bit
7685 - [mswin] update build scripts to work with latest binutils
7684 - [mingw] remove ftello and fseeko constants since they've been defined in mingw-w64 for over 9 months now and cause conflict
7683 - [ffmpeg] upgrade ffmpeg to 0.8.7
7680 - [MacOsX] Fix compilation flag (fluxSmooth/ResampleFps) for MacOsX, patch by nobbles
7679 - [plugin] add 1 to the string size to make sure it does not overflow
7666 - [core] dont override memcpy on macOsX
7665 - [yadif] use cmpl instead of cmp, compatibility with MacOsX (patch by nibbles)
7664 - [ffmpeg] don't reference deprecated API
7663 - [audiocore] missing include, patch by nibbles
7662 - [ffmpeg] upgrade ffmpeg to 0.8.6
7661 - [coreImage] Fix building with clang compiler (macOsX). Patch by nibbles
7658 - [MacOsX] Asm fix by nibbles
7657 - [fieldUtil] Patch for clang by nibbles
7654 - [Mac] Fix BUNDLE, patch by nibbles
7653 - [DIA] Dont use tip=NULL, patch by nibbles, need for clang
7644 - [flv] Better compatibility with metadata (merge from 2.6)
Download Mirror #1: http://mulder.googlecode.com/ (http://code.google.com/p/mulder/downloads/detail?name=Avidemux.2011-12-05.Win32.exe&can=2&q=)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)
LoRd_MuldeR
7th December 2011, 00:19
libx264 SVN-r2119 library pack:
There was a regression in this revison of x264. Please update to the latest revision below!
Changelog:
commit 0637cd67cb245fce5ba190fa4b9c341319ea2b37 [revision 2119]
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Wed Nov 30 13:02:12 2011 -0800
Modify MBAFF chroma deblock functions to handle U/V at the same time
Allows for more convenient asm implementations.
commit 67f1fdc4d9c030568eac8cf9ab9d0bb249f520db [revision 2118]
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Thu Nov 10 16:16:13 2011 -0800
CABAC trellis optimizations: use SIMD quant
Significant speed increase, minor change in output due to rounding.
commit e047b3c475cd42b6647397a244e239ebfca53bf6 [revision 2117]
Author: Steven Walters <kemuri9@gmail.com>
Date: Sun Nov 6 09:48:30 2011 -0800
YUV range detection and support for x264CLI
Two new options: --input-range and --range.
--input-range forces the range of the input in case of misdetection; auto by default.
-- range sets the range of the output; x264cli will convert if necessary, TV by default.
--fullrange is now removed as a CLI option (but the libx264 API is unchanged).
commit 00df989cc06208050230756525633438d76b5a6a [revision 2116]
Author: Kieran Kunhya <kieran@kunhya.com>
Date: Fri Nov 4 20:09:13 2011 +0000
Pass through user data
commit 04a0aeefd2f5b152c5dbca4a1c6569bd27c9f721 [revision 2115]
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Thu Oct 27 14:05:56 2011 -0700
Remove unpredictable branch in CABAC dqp
commit 4185ee883b04d9cee57a64fdebd153830b7b27ba [revision 2114]
Author: Loren Merritt <pengvado@akuvian.org>
Date: Sun Oct 23 23:15:11 2011 +0000
x86inc: AVX symmetry optimization
3-arg AVX ops with a memory arg can only have it in src2,
whereas SSE emulation of 3-arg prefers to have it in src1 (i.e. the move).
So, if the op is symmetric and the wrong one is memory, swap them.
Eliminates redundant moves in some cases when using 3-operand without AVX with memory arguments.
Also fix movss and movsd in some cases, and flag shufps correctly as float.
commit cc129adcaaf5604f3d4fea9ebcb289403192a741 [revision 2113]
Author: Anton Mitrofanov <Bugmaster@narod.ru>
Date: Tue Nov 29 13:45:13 2011 -0800
checkasm: shut up gcc warnings, fix some naming of functions in results
commit f0ccc98bb747b8ee0fe9329f4205cf382788bb89 [revision 2112]
Author: Mans Rullgard <mans@mansr.com>
Date: Mon Nov 28 16:29:12 2011 -0800
checkasm: fix build on ARM
Because of how ALIGNED_ARRAY_16 is defined on ARM, array initialisers cannot be used here. Use memset() instead.
commit d8d8e756b1fee72b4771761d6aa4cfb31edc0b67 [revision 2111]
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Sat Nov 12 01:31:49 2011 +0400
Improve makefile rules
Remove the need for "make clean" after most reconfigures.
commit e6d33a931c08918e78dcae97e4d80d0c3411bf2c [revision 2110]
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Sat Nov 12 00:47:48 2011 +0400
Mark some local functions as static, cosmetics
commit e0c11dc6e283569606aaa97767401c6a13c2529d [revision 2109]
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Fri Nov 11 23:19:02 2011 +0400
Fix crash if timecode file opening fails
commit a14db080c3fdba4cadc38152a292bb1fa216d50e [revision 2108]
Author: Fabian Greffrath <fabian+debian@greffrath.com>
Date: Fri Nov 11 13:25:43 2011 -0800
Configure: force PIC for shared build on PARISC and MIPS
commit 6a0bd421bf5fd006012ddcd1be2072a8736b2d27 [revision 2107]
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Sat Oct 22 19:41:07 2011 +0400
Improve yasm version check
Previous check allowed certain earlier versions that weren't fully compatible.
commit 07efeb45db224b7757880d4d63bb549fb454f6db [revision 2106]
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Tue Oct 18 14:30:26 2011 -0700
Add fenc prefetching to adaptive quant
Many fewer cache misses, faster adaptive quant.
These builds will NOT work with Avidemux 2.5.4 or older. Please update to Avidemux 2.5.5 r7694 (http://forum.doom9.org/showpost.php?p=1543434&postcount=1695) or later now!
Dark Shikari
7th December 2011, 00:23
You should probably update to r2120.
LoRd_MuldeR
7th December 2011, 00:38
You should probably update to r2120.
Argh. Will do tomorrow. Added a warning for now ;)
Dark Shikari
7th December 2011, 00:48
Argh. Will do tomorrow. Added a warning for now ;)Warning: these builds are broken, don't download them? Might as well just delete the link! ;)
LoRd_MuldeR
8th December 2011, 00:10
libx264 SVN-r2120 library pack:
libx264 SVN-r2120 complete "all-in-one" library pack (mirror #1) (http://code.google.com/p/mulder/downloads/detail?name=libx264-119-r2120M-win32.7z&can=2&q=)
libx264 SVN-r2120 complete "all-in-one" library pack (mirror #2) (http://www.mediafire.com/file/69267e8uc4vaq4b/libx264-119-r2120M-win32.7z)
Changelog:
commit 0c7dab9c2a106ce3ee5d6ad7282afb49e1cc3954 r2120
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Tue Dec 6 14:39:21 2011 -0800
Fix regression in r2118
Broke trellis with i16x16 macroblocks.
These builds will NOT work with Avidemux 2.5.4 or older. Please update to Avidemux 2.5.5 r7694 (http://forum.doom9.org/showpost.php?p=1543434&postcount=1695) or later now!
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.