Avidemux (with emphasis on x264/h264 GUI)

[LoRd_MuldeR]

Can you try this patch (http://pastebin.com/m5c51dbd8)? It should remove the need for force_align_arg_pointer.

libx264 SVN-r1065 + "this" Patch:
http://www.mediafire.com/file/ztgneowgehm/libx264-r1065-patched-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-2 (fprofiled). Tested with Avidemux 2.4.3 r4502.


Looks good :thanks:

[Dark Shikari]

libx264 SVN-r1065 + "this" Patch:
http://www.mediafire.com/file/ztgneowgehm/libx264-r1065-patched-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-2 (fprofiled). Tested with Avidemux 2.4.3 r4502.


Looks good :thanks:In that case, added to commit queue. Expect it tomorrow or something.

[LoRd_MuldeR]

libx264 SVN-r1069:
http://www.mediafire.com/file/dajwjdjjizz/libx264-r1069-gcc432-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Tested with Avidemux 2.4.3 r4502.

[LoRd_MuldeR]

Avidemux 2.4.3 SVN-r4508 (2009-01-01)
http://www.avidemux.org/

Revision 4508 (01 Jan 2009)
# Updated x264 to r1069.

4508 - [I18N] Russian update for Qt translation by ETY82
4507 - [dib] update libavcodec BMP decoder (backport r15924)
4506 - [dib] remove internal RGB/DIB decoder
4505 - [dib] use libavcodec decoder instead of internal for DIBs
4504 - [swscale] rename rgb/bgr 15/16 function names to match actual implementation (backport of r24965)
4503 - [rawvid] use libavcodec decoder instead of internal for raw video and support BGR24 colourspace
4502 - [mp4] correctly generate extra data for esds atom (fixes regression in r4375)

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.4)

[Pulstar]

Avidemux accepts Sorenson H.263 (FLV) but it doesn't export it to MP4 container properly (using the COPY command). Where's the problem? (using r4276)

[LoRd_MuldeR]

Where's the problem? (using r4276)

You are using a very outdated version. That probably is the problem. Please update and try again...

http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux

[Pulstar]

Thanks I will try the latest SVN :)

Edit - I'm still having problems embedding FLV into MP4, but with other formats like OGM it works fine. Also, I get this message when I try to load an AVC AVI into the program
If the file is using B-frames as reference it can lead to a crash or stuttering.
Avidemux can use another mode which is safe but YOU WILL LOSE FRAME ACCURACY.
Do you want to use that mode?

Regardless how I answer the prompt (Continue/Cancel) I can't export AVC to MP4 container either and receive a "failed" message. Any help would be greatly appreciated :)

[LoRd_MuldeR]

libx264 SVN-r1073:
http://www.mediafire.com/file/tqobkzqh4un/libx264-r1073-gcc432-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Tested with Avidemux 2.4.3 r4508.

[LoRd_MuldeR]

libx264 SVN-r1074:
http://www.mediafire.com/file/nm1nwjwyz3y/libx264-r1074-gcc432-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Tested with Avidemux 2.4.3 r4508.

[Pulstar]

Hello.. I still have a few questions I would appreciate answering :)

1- Is there a way to import AAC into AVIDemux? I want to use Nero's codec instead of Libfaac.
2- Are Yadif's default settings (temporal & spatial checks, TFF) good for most interlaced material? Is there a good tutorial on how to discern TFF/BFF?
3- Does the postproc option affect encoding or is it just for the preview pane? Is it recommended to enable postproc for target x264 encodes in VFW or just let the deblocking filter handle it?

[LoRd_MuldeR]

1- Is there a way to import AAC into AVIDemux? I want to use Nero's codec instead of Libfaac.

Try "Audio" -> "Main Track" -> "External MP3" and choose your AAC file. Maybe that works. It does work with MP3 and MP2 at least (never tried AAC).

If it doesn't work, then the answer is "No". In that case you'll need to mux outside Avidemux, which shouldn't be a big problem either.

2- Are Yadif's default settings (temporal & spatial checks, TFF) good for most interlaced material? Is there a good tutorial on how to discern TFF/BFF?

The field order (TFF -vs- BFF) totally depends on your source!

Use Yadif's "Bob" mode and then play the video in preview. If it plays smooth, then the field order is correct. If the video jumps forth and back, then field order is wrong!

Also I'd use either "Temporal & spatial check" or "Bob, temporal & spatial check" for my encode.
The former will keep the framerate (25i -> 25p), the latter doubles framerate (25i -> 50p). Of course framerate doubling gives nicer motion, but costs more bits to encode...

3- Does the postproc option affect encoding or is it just for the preview pane? Is it recommended to enable postproc for target x264 encodes in VFW or just let the deblocking filter handle it?

"Avidemux" and "VfW" don't belong to the same posting :sly:

However the Porstproc options do effect your encode. And it's your decision what you prefer:
With Postproc enabled you will get fewer "blocking" artifacts at the cost of reduced sharpness/details. Decide what you want ;)

Also note that x264's "Inloop Deblocking" option does not remove blocks that were already present in your source!

[Pulstar]

Oops :o sorry I forgot Avidemux doesn't rely on Directshow filters!
Thanks for answering my questions :D

[LoRd_MuldeR]

Oops :o sorry I forgot Avidemux doesn't rely on Directshow filters!

DirectShow and VfW are two completely different things. And both do not belong to Avidemux ;)

[LoRd_MuldeR]

Avidemux 2.4.3 SVN-r4532 (2009-01-11)
http://www.avidemux.org/

Revision 4532 (11 Jan 2009)
# Updated x264 to r1074.
# Updated Cairo to version 1.8.6-1.
# Updated GLib to version 2.18.4-1.
# Updated GTK+ to version 2.14.7-1.
# Updated libpng to version 1.2.34-1.

4532 - [cli] add AAC parameter to CLI (patch by LoRd_MuldeR) plus a few cosmetic tweaks
4526 - [Win32] fix installer to create Qt4 shortcuts & update package notes
4519 - [x264] use the same settings for 1st pass as 2nd pass
4508 - [I18N] Russian update for Qt translation by ETY82

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.4)

[LoRd_MuldeR]

libx264 SVN-r1080:
http://www.mediafire.com/file/zoqrdnwmk2m/libx264-r1080-gcc432-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Tested with Avidemux 2.4.3 r4532.

[ffmpeg]

Dear:

What's the meaning of "fprofiled"?

[LoRd_MuldeR]

Dear:

What's the meaning of "fprofiled"?

When you compile x264 with GCC, you can run "make" or "make fprofiled".

The latter will allow GCC to analyze the executable code while it is running. This way GCC can find code paths that are executed frequently and code paths that are executed rarely. After the profiling is done, it will re-compile the executable with the collected information in mind. That allows additional optimizations, which couldn't have been applied without the profiling step. So in short: Compiling with "fprofiled" takes much longer (as x264 will encode a given sample video over and over again during the profiling process), but yields a faster and smaller binary...

(Note that "yields a smaller binary" doesn't apply in general, but for libx264.dll it does apply)

[fxtech]

libx264 SVN-r1080:
http://www.mediafire.com/file/zoqrdnwmk2m/libx264-r1080-gcc432-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Tested with Avidemux 2.4.3 r4532.

Hi LM , there is a reason to not compile it with SSE and P4 profile ?

[Dark Shikari]

Hi LM , there is a reason to not compile it with SSE and P4 profile ?Given how weird Netburst is, compiling for Pentium 4 may actually have a rather significant drop in performance on any sane CPU...

[avih]

LoRd_MuldeR, do your avidemux packages include your compiled x264 dlls? or should one apply them manually?

[buzzqw]

it already include it.. but LM provides also upgrade to dll builds :)

BHH

[fxtech]

Given how weird Netburst is, compiling for Pentium 4 may actually have a rather significant drop in performance on any sane CPU...

could we try with P3 then ? it have a shorten pipeline then P4 and also support SSE :-) , i will try !

[LoRd_MuldeR]

LoRd_MuldeR, do your avidemux packages include your compiled x264 dlls? or should one apply them manually?

I just mirror Gruntster's Avidemux builds on my site. These include a recent libx264.dll, but probably not the latest one (see "Build Info.txt").
That's because he obviously can't make a new installer package for every single x264 revision.

So if you think the latest x264 changes are worth upgrading, you can pick my libx264.dll and replace the one in your Avidemux folder...

[LoRd_MuldeR]

could we try with P3 then ? it have a shorten pipeline then P4 and also support SSE :-) , i will try !

SSE1, as supported by the P3, doesn't help x264. That's because SSE1 is floating point stuff. x264 needs integer operations, like SSE2.

[fxtech]

SSE1, as supported by the P3, doesn't help x264. That's because SSE1 is floating point stuff. x264 needs integer operations, like SSE2.

Sorry i have to say befrore , i was referring to SSE2

[LoRd_MuldeR]

Sorry i have to say befrore , i was referring to SSE2

You were referring to P3 and that CPU doesn't have SSE2, only SSE1. Hence the P3 doesn't support any helpful SSE instructions for x264.

[fxtech]

maybe that is not the right place , but gcc have p3 opt for it short pipeline (it work with core1 that is a rework of the p3 core) and SSE2 flat to add sse2 opt code path

with the -march flags you can put P3 (better pentium3m in that way gcc4.3 know that it have SSE2 also) or what you want and tell him to substitute or opt code for SSE2 with -mfpmath=sse -msse -msse2 -O3

[Dark Shikari]

SSE2? Well, it's not as if the GCC autovectorizer is remotely useful for anything...

[LoRd_MuldeR]

maybe that is not the right place , but gcc have p3 opt for it short pipeline (it work with core1 that is a rework of the p3 core) and SSE2 flat to add sse2 opt code path

What's the point? If you allow GCC to use SSE2 instructions that doesn't necessarily mean it will be helpful for anything. Most (all?) performance-critical functions in x264 are written as hand-optimized assembler code, so compiler flags won't make any difference performance-wise. And GCC's optimizations are known to be "suboptimal". Also: If you make a build with SSE2 enabled, the resulting binary certainly won't run on a Pentium III processor, as the P3 doesn't support SSE2. It would throw an "Illegal Instruction" exception and crash. So making a P3-optimized binary with SSE2 enabled is nonsense...

[fxtech]

wihte flag , hand down

[laserfan]

This year-old post was wrt fixing odd "jumps" of frames when viewing:Not until Avidemux will implement a "new" method to handle H.264 streams in a frame-accurate way.
I think mean has announced that for the upcoming v2.5 series, but I wouldn't expect too much.
All the Avidemux developers (mainly Mean and Gruntster) spend their free time to work on the project.
So new features can take a while...
I'd like to use AviDemux 2.4.3 r4508to visually display where I-frames are in my x264 encodings, and am discovering today that it appears off by one frame. For example, index a 264 encoding with neuron2's tools, make an .avs to open the video in VirtualDub, then look for a frame that is a scene change and is clearly an I-frame (as predicted by the .stats file used for encoding in the first place). Let's say that frame number is 1234, and in Vdub it's confirmed to be the first frame in the new scene.

Then open that file in AviDemux and let it make an index. Reading the index it says frame 1234 is indeed an I-frame. Good, the same as I expected. But now, in Avidemux seek to frame 1234, and instead of the expected frame, the visual is for the frame PRIOR, and the frame type is for *that frame* (e.g. P or B type) but the time code is correct for the I-frame (the frame following)!

I've been trying to use Avidemux to set Chapter marks on I-frames and am struggling to explain the apparent inconsistency between the numbering & the visuals. Can someone help? :confused:

[LoRd_MuldeR]

This year-old post was wrt fixing odd "jumps" of frames when viewing:
I'd like to use AviDemux 2.4.3 r4508to visually display where I-frames are in my x264 encodings, and am discovering today that it appears off by one frame. For example, index a 264 encoding with neuron2's tools, make an .avs to open the video in VirtualDub, then look for a frame that is a scene change and is clearly an I-frame (as predicted by the .stats file used for encoding in the first place). Let's say that frame number is 1234, and in Vdub it's confirmed to be the first frame in the new scene.

Latest Avidemux (currently r4532) still doesn't support access to H.264 streams in a frame-accurate way. We need to wait for Avidemux 2.6 now ;)

For the meantime you can use AVSProxy (GUI) with DGAVCIndex to load H.264 streams into Avidemux through Avisynth. That's how I do it currently...

(Of course that way Avidemux won't display frame types)

[laserfan]

Thanks LM for your very fast reply, and confirmation of my suspicion! ;)

I appreciate it very much--I will stop beating my head against that wall for now! :)

Latest Avidemux (currently r4532) still doesn't support access to H.264 streams in a frame-accurate way. We need to wait for Avidemux 2.6 now ;)

For the meantime you can use AVSProxy (GUI) with DGAVCIndex to load H.264 streams into Avidemux through Avisynth. That's how I do it currently...

(Of course that way Avidemux won't display frame types)

[LoRd_MuldeR]

libx264 SVN-r1093:
http://www.mediafire.com/file/0ytuq1lndnm/libx264-r1093-gcc432-fprofiled-patched.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Patched back to core version 65 in order to make it work with Avidemux 2.4.3 r4532.

[LoRd_MuldeR]

libx264 SVN-r1096:
http://www.mediafire.com/file/z21yttztt2j/libx264-r1096-gcc432-fprofiled-patched.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Patched back to core version 65 in order to make it work with Avidemux 2.4.3 r4532.

[LoRd_MuldeR]

Avidemux 2.4.3 SVN-r4559 (2009-02-02)
http://www.avidemux.org/

Revision 4558 (02 Feb 2009)
# Updated Fontconfig to version 2.6.0-2.
# Updated Freetype to version 2.3.8-1.
# Updated Pango to version 1.22.4-1.
# Updated x264 to r1097.

4559 - [Win32] update installer for new libexpat
4558 - [I18N] various translation fixes
4557 - [Qt] honour LFs for alert boxes
4536 - [mp4] don't report an error when queue runs out of audio
4535 - [automake] update build script
4532 - [cli] add AAC parameter to CLI (patch by LoRd_MuldeR) plus a few cosmetic tweaks

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.4)

[LoRd_MuldeR]

libx264 SVN-r1099:
http://www.mediafire.com/file/1dr0fzgzqhw/libx264-r1099-gcc432-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Tested with Avidemux 2.4.3 r4559.

[LoRd_MuldeR]

libx264 SVN-r1101:
http://www.mediafire.com/file/zzmwjhqmwmm/libx264-r1101-gcc432-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Tested with Avidemux 2.4.3 r4559.

[LoRd_MuldeR]

libx264 SVN-r1109:
http://www.mediafire.com/file/2eydy4mgldy/libx264-r1109-gcc432-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Tested with Avidemux 2.4.4 Final.

[LoRd_MuldeR]

libx264 SVN-r1112:
http://www.mediafire.com/file/4otmlmzmnmj/libx264-r1112-gcc432-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Tested with Avidemux 2.4.4 Final.

[LoRd_MuldeR]

libx264 SVN-r1114:
http://www.mediafire.com/file/mowdyn4tjq3/libx264-r1114-gcc432-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Tested with Avidemux 2.4.4 Final.

--------------------------------------------------

Debug build:
http://www.mediafire.com/file/ye3tltlwzyi/libx264-r1114-gcc432-debug.7z

Debug build with optimizations:
http://www.mediafire.com/file/3wonwzt3mwz/libx264-r1114-gcc432-debug-optimized.7z

[LoRd_MuldeR]

libx264 SVN-r1114 fixed:
http://www.mediafire.com/file/m2nn3c2w2zl/libx264-r1114-gcc432-fprofiled-fixed.7z

Compiled with MinGW GCC 4.3.2-tdm-2, march=pentium2, fprofiled. Tested with Avidemux 2.4.4 Final.

This build contains an experimental fix for the EXCEPTION_INT_DIVIDE_BY_ZERO crash that people reported!

The patch that has been used can be found here:
x264_nodivzero.diff (http://www.mediafire.com/file/jjwgnzytzvn/x264_nodivzero.diff)

[Faiakes]

Thanks. Much needed...

[LoRd_MuldeR]

Avidemux 2.5 SVN-r4629 (2009-02-24)
http://www.avidemux.org/

4629 - [mac] fix referencing of ffmpeg libs on Mac
4628 - [mac] correctly reference ffmpeg libs on Mac
4627 - [mac] fix name mangling for Mac
4626 - [mac] CMake 2.6 support for Mac build (patch by surfer)
4625 - [x264] fix setting of max GOP on x264 config window for Qt
4622 - [xvid/x264] remove threading options for x264 and Xvid from Preferences window
4621 - [filter] add spinboxes to Contrast and MPlayer eq2 configure windows for Qt
4620 - [x264] support extra adaptive b-frame decision option
4619 - [x264] close encoder at end of pass, not end of encoding
4618 - [ffmpeg] update FFmpeg to r17480 & libswscale r28690
4617 - [x264] fix serialisation of idc level and direct prediction size options
4616 - [aften] activate Aften plugin
4615 - [mp4/mkv] fix mp4 and mkv muxing to work with ffmpeg update
4614 - [x264] fix flushing using null frames
4609 - [ffmpeg] fix install dir for Unix [part 2]
4608 - [ffmpeg] fix install dir for Unix
4607 - [CMake] fix debug build
4590 - [Win32] libx264 build script
4589 - [UI] update copyright year
4588 - [Win32] use correct icons for executables
4587 - [Win32] make plugins folder less obtuse
4586 - [Win32] split UIs to separate installers
4585 - [svn] remove empty folders
4584 - [Win32] update installer to remember previously selected components when upgrading
4582 - [Win32] update installer script for 2.5 (generate log for uninstalling) [Part 2]
4581 - [Win32] update installer script for 2.5 (now using Modern UI 2 and Memento) [Part 1]
4580 - [Win32] update build scripts for 2.5
4579 - [Merge] merge platform build scripts from 2.4 branch
4573 - [Merge] integrate changes from 2.4 branch (r4572)
4561 - [ffmpeg] update to FFmpeg r16945 & libswscale r28447
4560 - [x264] support libx264 core 66

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1114:
http://www.mediafire.com/file/m0ewwtjtybw/libx264-r1114-gcc432-fprofiled-try2.7z

Compiled with MinGW GCC 4.3.3-tdm-1, march=pentium2, fprofiled. Tested with Avidemux 2.5 r4629.

Patches used:
* no_div_zero.diff (http://www.mediafire.com/file/win232mgm4q/no_div_zero.diff)
* print_params.diff (http://www.mediafire.com/file/0znczeg3mm4/print_params.diff)

[Ryo94]

I can't uninstall v2.4.4 or run the v2.5 setup, in both cases I get this message

http://i39.tinypic.com/35ko1oy.jpg

Any solution? Thanks in advance.

[LoRd_MuldeR]

I can't uninstall v2.4.4 or run the v2.5 setup, in both cases I get this message

http://i39.tinypic.com/35ko1oy.jpg

Your installer is corrupted. The error message is pretty clear, isn't it?

Any solution? Thanks in advance.

Re-download the installer.

If the problem occurs again, you must check your internet connection and your hard-drive for errors...

[Inspector.Gadget]

LoRd_MuldeR - is there a way to use the Avidemux 2.4 audio decoder addons (DTS / AMR-NB) wth the new 2.5 SVN builds? I've tried placing the .dll files in both the root Avidemux install directory and the "Audio Decoders" folder and I still receive warnings about bad audio on files with DTS audio. The built-in support also doesn't appear to have radio boxes for DTS or AMR-NB support.

[LoRd_MuldeR]

I'm not sure. But I guess we need a DTS/ARM-NB Avidemux-Plugin now ;)

Just putting the decoder libraries in the "plugins\audioDecoder" folder won't work for obvious reasons...

--- [EDIT] ---

Looking at the SVN repository, it seems there is are AMRNB and DCA plugins available:
http://svn.berlios.de/wsvn/avidemux/branches/avidemux_2.5_branch_gruntster/plugins/ADM_audioDecoders/ADM_ad_amrnb/?rev=4637#

There just is no binary included in the installer (yet).

[roozhou]

I'm not sure. But I guess we need a DTS/ARM-NB Avidemux-Plugin now ;)

Just putting the decoder libraries in the "plugins\audioDecoder" folder won't work for obvious reasons...

--- [EDIT] ---

Looking at the SVN repository, it seems there is are AMRNB and DCA plugins available:
http://svn.berlios.de/wsvn/avidemux/branches/avidemux_2.5_branch_gruntster/plugins/ADM_audioDecoders/ADM_ad_amrnb/?rev=4637#

There just is no binary included in the installer (yet).

IIRC ffmpeg has an DTS decoder. Why does avidemux require a DCA plugin to decode DTS?

[LoRd_MuldeR]

IIRC ffmpeg has an DTS decoder. Why does avidemux require a DCA plugin to decode DTS?

Because all encoders and decoders have been made plugins in Avidemux 2.5 :)

Also I think the official download does not contain the ARM-NB and DCA decoders due to licensing/patenting issues...

Libdca and amrnb aren’t distributed with Avidemux due to patent right issues. However, since r3091, Avidemux 2.4 can automatically detect and use these libraries once they’re installed.

[Inspector.Gadget]

Yeah, those were the plugins I tried. Is the 2.5 branch just not set up to recognize them yet?

[LoRd_MuldeR]

Yeah, those were the plugins I tried. Is the 2.5 branch just not set up to recognize them yet?

I say it again: For Avidemux 2.5 you will need audio-decoder Plugins. There was no such thing for Avidemux 2.4, as it didn't use Plugins :rolleyes:

Hence the ARM-NB and DCA decoder libraries (alone) won't work with Avidemux 2.5. You need suitable Avidemux Plugins!

Also if you look at the Avidemux 2.5 source tree, you will see that there already are ARM-NB and DCA plugisn, only somebody needs to compile them ;)

[Inspector.Gadget]

Ah, now I understand: the whole architecture changed.

[LoRd_MuldeR]

Ah, now I understand: the whole architecture changed.

Exactly. They moved all the encoders and decoders from the core applications to Plugins.

[LoRd_MuldeR]

libx264 SVN-r1115:

MinGW GCC 3.4.5-r3, vanilla:
http://www.mediafire.com/file/vy50i0ngmkw/libx264-r1115-gcc345-fprofiled.7z

MinGW GCC 4.3.3-tdm-1, patched:
http://www.mediafire.com/file/zvj2alwnoam/libx264-r1115-gcc433-fprofiled-patched.7z

MinGW GCC 4.3.3-tdm-1, vanilla:
http://www.mediafire.com/file/gznntzwrzd0/libx264-r1115-gcc433-fprofiled-vanilla.7z

All builds: march=pentium2, fprofiled. Tested with Avidemux 2.5 SVN-r4629.

[LoRd_MuldeR]

LoRd_MuldeR - is there a way to use the Avidemux 2.4 audio decoder addons (DTS / AMR-NB) wth the new 2.5 SVN builds? I've tried placing the .dll files in both the root Avidemux install directory and the "Audio Decoders" folder and I still receive warnings about bad audio on files with DTS audio. The built-in support also doesn't appear to have radio boxes for DTS or AMR-NB support.

DTS and ARM-NB plugins for Avidemux 2.5 are now available:
http://avidemux.org/admForum/viewtopic.php?pid=18985#p18985

[Inspector.Gadget]

Excellent, thank you very much for letting us know!

[Faiakes]

Thanks!

[LoRd_MuldeR]

Avidemux 2.5 SVN-r4648 (2009-03-02)
http://www.avidemux.org/

Revision 4648 (02 Mar 2009)
# Updated x264 to r1115.

4648 - [qt] add plugins menu option to Qt main window
4647 - [cmake] pass extra c and ld flags to ffmpeg configure
4646 - [cmake] add more output to verbose mode
4645 - [Mov] Oops
4644 - [Mov] Correctly detect MSADPCM in mov
4640 - [plugins] fix Mac build for FluxSmooth and ResampleFps
4639 - [plugins] instruct plugin to prepare for first pass upon initialisation so extra header info can be determined earlier
4638 - [x264/xvid] employ a locale-agnostic output for numbers in settings XML
4637 - [x264] fix compilation error for GTK plugin when using a libx264 core version earlier than 65
4636 - [esd] fix link libraries
4635 - [plugin] make plugin symbols local (not global) on Unix so functions with same name don't clash
4634 - [script] add very basic dialogFactory class to ECMAScript engine
4633 - [mac] add Cocoa framework to ldflags for renderer
4629 - [mac] fix referencing of ffmpeg libs on Mac

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[Faiakes]

I'm still having trouble with converting DVD .vob files to x264 MKV or even MP4 with any of the buids past the stable 2.4.4
Is it just me? I can post specific configurations and errors if you want.

[LoRd_MuldeR]

I'm still having trouble with converting DVD .vob files to x264 MKV or even MP4 with any of the buids past the stable 2.4.4
Is it just me? I can post specific configurations and errors if you want.

What does "trouble" mean? Does it crash or what? If so, what does the log say?

Also for Avidemux 2.5 troubleshooting, you may want to post here:
http://avidemux.org/admForum/viewforum.php?id=18

[LoRd_MuldeR]

libx264 SVN-r1119:

MinGW GCC 4.3.3-tdm-1:
http://www.mediafire.com/file/ynfaxm2hjil/libx264-r1119-gcc433-fprofiled-core66.7z

MinGW GCC 3.4.5-r3:
http://www.mediafire.com/file/murxn2z4025/libx264-r1119-gcc345-fprofiled-core66.7z

Both builds: march=pentium2, fprofiled. Tested with Avidemux 2.5 SVN-r4648.

[Faiakes]

What does "trouble" mean? Does it crash or what? If so, what does the log say?

Also for Avidemux 2.5 troubleshooting, you may want to post here:
http://avidemux.org/admForum/viewforum.php?id=18OK, will post specifics there today.

[LoRd_MuldeR]

Avidemux 2.5 SVN-r4658 (2009-03-05)
http://www.avidemux.org/

Revision 4658 (05 Mar 2009)
# Updated Qt to version 4.5.0.

4658 - [core] remove unnecessary kludge now ffmpeg is fixed
4657 - [ffmpeg] change cross compilation flag to set architecture
4656 - [videnc] fix 2nd pass encoding
4655 - [swscale] increase maximum width to 4096
4654 - [win32] enable shared libgcc and libstdc++ to reduce size and memory usage
4653 - [videnc] tweak video encoder plugin api to make things cleaner
4652 - [cmake] correct linker flag variable
4651 - [ffmpeg] add CMake option to instruct ffmpeg's configure to perform a cross compilation
4650 - [i18n] remove duplicate messages from ts files during build since Qt 4.5 doesn't like it
4649 - [qt] prevent crash when clicking external filters
4648 - [qt] add plugins menu option to Qt main window

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1123:
http://www.mediafire.com/file/md2mocjjyum/libx264-r1123-gcc433-fprofiled-core66.7z

Compiled with MinGW GCC 4.3.3-tdm-1, march=pentium2, fprofiled. Tested with Avidemux 2.5 r4658.

[LoRd_MuldeR]

libx264 SVN-r1125:

MinGW GCC 4.3.3-tdm-1:
http://www.mediafire.com/file/y2i5nwiyyq4/libx264-r1125-gcc433-fprofiled-core66.7z

MinGW GCC 4.2.1-sjlj:
http://www.mediafire.com/file/2zm2zyhcjmc/libx264-r1125-gcc421-fprofiled-core66.7z

MinGW GCC 3.4.5-r3:
http://www.mediafire.com/file/jth0mymrmjh/libx264-r1125-gcc345-fprofiled-core66.7z

All builds: march=pentium2, fprofiled. Tested with Avidemux 2.5 SVN-r4658 -and- 2.4.4 Final.

[Faiakes]

libx264 SVN-r1125:

MinGW GCC 4.3.3-tdm-1:
http://www.mediafire.com/file/y2i5nwiyyq4/libx264-r1125-gcc433-fprofiled-core66.7z

MinGW GCC 3.4.5-r3:
http://www.mediafire.com/file/jth0mymrmjh/libx264-r1125-gcc345-fprofiled-core66.7z

Both builds: march=pentium2, fprofiled. Tested with Avidemux 2.5 SVN-r4658 -and- 2.4.4 Final.
May I ask what the difference is between them?

Is one of them better suited for the latest SVN builds and nother for the stable release?

[LoRd_MuldeR]

May I ask what the difference is between them?

They were compiled with different versions of the MinGW/GCC toolchain, but they should work identical.

However some people reported crashes with x264 in Avidemux (which I couldn't reproduce until now) and after some discussion it came down to a potential compiler bug.

There also is a patch to workaround the crash, but I don't currently use it. Instead I went back to MinGW 3.4.5, which hopefully is more stable than 4.3.3.

So if you encounter a crash with my MinGW 4.3.3 build, then please try my MinGW 3.4.5 build. Still waiting for feedback...

Is one of them better suited for the latest SVN builds and nother for the stable release?

Nope. At least not to my knowledge.

[LoRd_MuldeR]

Added a MinGW GCC 4.2.1-sjlj build:
http://forum.doom9.org/showpost.php?p=1258879&postcount=1067

[LoRd_MuldeR]

libx264 SVN-r1127:

MinGW GCC 4.3.3-tdm-1:
http://www.mediafire.com/file/wmdw3tzmzma/libx264-r1127-gcc433-fprofiled-core66.7z

MinGW GCC 4.2.1-sjlj:
http://www.mediafire.com/file/0jy5mtdmnec/libx264-r1127-gcc421-fprofiled-core66.7z

MinGW GCC 3.4.5-r3:
http://www.mediafire.com/file/yodvnmayxm2/libx264-r1127-gcc345-fprofiled-core66.7z

All builds: march=pentium2, fprofiled. Tested with Avidemux 2.5 SVN-r4658 -and- 2.4.4 Final.

[heather]

I have been using Avidemux 2.4.3 for Win32.

Use a USB from Pinnacle to capture HD and SD TV.

Run the Saved Video (in TS) through ProjectX to clean up the errors and demux the TS file.

Next use Avidemux to REMUX the two files from ProjectX.

Next load the Remuxed file into Avidemux and do the cutting and encoding for DVD.

Trouble is that the image displayed in the Avidemux Window is always a 4X3 format and it is squashed making people look skinney.

Most of the TV Captures are 16X9. (a) SD, 720x576 16x9 (b) HD, 1440x1080 16x9 (c) HD, 1920x1080 ?

Yet I see on the download Web Site a Wide image in Avidemux.

How is this achieved? I just cant find any settings for it.

Heather

[LoRd_MuldeR]

I have been using Avidemux 2.4.3 for Win32.

Use a USB from Pinnacle to capture HD and SD TV.

Run the Saved Video (in TS) through ProjectX to clean up the errors and demux the TS file.

Next use Avidemux to REMUX the two files from ProjectX.

Next load the Remuxed file into Avidemux and do the cutting and encoding for DVD.

Trouble is that the image displayed in the Avidemux Window is always a 4X3 format and it is squashed making people look skinney.

Yet I see on the download Web Site a Wide image in Avidemux.

How is this achieved? I just cant find any settings for it.

Heather

Probably your source is anamorphic (http://en.wikipedia.org/wiki/Anamorphic). Avidemux shows the image as-is, without any PAR applied ;)

If you encode your video with the proper PAR value (not that there is an "as input" option) it will look correctly in a player.

You can also use the "resize" filter to convert it to the 1:1 PAR (aka "square pixels").

[roozhou]

@MuldeR
What is the difference between GCC 4.3.3 tdm and GCC 4.2.1 sjlj?
Which version of binutil are you using?

[LoRd_MuldeR]

What is the difference between GCC 4.3.3 tdm and GCC 4.2.1 sjlj?

GCC 4.3.3-tdm is taken from here, it's newer than the "official" builds:
http://www.tdragon.net/recentgcc/

(Also see the "usage notes" about "Dwarf-2 vs. SJLJ unwinding" on that page)

GCC 4.2.1-sjlj is taken from official MinGW site:
http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=241304&release_id=532062

Which version of binutil are you using?

v2.19.1 for GCC 4.x.x, v2.17.50 for GCC 3.4.5

[LoRd_MuldeR]

Avidemux 2.5 SVN-r4685 (2009-03-14)
http://www.avidemux.org/

Revision 4685 (14 Mar 2009)

4685 - [Win32] update installer to install system scripts
4684 - [xvid] fix saving of custom matrix type
4683 - [script] add scripted PSP auto wizard
4682 - [qt] reposition Auto menu
4681 - [x264] change PSP config xml to only include tags that are different to x264 default
4680 - [x264/xvid] make all schema elements optional
4679 - [x264] fix loading of idc level
4678 - [auto] remove internal auto wizards from Qt interface
4677 - [script] exclude svn folder from installation of system scripts

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1128:

MinGW GCC 4.3.3-tdm-1:
http://www.mediafire.com/file/xi5dlk1lmwo/libx264-r1128-gcc433-fprofiled-core66.7z

MinGW GCC 4.2.1-sjlj:
http://www.mediafire.com/file/mmjmmctf5jz/libx264-r1128-gcc421-fprofiled-core66.7z

MinGW GCC 3.4.5-r3:
http://www.mediafire.com/file/yjjdzu5mmy5/libx264-r1128-gcc345-fprofiled-core66.7z

Cross-compiled from Ubuntu:
http://www.mediafire.com/file/zgzn1zh5gli/libx264-r1128-cross-gcc421-core66.7z

All builds: march=pentium2, fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.

[LoRd_MuldeR]

libx264 SVN-r1129:

MinGW GCC 4.3.3-tdm-1:
http://www.mediafire.com/file/dzjgomkt2jm/libx264-r1129-gcc433-fprofiled-core66.7z

MinGW GCC 4.2.1-sjlj:
http://www.mediafire.com/file/f1oqndjonvn/libx264-r1129-gcc421-fprofiled-core66.7z

MinGW GCC 3.4.5-r3:
http://www.mediafire.com/file/wzim0rgzwqw/libx264-r1129-gcc345-fprofiled-core66.7z

All builds: march=pentium2, fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.

[roozhou]

v2.19.1 for GCC 4.x.x, v2.17.50 for GCC 3.4.5

Well 2.18 and 2.19 sometimes produce broken EXEs for me. (always for MPlayer)

[LoRd_MuldeR]

Well 2.18 and 2.19 sometimes produce broken EXEs for me. (always for MPlayer)

Hmmm, broken in what way exactly? My libx264 builds seem to work correctly...

[roozhou]

Hmmm, broken in what way exactly? My libx264 builds seem to work correctly...

Broken in aligned SSE instruction.
Well, this only appears in EXEs while DLLs are OK.

[LoRd_MuldeR]

Broken in aligned SSE instruction.
Well, this only appears in EXEs while DLLs are OK.

Guess I'd have encountered a crash, if that was the case with my libx264 builds...

[IceManZ]

Is there a simple way to import AVC video profiles in avidemux x264 control panel (ie: Sharktooth ones) ?

Thanks a lot for all your constructiv answers :)

[LoRd_MuldeR]

Is there a simple way to import AVC video profiles in avidemux x264 control panel (ie: Sharktooth ones) ?

Thanks a lot for all your constructiv answers :)

MeGUI's profiles are cannot be imported into Avidemux directly.

Anyway, these "profiles" are simply collections of x264 settings. So you can simply look what x264 settings are used in a specific MeGUI profile and then choose the very same settings in Avidemux' x264 dialog. Then you can even save these settings as a Avidemux script, so you don't need to set them up manually every time...

[IceManZ]

Thanks a lot for your fast answer LoRd_MuldeR.

I try to "map" the settings between MeGui profils and avidemux x264 settings and it's really disturbing. I can't find always the same terms / words.

As Sharktooth's profiles, Do you know if any user has made available their tries in "mapping" settings ?

Thanks a lot for your time.

[LoRd_MuldeR]

I can't find always the same terms / words.

Anything your are missing in particular?

[LoRd_MuldeR]

libx264 SVN-r1130:

MinGW GCC 4.3.3-tdm-1:
http://www.mediafire.com/file/jvl0hxdwzhv/libx264-r1130-gcc433-fprofiled-core66.7z

MinGW GCC 4.2.1-sjlj:
http://www.mediafire.com/file/tmdm5nwzumc/libx264-r1130-gcc421-fprofiled-core66.7z

MinGW GCC 3.4.5-r3:
http://www.mediafire.com/file/qynhyly2zjr/libx264-r1130-gcc345-fprofiled-core66.7z

All builds: march=pentium2, fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
Updated pthreads library, latest changelog entry: 2009-mar-19.

[LoRd_MuldeR]

libx264 SVN-r1134:

MinGW GCC 4.3.3-tdm-1:
http://www.mediafire.com/file/tnof2oqnmzw/libx264-r1134-gcc433-fprofiled-core66.7z

MinGW GCC 4.2.1-sjlj:
http://www.mediafire.com/file/tm3mymhj0ey/libx264-r1134-gcc421-fprofiled-core66.7z

MinGW GCC 3.4.5-r3:
http://www.mediafire.com/file/4mmruttklnz/libx264-r1134-gcc345-fprofiled-core66.7z

All builds: march=pentium2, fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.

[Yobbo]

Lord Mulder when you post up these "libx264" builds, what am I meant to do with them?

[LoRd_MuldeR]

Lord Mulder when you post up these "libx264" builds, what am I meant to do with them?

Replace the old DLL's in your Avidemux folder? :p

(You may want to make a backup of your old files first though...)

[Yobbo]

Thanks!

[LoRd_MuldeR]

libx264 SVN-r1136:

libx264-r1136, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1136M-gcc433-core2-fprofiled.7z)
libx264-r1136, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1136M-gcc433-k8-fprofiled.7z)
libx264-r1136, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1136M-gcc433-pentium2-fprofiled.7z)
libx264-r1136, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1136M-gcc421-pentium2-fprofiled.7z)
libx264-r1136, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1136M-gcc345-pentium2-fprofiled.7z)

All builds are fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.

[fxtech]

good bye P3 legacy ! thank a lot for the core 2 opt version !

[LoRd_MuldeR]

good bye P3 legacy ! thank a lot for the core 2 opt version !

Just to make it clear:
1. The "Pentium 2" builds will run on any MMX capable processor (P2/K6 and later). x264 requires MMX anyway, if it was compiled on an MMX capable machine, which is the case here.
2. Don't expect too much from compiler optimizations! Anything above "-march=pentium2" only gives very minor speed-up, if at all. I'll make "Core 2" builds anyway to be sure.

[Pulstar]

Hello LoRd_MuldeR, is it possible to use AVIDemux to encode standard VCD2.0 videos? LAVC is a VBR lib so it cannot be used, and whenever I use MPEG2ENC it crashes the program. I tried using filters to predefince the proper height/width to no avail. Here's the log..

Looks like FRAME_NTSC
resize by x

New X x Y = 352 x 235

Resized to : 352 x 232, add black border 0 x 8**saving:**
Output format:4
MPEG family
[Bridge] Going to time 0
3gp Go to time succeeded chunk :0 time ask:0 time get:0
[Bridge] Starting with time 0, shift 0
[Bridge] Ending with time 0, sample 0
[Bridge] Going to time 0
3gp Go to time succeeded chunk :0 time ask:0 time get:0
[Bridge] Going to time 0
3gp Go to time succeeded chunk :0 time ask:0 time get:0
[Lavcodec] Creating Lavcodec
[Lavcodec]Incoming : fq : 44100, channel : 2 bitrate: 224
[Lavcodec]Lavcodec successfully initialized
X*CD: Using VCD PS

Using mpeg2enc encoder (VCD)
Detecting NTSC format
[mpeg2enc]Encoding MPEG-1 video
[mpeg2enc]Horizontal size: 352 pe
l[mpeg2enc]Vertical size: 240 pel
[mpeg2enc]Aspect ratio code: 12 = 1:1.1250 (4:3 NTSC for 720x480/352x240 images)
[mpeg2enc]Frame rate code: 4 = 30000.0/1001.0 (NTSC VIDEO)
[mpeg2enc]Bitrate: 1151 KBit/s
[mpeg2enc]Field order for input: none/progressive
[mpeg2enc]New Sequence every 790 Mbytes
[mpeg2enc]Assuming non-video stream of 230 Kbps
[mpeg2enc]Search radius: 16
Using default unmodified quantization matrices
[Mpeg2enc]Using MMX quant non intra
[Mpeg2enc]Enabling mmx motion search
[Mpeg2enc] MMXE motion
[Mpeg2enc] SSE idct/fdct
[Mpeg2enc] MMXE predict
opt->enc_height2 :240 opt->enc_width: 352 opt->enc_height2:240

Mpeg2enc Encoder , w: 352 h:240 mode:2Opening mplex muxer (C:\Documents and Settings\Pulstar\Desktop\p1.mpg)
PacketQueue Mplex audioQ created
PacketQueue Mplex videoQ created
mplex type is :1
creating slave thread
[Muxer Slave Thread] Creating job & muxer
output file created
Init ok
[AudioThread] Starting
[VideoThread] Starting
audio done (MP2), creating video bitstream

Any help would be appreciated :)

[LoRd_MuldeR]

Hello LoRd_MuldeR, is it possible to use AVIDemux to encode standard VCD2.0 videos?

What's wrong with the "Auto" -> "Video CD" wizard ???

LAVC is a VBR lib so it cannot be used

That statement doesn't make any sense to me...

[Pulstar]

It still crashes using the auto wizard after encoding a few frames. As for what I meant, Nero 8 complains that the video isn't encoded in 1050kbps CBR using LAVC (it uses a variable bitrate for encoding videos)

[LoRd_MuldeR]

When VBV is used the encoder will restrict the VBR encoding to the specified buffer size in order to ensure compatibility to hardware players.
So if you select the correct buffer size (40 KB for a Video-CD), you should get compatible stream...

[Brazil2]

How do you set psy_rd in Avidemux ? Is it even possible ?
It seems to be automatically used depending on the settings but I always end up with psy_rd=1.0:0.0 and I can't find a way to change this.

[LoRd_MuldeR]

How do you set psy_rd in Avidemux ? Is it even possible ?
It seems to be automatically used depending on the settings but I always end up with psy_rd=1.0:0.0 and I can't find a way to change this.

There is no option to change the Psy RDO and Psy Trellis settings in Avidemux yet. So the defaults will be used.
Anyway, if you lower subme to 5 (or even lower), then Psy RDO will be disabled, as Psy RDO requires subme 6 (or above).
If you build x264 yourself, you can easily change the defaults in x264_param_default() in "common\common.c".

[Brazil2]

OK, thanks for the information :)

[billqs]

Hey!

I use AviDemux to edit my Xvid and Divx encoded tv caps to remove commercials, etc.

Recently, I was using "showsqueeze" in BeyondTV and reset it to wmv mode instead of a Divx 5 encoded avi. I did this despite my dislike of M$ codecs because I had the option of deinterlacing upon reencode. (This option was not available for Divx in BeyondTV.

I loaded up a couple of wmv files and had the following problems:

1. Using a recent Avidemux 2.5 beta build from mid-March the program would just literally disappear when I hit play on the file (I imagine that it crashed, but no error messages or anything.)

2. Using Avidemux 2.44 final I could edit the file, remove commercials and make many filter adjustments to the video. However, after re-encoding the video to Vxid and the audio to mp3 (lame) for the final product, I had the edited video but the audio still had the commercial breaks included.

My first thought was that for some reason I had accidentally left the audio stream at copy, so I pulled up another wmv file, edited it down, reencoded both video and audio and the same error occurred.

After I got the error a second time, I pulled up an old avi file, edited it and encoded to Xvid and mp3 and it was perfect both video and audio.

I am running XP SP3 with a quadcore procecessor and 3Gig of RAM.

Does anyone have a suggestion?

[LoRd_MuldeR]

Probably Avidemux doesn't support WMA streams properly. I have no experience with WMV/WMA editing in Avidemux.

Try converting your WMV file to a more useful format before you do the editing in Avidemux...

BTW: I don't see how "deinterlacing" is related to your choice between MPEG-4 ASP (DivX) and WMV, as deinterlacing is pre-processing. It's not part of the encoding!

[LoRd_MuldeR]

libx264 SVN-r1137:

libx264-r1137, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1137M-gcc433-core2-fprofiled.7z)
libx264-r1137, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1137M-gcc433-k8-fprofiled.7z)
libx264-r1137, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1137M-gcc433-pentium2-fprofiled.7z)
libx264-r1137, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1137M-gcc421-pentium2-fprofiled.7z)
libx264-r1137, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1137M-gcc345-pentium2-fprofiled.7z)

All builds are fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.

[billqs]

Thanks for the idea Mulder. I'm going to do that and change the "showsqueeze" option in BeyondTV back to Divx since it makes for much easier editing.

BTW: I don't see how "deinterlacing" is related to your choice between MPEG-4 ASP (DivX) and WMV, as deinterlacing is pre-processing. It's not part of the encoding!

I'm aware it's preprocessing... it's just that Snapstream in their "infinite wisdom" made deinterlacing an option before re-encoding in wmv, but not in Divx. I had previously had issues fixing interlaced videos, particularly those with letterboxing so in my "inifinite wisdom (not)" I wanted to save a step and have all files of tv caps progressive both the divx, and ts files (which already are progressive as they are captured in 720p.)

Since what I have actually done is add a step rather than save a step, I am going back to Divx on the showsqueeze option. I would not use anything, but I have a couple of hundred Gigs in videos backed up waiting for me to process and I hate to see how huge the files would be if I had them all in glorious MPEG-2.

Thanks!

[LoRd_MuldeR]

Why you don't capture to some lossless format and then deinterlace with the deinterlacer of your choice and re-encode with the encoder of your choice?

[billqs]

Why you don't capture to some lossless format and then deinterlace with the deinterlacer of your choice and re-encode with the encoder of your choice?

Well, all three capture cards I own are hardware capture cards. Two capture to MPEG-2 and one captures to h.264. If I can clear the backlog of videos out, then I may stop all reencoding from within BeyondTV and then use MeGui, Ripbot or AviDemux to process and encode the video.

I know that I lose quality every time there is a reencode. I appreciate all your help!:)

[LoRd_MuldeR]

If you capture interlaced in MPEG-2 at high enough bitrate, the capture quality should be transparent (visually lossless).

Then you can do the further processing (deinterlacing, encoding, etc) in Avidemux, RipBot, MeGUI or whatever application you prefer for that step.

I used to capture at 15 MBit/s CBR with my analog MPEG-2 hardware encoder card...

[billqs]

Thanks, that's a really good suggestion!

[LoRd_MuldeR]

libx264 SVN-r1139:

libx264-r1139, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1139M-gcc433-core2-fprofiled.7z)
libx264-r1139, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1139M-gcc433-k8-fprofiled.7z)
libx264-r1139, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1139M-gcc433-pentium2-fprofiled.7z)
libx264-r1139, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1139M-gcc421-pentium2-fprofiled.7z)
libx264-r1139, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1139M-gcc345-pentium2-fprofiled.7z)

All builds are fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.

[Kurtnoise]

it seems that there is a small bug in the OCR Tool (TS -> srt) using the latest windows build (rev4685). When you open a TS file, it's not opendialog event but savedialog event which is used...

[LoRd_MuldeR]

libx264 SVN-r1140:

libx264-r1140, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1140M-gcc433-core2-fprofiled.7z)
libx264-r1140, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1140M-gcc433-k8-fprofiled.7z)
libx264-r1140, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1140M-gcc433-pentium2-fprofiled.7z)
libx264-r1140, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1140M-gcc421-pentium2-fprofiled.7z)
libx264-r1140, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1140M-gcc345-pentium2-fprofiled.7z)

All builds are fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.

[Jalavera]

it seems that there is a small bug in the OCR Tool (TS -> srt) using the latest windows build (rev4685). When you open a TS file, it's not opendialog event but savedialog event which is used...

Yes, it also happens in ALL previous 2.x svn Qt versions. In order to have a correct opendialogbox is needed to install latest 2.4.4 stable with GTK+ versions (Qt version also fails).
Please check new 2.5.x Qt-only versions...

[LoRd_MuldeR]

Yes, it also happens in ALL previous 2.x svn Qt versions. In order to have a correct opendialogbox is needed to install latest 2.4.4 stable with GTK+ versions (Qt version also fails).
Please check new 2.5.x Qt-only versions...

You may want to file a bugreport (http://bugs.avidemux.org/) then ;)

[Jalavera]

Ok. Done & wait...
:thanks:

[LoRd_MuldeR]

libx264 SVN-r1143:

libx264-r1143, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1143M-gcc433-core2-fprofiled.7z)
libx264-r1143, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1143M-gcc433-k8-fprofiled.7z)
libx264-r1143, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1143M-gcc433-pentium2-fprofiled.7z)
libx264-r1143, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1143M-gcc421-pentium2-fprofiled.7z)
libx264-r1143, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1143M-gcc345-pentium2-fprofiled.7z)

All builds are fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.

[LoRd_MuldeR]

Avidemux 2.5 SVN-r4741 (2009-04-20)
http://www.avidemux.org/

Revision 4741 (20 Apr 2009)
# Updated GLib to version 2.20.1-1.
# Updated GTK+ to version 2.16.1-1.
# Updated Pango to version 1.24.0-1.

4741 - [script] change PSP auto wizard to check appropriateness of target audio track
4740 - [script] add AudioTrackInfo class and sourceTrackInfo/targetTrackInfo properties to Audio class
4739 - [ocr] use open dialog instead of save dialog (FS#599)
4721 - [ffmpeg] update FFmpeg to r18300 & libswscale r29120
4688 - [script] only apply resize filter when necessary when using scripted auto wizard
4687 - [script] clean up naming of methods & props for audio object
4686 - [script] make video & audio methods return null when no video is open
4685 - [Win32] update installer to install system scripts

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

Avidemux 2.5 SVN-r4758 (2009-04-22)
http://www.avidemux.org/

Revision 4758 (22 Apr 2009)
# Updated Avisynth Proxy GUI to version 2.08.
# Updated x264 to r1145.

4758 - [x264] support core 67
4757 - [rgb] use SWS_ACCURATE_RND to temporarily fix broken swscale RGB conversion
4756 - [cmake] use ffmpeg tarball first if available otherwise svn
4755 - [cmake] move svn retrieval of ffmpeg to separate script
4754 - [cmake] move patching of ffmpeg to separate script
4746 - [src] update Secret Rabbit Code to 0.1.7 for speed improvements
4745 - [auto] add more device auto wizards
4744 - [qt] use complete base name for auto wizards so full stops are handled in name
4743 - [x264] add additional device presets
4742 - [x264/xvid] use complete base name of xml config file so full stops are handled in name

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1145:

libx264-r1145, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-core2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-k8-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-pentium2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc421-pentium2-fprofiled.7z)
libx264-r1145, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc345-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4 any longer. Please update to Avidemux 2.5 SVN-r4758 (http://forum.doom9.org/showpost.php?p=1276998&postcount=1118) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.

[fxtech]

4758 - [x264] support core 67

Hi lord , there is a reason for the change of the name on the last x264 dll ? them are libx264-67 instead 66 , and have to be renamed to work with the last build

[LoRd_MuldeR]

4758 - [x264] support core 67

Hi lord , there is a reason for the change of the name on the last x264 dll ? them are libx264-67 instead 66 , and have to be renamed to work with the last build

Yes, there is a reason! The API of x264 has changed once again and therefore it's now core-67 instead of core-66. Consequently the filename now is "libx264-67.dll" instead of "libx264-66.dll". In fact this change in the x264 API was long ago. Unfortunately Avidemux was not updated for that change. Hence I had to patch x264 in order to make it work with existing Avidemux builds. But yesterday Gruntster finally updated Avidemux to support x264 core-67. So I don't need to patch x264 any longer. From now on I will simply build x264 core-67 as-is. Thus all new builds of libx264 will require a recent build of Avidemux. You need Avidemux 2.5 SVN-r4758 or later. And be warned that renaming the "libx264-67.dll" to "libx264-66.dll" will NOT work with older Avidemux builds! Different x264 core versions have different filenames for a reason...

[fxtech]

right i did not see also the svn revision build , i was using the 4741 , thx a lot

[Pulstar]

Hello it's me again. I've abandoned the concept of using VCD and now switched to WMV to distribute videos (less hassles this way, just load 'em in WMP and go!).. Btw I need a way to load and run a job file (generated using the GUI) in AVIDemux automatically. Is there a switch in AVIDemux CLI that supports this?

Edit - Another question.. When it comes to encoding HuffYUV video (ffmpeg, adaptive) postproc isn't really needed is it?

[LoRd_MuldeR]

Hello it's me again. I've abandoned the concept of using VCD and now switched to WMV to distribute videos (less hassles this way, just load 'em in WMP and go!).. Btw I need a way to load and run a job file (generated using the GUI) in AVIDemux automatically. Is there a switch in AVIDemux CLI that supports this?

See the Avidemux Wiki:
http://avidemux.org/admWiki/index.php?title=Command_line_usage

Edit - Another question.. When it comes to encoding HuffYUV video (ffmpeg, adaptive) postproc isn't really needed is it?

If you are encoding from a lossy source, then postprocessing can be used to reduce blocking and ringing - at the cost of reduced sharpness.

This doesn't change at all, if you are encoding to a lossless format, such as HuffYUV.

Even if you are encoding from a lossless source, there still may be blocking/ringing in the video, if the video originally came from some lossy format.

(Just because a video is stored in a lossless format the content isn't necessarily of good quality)

[Schrade]

libx264 SVN-r1145:

libx264-r1145, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-core2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-k8-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-pentium2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc421-pentium2-fprofiled.7z)
libx264-r1145, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc345-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4 any longer. Please update to Avidemux 2.5 SVN-r4758 (http://forum.doom9.org/showpost.php?p=1276998&postcount=1118) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.

LoRd_MuldeR, what's the difference between the GCC 4.3.3, 4.2.1 and 3.4.5 builds? (Other than compiler used..) Is it for speed reasons?

[LoRd_MuldeR]

LoRd_MuldeR, what's the difference between the GCC 4.3.3, 4.2.1 and 3.4.5 builds? (Other than compiler used..) Is it for speed reasons?

The GCC 4.3.3 builds should be the preferred ones, as that's the current GCC series. Well, there's GCC 4.4.0 now, but no MinGW build yet.

Anyway, in the past we had crashes in x264 that obviously were caused by miscompliation. So I make builds with older GCC versions too, as these should be more stable.

So if you encounter any problems with my GCC 4.3.3 builds, please try the GCC 4.2.1 or GCC 3.4.5 builds and report back...

[Schrade]

Aha.. thanks. Yeah, I've had crashes in the past. Will keep this in mind.

[Pulstar]

See the Avidemux Wiki:
http://avidemux.org/admWiki/index.php?title=Command_line_usage

If you are encoding from a lossy source, then postprocessing can be used to reduce blocking and ringing - at the cost of reduced sharpness.

This doesn't change at all, if you are encoding to a lossless format, such as HuffYUV.

Even if you are encoding from a lossless source, there still may be blocking/ringing in the video, if the video originally came from some lossy format.

(Just because a video is stored in a lossless format the content isn't necessarily of good quality)

Thanks.. my source is analogue so postproc makes it smoother than absolutely needed. I wish I could get MPEG4 to look as sharp as MPEG2. Can you please recommend any quant. matrices for PAL VHS material?

Oh and I get GUI bugs like this one when using AVIDemux 2.5
http://img24.imageshack.us/img24/9156/image5dom.png

GTK works better on my WinXP SP3 computers.. Is there a way to fix this? Unlike GTK I think QT comes built-in with the runtimes :confused:

[LoRd_MuldeR]

Thanks.. my source is analogue so postproc makes it smoother than absolutely needed.

Post-processing only makes sense for over-compressed sources that have a lot of ugly blocking/ringing in them...

I wish I could get MPEG4 to look as sharp as MPEG2.

There is NO reason why MPEG-4 should look less sharp than MPEG-2. In fact MPEG-4 compresses much more efficient than MPEG-2. Consequently at the same bitrate you should get significant better quality (better detail retention) with MPEG-4. As an alternative, MPEG-4 AVC (x264) compresses even more efficient than MPEG-4 ASP (Xvid).

Also: Please make sure that you are looking at the unprocessed(!) MPEG-4 video, when you compare the "sharpness" of MPEG-4 to MPEG-2. Many MPEG-4 decoders (e.g. the Xvid decoder filter, the DivX decoder filter and even ffdshow) have built-in "post-processing" filters. These will sacrifice sharpness for deblocking and derininging. Hence you must disable these filters for a proper comparision!

Last but not least you must be aware that any re-encoding from a lossy format to a lossy format will unavoidably cause a quality degradation of some degree...

Can you please recommend any quant. matrices for PAL VHS material?

No, I can't. But generally the "MPEG" quantization should be more sharp (and more prone to blocking) than the "H.263" quantization.
Custom quant matrices can be used for MPEG quantization only...

Some CQM's for MPEG-4 ASP can be found here:
http://forum.doom9.org/showthread.php?s=&threadid=83125

Oh and I get GUI bugs like this one when using AVIDemux 2.5 ... Is there a way to fix this?

I can reproduce this (very minor) glitch. You may want to file a bug report (http://bugs.avidemux.org/), if it annoys you ;)

Unlike GTK I think QT comes built-in with the runtimes :confused:

No idea what that is supposed to mean :confused:

[LoRd_MuldeR]

Avidemux 2.5 SVN-r4763 (2009-04-26)
http://www.avidemux.org/

Revision 4763 (26 Apr 2009)
# Added Netscape Portable Runtime version 4.7.4.
# Updated Pango to version 1.24.1-1.
# Updated Qt to version 4.5.1.
# Updated SpiderMonkey to version 1.7.0.

4763 - [Win32] update Win32 build scripts and installer to use own SpiderMonkey
4762 - [script] add option to use system version of SpiderMonkey
4761 - [script] revert part of r4760
4760 - [script] output new property names in scripts
4759 - [js] remove pointless resolving of path for include scripts
4758 - [x264] support core 67

libx264 SVN-r1145:

libx264-r1145, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-core2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-k8-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-pentium2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc421-pentium2-fprofiled.7z)
libx264-r1145, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc345-pentium2-fprofiled.7z)

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1145:

libx264-r1145, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc440-core2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc440-amdfam10-fprofiled.7z)
libx264-r1145, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc440-pentium2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-core2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-amdfam10-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-pentium2-fprofiled.7z)
libx264-r1145, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc345-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4 any longer. Please update to Avidemux 2.5 SVN-r4758 (http://forum.doom9.org/showpost.php?p=1276998&postcount=1118) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.

[Yobbo]

There's no "Auto - DVD" preset anymore?

[LoRd_MuldeR]

There is an overhaul going on for the "Auto" menu currently...

[Yobbo]

Thanks a lot, Lord Mulder. I'm looking forward to the next milestone build. I appreciate all the work you do to make this excellent software accessible to us lay folk!

[roozhou]

@MuldeR
Maybe an off-topic question.
I noticed you are providing tdm 4.4.0 libx264 builds, but I have problem compiling x264 with tdm 4.4.0 from git. Configure failed and returned ./configure: line 320: die: command not found

There are no such problems using GCC 3.4.5/4.3.3/4.2.4. And configuring with 4.3.3 and compiling with 4.4.0 also works fine. Have you encountered such problem?

There is also problem compiling mplayer/mencoder with tdm 4.4.0, but this is far more off-topic.

[LoRd_MuldeR]

I noticed you are providing tdm 4.4.0 libx264 builds, but I have problem compiling x264 with tdm 4.4.0 from git. Configure failed

Try this patch:
http://mplayer.somestuff.org/misc/libx264/patches/configure-gcc440-fix.diff

More info here:
http://forum.doom9.org/showpost.php?p=1279759&postcount=534

There is also problem compiling mplayer/mencoder with tdm 4.4.0, but this is far more off-topic.

Apparently Sherpya is using GCC 4.5.0 for his MPlayer/MEncoder builds. But he doesn't provide his GCC 4.5.0 binaries (unless I missed something).

[fxtech]

anyone noticed that since the last svn all the custom script stop to work ? all of the give an interpreter error from the spidermonkey engine , also the conversion on mpeg4 asp using lavc on mp4 mov container becoming unreadable

[LoRd_MuldeR]

My custom scripts still work. For example I use scripts to load my x264 configuration and this works like a charm in latest SVN version.

So there must be some specific problem with your script...

[fxtech]

could you paste it here please ?

[LoRd_MuldeR]

Here we go:
http://pastie.org/469980

[fxtech]

i have to investigate

http://i39.tinypic.com/nxvmog.jpg

avidemux 2.5.0 svn 4762 just installed i am using the QT gui

[LoRd_MuldeR]

You must open a video first before you execute that script. That script will only setup the video encoder, it doesn't open any video ;)

(It's probably not the best idea to post huge screenshots. You may post a thumbnail or a hyperlink to the full-size image instead)

[fxtech]

It works !!!

[LoRd_MuldeR]

libx264 SVN-r1148:

libx264-r1148, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc440-core2-fprofiled.7z)
libx264-r1148, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc440-amdfam10-fprofiled.7z)
libx264-r1148, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc440-pentium2-fprofiled.7z)

libx264-r1148, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc433-core2-fprofiled.7z)
libx264-r1148, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc433-amdfam10-fprofiled.7z)
libx264-r1148, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc433-pentium2-fprofiled.7z)

libx264-r1148, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc421-pentium2-fprofiled.7z)
libx264-r1148, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc345-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4763 (http://forum.doom9.org/showpost.php?p=1278405&postcount=1130) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.

[LoRd_MuldeR]

libx264 SVN-r1148 using experimental AutoVAQ patch v0.2 by BugMaster:

libx264-r1148, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1148M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1148, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1148M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1148, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1148M-autovaq-gcc440-pentium2-fprofiled.7z)

libx264-r1148, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1148M-autovaq-gcc433-core2-fprofiled.7z)
libx264-r1148, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1148M-autovaq-gcc433-amdfam10-fprofiled.7z)
libx264-r1148, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1148M-autovaq-gcc433-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4763 (http://forum.doom9.org/showpost.php?p=1278405&postcount=1130) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster's patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Again using the "force_align_arg_pointer" attribute to avoid crash, so only GCC 4.x builds this time.

[LoRd_MuldeR]

libx264 SVN-r1153:

libx264-r1153, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc440-core2-fprofiled.7z)
libx264-r1153, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc440-amdfam10-fprofiled.7z)
libx264-r1153, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc440-pentium2-fprofiled.7z)

libx264-r1153, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc433-core2-fprofiled.7z)
libx264-r1153, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc433-amdfam10-fprofiled.7z)
libx264-r1153, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc433-pentium2-fprofiled.7z)

libx264-r1153, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc421-pentium2-fprofiled.7z)
libx264-r1153, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1153 using experimental AutoVAQ patch v0.2 by BugMaster:

libx264-r1153, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1153M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1153, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1153M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1153, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1153M-autovaq-gcc440-pentium2-fprofiled.7z)

libx264-r1153, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1153M-autovaq-gcc433-core2-fprofiled.7z)
libx264-r1153, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1153M-autovaq-gcc433-amdfam10-fprofiled.7z)
libx264-r1153, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1153M-autovaq-gcc433-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4763 (http://forum.doom9.org/showpost.php?p=1278405&postcount=1130) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster's patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the "force_align_arg_pointer" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.

[Inspector.Gadget]

LoRd_MuldeR,

I've found a bug in rev 4763 when opening a VOB file directly. The source is 16:9 NTSC (Region 1) Aqua Teen Hunger Force Season 6 Disc 2. Included below is an image showing the problem and a link to a 10-second sample cut with Avidemux. Hopefully you can reproduce the problem. The same file is fine in DGIndex and MPC-HC. If it is of any relevance, the problem persists throughout the file; the top fields are garbled but the bottom fields seem to decode correctly.

http://i39.tinypic.com/11jvhwi.jpg

Problem.vob (12.6 MB, ~10 seconds): http://www.mediafire.com/?sharekey=971922f6b4415a77d956df2962098fcbe04e75f6e8ebb871

:thanks:

Edit: I thought this might have been a problem with starting on a P-frame rather than an I-frame (unless Avidemux's frame type detection is wrong), but it persists for numerous GOPs.

Edit #2: This only happens when I don't choose to append all the VOB files in the program chain - Avidemux thinks VTS_01_1.VOB (the problematic file) starts with a P frame when opened on its own, but when I append the rest of the VTS_01_X.VOB files, Avidemux correctly begins on an I-frame and the problem disappears. Any idea what's going on here? So far as I know the missing I frame can't be in the second or third VOB...

[LoRd_MuldeR]

I can't see any problems with your sample, except that there are a few garbled blocks in the very first frames (1 to 7). But these are present in MPlayer and MPC+ffdshow as well!

http://img193.imageshack.us/img193/8100/vobgarbled.th.png (http://img193.imageshack.us/img193/8100/vobgarbled.png)

So it's not an Avidemux problem. The rest of the clip looks 100% fine for me. This is with Avidemux 2.5 r4763.

[Inspector.Gadget]

Yes, unfortunately upon a second look the sample does not have the same problem as the stream I cut it from using Avidemux. I don't know why this happened, as I made sure to begin with the first frame rather than the first keyframe. Here are two screenshots I've taken that may help illustrate this problem.

In this first screenshot, I opened VTS_01_1.VOB, declined to append the rest of the VOBs at the prompt, and wound up starting on a P-frame: hence the garbled image.
http://img190.imageshack.us/img190/8716/singlevobproblem.th.png (http://img190.imageshack.us/my.php?image=singlevobproblem.png)


In this second screenshot, I opened VTS_01_1.VOB, allowed Avidemux to append the rest of the VOBs, and everything was fine: the stream started on an I-frame.
http://img190.imageshack.us/img190/8427/multiplevobnoproblem.th.png (http://img190.imageshack.us/my.php?image=multiplevobnoproblem.png)


But shouldn't the first frame in a given VOB be the same anyway if it's alone or the first in a sequence? I know that VTS_01_0.VOB was not prepended to the others in the second case.

[LoRd_MuldeR]

But shouldn't the first frame in a given VOB be the same anyway if it's alone or the first in a sequence? I know that VTS_01_0.VOB was not prepended to the others in the second case.

It should, yes. Maybe you should open a topic in the Avidemux forum and provide a sample that can reproduce your problem...

[LoRd_MuldeR]

libx264 SVN-r1158:

libx264-r1158, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1158M-gcc440-core2-fprofiled.7z)
libx264-r1158, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1158M-gcc440-amdfam10-fprofiled.7z)
libx264-r1158, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1158M-gcc440-pentium2-fprofiled.7z)

libx264-r1158, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1158M-gcc433-core2-fprofiled.7z)
libx264-r1158, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1158M-gcc433-amdfam10-fprofiled.7z)
libx264-r1158, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1158M-gcc433-pentium2-fprofiled.7z)

libx264-r1158, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1158M-gcc421-pentium2-fprofiled.7z)
libx264-r1158, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1158M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1158 using experimental AutoVAQ patch v0.2 by BugMaster:

libx264-r1158, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1158M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1158, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1158M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1158, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1158M-autovaq-gcc440-pentium2-fprofiled.7z)

libx264-r1158, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1158M-autovaq-gcc433-core2-fprofiled.7z)
libx264-r1158, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1158M-autovaq-gcc433-amdfam10-fprofiled.7z)
libx264-r1158, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1158M-autovaq-gcc433-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4763 (http://forum.doom9.org/showpost.php?p=1278405&postcount=1130) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster's patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the "force_align_arg_pointer" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.

[Inspector.Gadget]

It should, yes. Maybe you should open a topic in the Avidemux forum and provide a sample that can reproduce your problem...

OK, I'll do that. Thanks for your patience; I'm not sure why the sample didn't work but maybe it's a related issue with MPEG-2 parsing :confused:

[LoRd_MuldeR]

Avidemux 2.5 SVN-r4871 (2009-05-25)
http://www.avidemux.org/

Revision 4871 (25 May 2009)
# Updated x264 to r1159.

4871 - [ffmpeg] update FFmpeg to r18940 & libswscale r29319
4868 - [Build] fix fix patch name
4867 - [Build] fix patch name
4866 - [ffmpeg] keep original ffmpeg library names on Windows
4850 - [Renderer] Fix xv output
4849 - [audio] Decoded DTS Header to update #of channels
4848 - [ffmpeg] change libxxx to libADM5xxx to avoid clash with system libs
4767 - [I18n] Add tw translation (ziyawu@xxxx.com) and bulgarian (LFU project team)
4766 - [x264] always return flag after creating header
4763 - [Win32] update Win32 build scripts and installer to use own SpiderMonkey

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1162:

libx264-r1162, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1162M-gcc440-core2-fprofiled.7z)
libx264-r1162, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1162M-gcc440-amdfam10-fprofiled.7z)
libx264-r1162, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1162M-gcc440-pentium2-fprofiled.7z)

libx264-r1162, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1162M-gcc433-core2-fprofiled.7z)
libx264-r1162, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1162M-gcc433-amdfam10-fprofiled.7z)
libx264-r1162, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1162M-gcc433-pentium2-fprofiled.7z)

libx264-r1162, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1162M-gcc421-pentium2-fprofiled.7z)
libx264-r1162, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1162M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1162 using experimental AutoVAQ patch v0.2 by BugMaster:

libx264-r1162, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1162M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1162, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1162M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1162, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1162M-autovaq-gcc440-pentium2-fprofiled.7z)

libx264-r1162, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1162M-autovaq-gcc433-core2-fprofiled.7z)
libx264-r1162, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1162M-autovaq-gcc433-amdfam10-fprofiled.7z)
libx264-r1162, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1162M-autovaq-gcc433-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4871 (http://forum.doom9.org/showpost.php?p=1289938&postcount=1153) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster's patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the "force_align_arg_pointer" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.

[LoRd_MuldeR]

libx264 SVN-r1165:

libx264-r1165, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1165M-gcc440-core2-fprofiled.7z)
libx264-r1165, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1165M-gcc440-amdfam10-fprofiled.7z)
libx264-r1165, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1165M-gcc440-pentium2-fprofiled.7z)

libx264-r1165, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1165M-gcc433-core2-fprofiled.7z)
libx264-r1165, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1165M-gcc433-amdfam10-fprofiled.7z)
libx264-r1165, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1165M-gcc433-pentium2-fprofiled.7z)

libx264-r1165, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1165M-gcc421-pentium2-fprofiled.7z)
libx264-r1165, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1165M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1165 using experimental AutoVAQ patch v0.2 by BugMaster:

libx264-r1165, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1165M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1165, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1165M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1165, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1165M-autovaq-gcc440-pentium2-fprofiled.7z)

libx264-r1165, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1165M-autovaq-gcc433-core2-fprofiled.7z)
libx264-r1165, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1165M-autovaq-gcc433-amdfam10-fprofiled.7z)
libx264-r1165, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1165M-autovaq-gcc433-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4871 (http://forum.doom9.org/showpost.php?p=1289938&postcount=1153) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster's patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the "force_align_arg_pointer" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.

[LoRd_MuldeR]

libx264 SVN-r1169:

libx264-r1169, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1169M-gcc440-core2-fprofiled.7z)
libx264-r1169, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1169M-gcc440-amdfam10-fprofiled.7z)
libx264-r1169, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1169M-gcc440-pentium2-fprofiled.7z)

libx264-r1169, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1169M-gcc421-pentium2-fprofiled.7z)
libx264-r1169, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1169M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1169 using experimental AutoVAQ patch v0.2 by BugMaster:

libx264-r1169, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1169M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1169, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1169M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1169, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1169M-autovaq-gcc440-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4871 (http://forum.doom9.org/showpost.php?p=1289938&postcount=1153) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster's patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the "force_align_arg_pointer" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.

[LoRd_MuldeR]

libx264 SVN-r1171:

libx264-r1171, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1171M-gcc440-core2-fprofiled.7z)
libx264-r1171, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1171M-gcc440-amdfam10-fprofiled.7z)
libx264-r1171, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1171M-gcc440-pentium2-fprofiled.7z)

libx264-r1171, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1171M-gcc421-pentium2-fprofiled.7z)
libx264-r1171, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1171M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1171 using experimental AutoVAQ patch v0.2 by BugMaster:

libx264-r1171, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1171M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1171, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1171M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1171, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1171M-autovaq-gcc440-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4871 (http://forum.doom9.org/showpost.php?p=1289938&postcount=1153) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster's patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the "force_align_arg_pointer" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.

[LoRd_MuldeR]

libx264 SVN-r1171 using experimental AutoVAQ patch v0.3 by BugMaster:

libx264-r1171, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1171M-autovaq-gcc440-core2-fprofiled.new.7z)
libx264-r1171, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1171M-autovaq-gcc440-amdfam10-fprofiled.new.7z)
libx264-r1171, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1171M-autovaq-gcc440-pentium2-fprofiled.new.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4871 (http://forum.doom9.org/showpost.php?p=1289938&postcount=1153) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster's patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the "force_align_arg_pointer" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.

[Brazil2]

It seems that AviDemux 2.5 has been released even though the web sites haven't been updated yet:

http://sourceforge.net/project/showfiles.php?group_id=67275

But no ZIP file available, unfortunately :confused:

[lych_necross]

Patience Brazil2. It takes time to compile new releases and update websites (not to mention dealing with real life) :)

[LoRd_MuldeR]

Patience Brazil2. It takes time to compile new releases and update websites (not to mention dealing with real life) :)

It's not like Avidemux 2.5 was anything new. Builds of the Avidemux 2.5 branch have been provided (and should be preferred) for quite some time now!

And since the latest Win32 build available from Gruntster's site (r4871) exactly nothing of importance has changed in the 2.5 tree :p

Look at the SVN log:
http://svn.berlios.de/wsvn/avidemux/branches/avidemux_2.5_branch_gruntster/?op=log

[LoRd_MuldeR]

libx264 SVN-r1173:

libx264-r1173, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1173M-gcc440-core2-fprofiled.7z)
libx264-r1173, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1173M-gcc440-amdfam10-fprofiled.7z)
libx264-r1173, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1173M-gcc440-pentium2-fprofiled.7z)

libx264-r1173, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1173M-gcc421-pentium2-fprofiled.7z)
libx264-r1173, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1173M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1173 using experimental AutoVAQ patch v0.3 by BugMaster:

libx264-r1173, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1173M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1173, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1173M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1173, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1173M-autovaq-gcc440-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4871 (http://forum.doom9.org/showpost.php?p=1289938&postcount=1153) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster's patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the "force_align_arg_pointer" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.

[Schrade]

Just as a note, Gruntster's site (http://avidemux.razorbyte.com.au/) lists revision 4494 as the 2.5 final. It's actually 4944. Confused me for a sec until I read the Windows Package Notes (http://avidemux.razorbyte.com.au/binaries/2.5/SVN/Package%20Notes.html) link.

[LoRd_MuldeR]

Just as a note, Gruntster's site (http://avidemux.razorbyte.com.au/) lists revision 4494 as the 2.5 final. It's actually 4944. Confused me for a sec until I read the Windows Package Notes (http://avidemux.razorbyte.com.au/binaries/2.5/SVN/Package%20Notes.html) link.

That was a typo indeed. r4494 would be older than the previous 2.4.4 Milestone release :p

[LoRd_MuldeR]

Avidemux 2.5 SVN-r4968 (2009-06-27)
http://www.avidemux.org/

Revision 4968 (27 Jun 2009)
# Updated ATK to version 1.26.0-1.
# Updated GLib to version 2.20.3-1.
# Updated GTK+ to version 2.16.2-1.
# Updated libpng to version 1.2.37-1.
# Updated Ogg to version 1.1.4.
# Updated Pango to version 1.24.2-1.
# Updated Qt to version 4.5.2.
# Updated Vorbis to version 1.2.2.
# Updated x264 to r1173.

4968 - [ffmpeg] update FFmpeg to r19285 & libswscale r29406
4962 - [automation] Also use the couple int %d for sscanf, cast later
4961 - [QT4] Maybe fix build on some linux variant
4945 - [po] traditional chinese update by Dong-Jun Wu
4943 - [ffmpeg] ffmpeg tarballs
4876 - [PO] Take also strings from plugin
4871 - [ffmpeg] update FFmpeg to r18940 & libswscale r29319

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[Brazil2]

Where can I find documentation about the use of the Video Usability Information options in the Output tab of the x264 Configuration of the new Avidemux 2.5 ?

[LoRd_MuldeR]

I think these options are just hints for the playback device. Not something that actually effects the encoding. Some info here:

http://mulder.dummwiedeutsch.de/pub/x264/

[Brazil2]

I think these options are just hints for the playback device. Not something that actually effects the encoding. Some info here:

http://mulder.dummwiedeutsch.de/pub/x264/
That's a nice guide, thanks for that :)

Unfortunately it doesn't give explanations about the use of the Video Usability Information options...

[LoRd_MuldeR]

Unfortunately it doesn't give explanations about the use of the Video Usability Information options...

That's because I have nothing to say about them, except that these options are information that will be forwarded to the playback equipment.

It depend on the playback equipment whether the "Video Usability Information" will be evaluated or ignored...

[lansing]

a small bug:

http://img38.imageshack.us/img38/4113/bugpro.jpg

[LoRd_MuldeR]

Avidemux 2.5 SVN-r4992 (2009-07-04)
http://www.avidemux.org/

Revision 4992 (03 Jul 2009)
# Updated FAAC to version 1.28.
# Updated FAAD2 to version 2.7.

4992 - [win32] update installer to include avcodec video encoder plugin
4991 - [vidEnc] remove more remnants of old encoders
4990 - [vidEnc] remove old encoders that have plugin equivalents
4988 - [script] fix rendering of scanVbr function to file
4987 - [vidEnc] DV plugin (also supports more profiles)
4984 - [vidEnc] ffvhuff and ffv1 plugins
4983 - [vidEnc] fix loading of multiple encoders in the one plugin
4982 - [huffyuv] huffyuv plugin
4976 - [vidEnc] always use extra data from plugin (let plugin decide when to generate)
4968 - [ffmpeg] update FFmpeg to r19285 & libswscale r29406

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

Avidemux 2.5 SVN-r4997 (2009-07-05)
http://www.avidemux.org/

Revision 4997 (05 Jul 2009)
# Updated FAAC to version 1.28.
# Updated FAAD2 to version 2.7.

4997 - [muxer] prevent crash when audio isn't appropriate for MPEG muxer
4996 - [ffmpeg] oops, actually enable valid encoders
4995 - [dlgFactory] fix sizing of bitrate control
4994 - [x264] fix loading of Auto idc level setting
4993 - [vidEnc] more cleanup
4992 - [win32] update installer to include avcodec video encoder plugin

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[lych_necross]

I'm having a problem with r4997. Everytime I click on 'Help' then Plugins, the program crashes. Other than that, everything seems to work fine. I do have the DTS/AMR addon installed btw.

[boyumeow]

I m getting the same thing with r4992 too, but the program just shut down without any error window pop-up report. Thanks.

Note: quote from my admlog.txt which produce errors in my case.
...
[ADM_ae_plugin] Scanning done
[ADM_ad_plugin] Scanning directory C:\Users\Boyumeow\AppData\Roaming\avidemux\plugins\audioDecoder\
[ADM_ad_plugin] Cannot parse plugin
[ADM_vf_plugin] Scanning directory C:\Users\Boyumeow\AppData\Roaming\avidemux\plugins\videoFilter\
[ADM_vf_plugin] Cannot parse plugin
[ADM_vidEnc_plugin] Scanning directory D:\Program Files\Avidemux 2.5\plugins\videoEncoder\
ignored: x264
ignored: xvid
...
[Locale] Locale: en_US
[Locale] Loading language file D:/Program Files/Avidemux 2.5/i18n/qt_en_US FAILED
[Locale] Loading language file D:/Program Files/Avidemux 2.5/i18n/avidemux_en_US FAILED
[Locale] Test: &Edit -> &Edit
...

[LoRd_MuldeR]

I'm having a problem with r4997. Everytime I click on 'Help' then Plugins, the program crashes. Other than that, everything seems to work fine. I do have the DTS/AMR addon installed btw.

You have a much better chance to get this fixed by reporting it at the Avidemux forums (http://avidemux.org/admForum/viewforum.php?id=18) ;)

Workaround: Don't goto Help -> Plugins :p

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5010 (2009-07-06)
http://www.avidemux.org/

Revision 5010 (06 Jul 2009)
# Updated FAAC to version 1.28.
# Updated FAAD2 to version 2.7.

5010 - [filter] format filter parameters correctly on 64bit
5009 - [vidEnc] use a safer way of discriminating encoders in avcodec encoder plugin
5005 - [vidEnc] pass valid encoderId when querying for plugin description
5004 - [ffmpeg] enable runtime cpu detection
5003 - [ffmpeg] filter log messages
5000 - [ffmpeg] fix ffmpeg logging
4999 - [scale] only use one scaling method with swscale
4998 - [ffmpeg] enable rawvideo decoder
4997 - [muxer] prevent crash when audio isn't appropriate for MPEG muxer

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[lych_necross]

You have a much better chance to get this fixed by reporting it at the Avidemux forums (http://avidemux.org/admForum/viewforum.php?id=18) ;)

Workaround: Don't goto Help -> Plugins :p
Noted for future reference. Version R5010 fixes the plugin menu problem.

[LoRd_MuldeR]

libx264 SVN-r1178:

libx264-r1178, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1178M-gcc440-core2-fprofiled.7z)
libx264-r1178, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1178M-gcc440-amdfam10-fprofiled.7z)
libx264-r1178, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1178M-gcc440-pentium2-fprofiled.7z)

libx264-r1178, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1178M-gcc421-pentium2-fprofiled.7z)
libx264-r1178, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1178M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1178 using experimental AutoVAQ patch v0.3 by BugMaster:

libx264-r1178, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1178M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1178, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1178M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1178, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1178M-autovaq-gcc440-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4871 (http://forum.doom9.org/showpost.php?p=1289938&postcount=1153) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster's patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the "force_align_arg_pointer" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.

Note: Until Avidemux is updated to core-68, you will need to rename "libx264-68.dll" to "libx264-67.dll" as a temporary workaround.
This single time renaming the DLL is allowed, because the API didn't really change between 67 and 68. As far as I can tell...

[Dark Shikari]

libx264 SVN-r1178:

libx264-r1178, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1178M-gcc440-core2-fprofiled.7z)
libx264-r1178, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1178M-gcc440-amdfam10-fprofiled.7z)
libx264-r1178, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1178M-gcc440-pentium2-fprofiled.7z)

libx264-r1178, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1178M-gcc421-pentium2-fprofiled.7z)
libx264-r1178, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1178M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1178 using experimental AutoVAQ patch v0.3 by BugMaster:

libx264-r1178, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1178M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1178, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1178M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1178, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1178M-autovaq-gcc440-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4871 (http://forum.doom9.org/showpost.php?p=1289938&postcount=1153) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster's patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the "force_align_arg_pointer" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.

Note: Until Avidemux is updated to core-68, you will need to rename "libx264-68.dll" to "libx264-67.dll" as a temporary workaround.
This single time renaming the DLL is allowed, because the API didn't really change between 67 and 68. As far as I can tell...The API changed (the defaults changed), but the ABI did not change.

[LoRd_MuldeR]

libx264 SVN-r1179:

libx264-r1179, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1179M-gcc440-core2-fprofiled.7z)
libx264-r1179, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1179M-gcc440-amdfam10-fprofiled.7z)
libx264-r1179, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1179M-gcc440-pentium2-fprofiled.7z)

libx264-r1179, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1179M-gcc421-pentium2-fprofiled.7z)
libx264-r1179, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1179M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1179 using experimental AutoVAQ patch v0.3 by BugMaster:

libx264-r1179, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1179M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1179, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1179M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1179, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1179M-autovaq-gcc440-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4871 (http://forum.doom9.org/showpost.php?p=1289938&postcount=1153) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster's patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the "force_align_arg_pointer" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.

Note: Until Avidemux is updated to core-68, you will need to rename "libx264-68.dll" to "libx264-67.dll" as a temporary workaround.
This single time renaming the DLL is allowed, because the ABI didn't change between core-67 and core-68.

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5031 (2009-07-10)
http://www.avidemux.org/

Revision 5031 (10 Jul 2009)
# Recompiled FAAC with MinGW's GCC 4.2.1-sjlj-2.
# Updated x264 to r1179.

5031 - [vidEnc] change video encoder API to include planes and strides of source frame (so each plugin doesn't need to calculate them)
5030 - [vidEnc] fix case of filename in MPEG-1 encoder plugin
5029 - [vidEnc] remove generation of config header file for avcodec plugin
5028 - [vidEnc] derived virtual functions don't get called in constructor
5027 - [vidEnc] MPEG-1 encoder plugin (incomplete)
5026 - [xvid] use generic options class
5025 - [x264] tidy up
5024 - [x264] update idc levels in config schema
5022 - [x264] remember encode mode for GTK+ interface
5021 - [x264] handle integer idc levels properly
5020 - [x264] use a more precise buffer size for decoded picture
5019 - [x264] interpret preset xml block and load appropriate config
5017 - [x264] use generic options class
5016 - [vidEnc] create a generic options class to handle most of the grunt work
5010 - [filter] format filter parameters correctly on 64bit

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1181:

libx264-r1181, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1181M-gcc440-core2-fprofiled.7z)
libx264-r1181, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1181M-gcc440-amdfam10-fprofiled.7z)
libx264-r1181, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1181M-gcc440-pentium2-fprofiled.7z)
libx264-r1181, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1181M-gcc421-pentium2-fprofiled.7z)
libx264-r1181, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1181M-gcc345-pentium2-fprofiled.7z)


libx264 SVN-r1181 using experimental AutoVAQ patch v0.3 by BugMaster:

libx264-r1181, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1181M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1181, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1181M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1181, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1181M-autovaq-gcc440-pentium2-fprofiled.7z)


These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5031 (http://forum.doom9.org/showpost.php?p=1304262&postcount=1181) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster's patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the "force_align_arg_pointer" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.

Note: Avidemux has been updated for x264 core-68. So do NOT rename the 'libx264-68.dll' file from now on. Use Avidemux r5031 instead !!!

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5065 (2009-07-12)
http://www.avidemux.org/

Revision 5065 (12 Jul 2009)
# Updated Vorbis to version 1.2.3.
# Updated x264 to r1181.

5065 - [win32] fix linking
5064 - [x264/Xvid] use button boxes on Qt config windows
5063 - [vidEnc] tidy up memory allocation for video encoder options
5050 - [bootStrap] Fix install path, have to specify twice
5049 - [BooStrap] Fix mixup
5046 - [vidEnc] Linux compilation fixes
5042 - [Build] Gcc 4.4 fixes by whaevr
5036 - [Patch] wrong include
5035 - [Patch] plf underlinking
5034 - [Patch] Plf format string patch
5033 - [Build] Bootstrap script
5032 - [Build Fix] Build fix for karmic koala + simple build script for main (not for plugins yet)

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5087 (2009-07-13)
http://www.avidemux.org/

Revision 5087 (13 Jul 2009)
# Updated Vorbis to version 1.2.3.
# Updated x264 to r1181.

5087 - [lame] save channel mode and bitrate mode on config window
5086 - [x264] save zones on Qt config window (FS#606)
5077 - [x264] suppress warning when using Qt config window and presets with Trellis or Cabac are switched off
5076 - [xvid] remember encode mode for GTK+ interface
5073 - [x264/xvid] set default encode mode for Qt config windows
5070 - [vidEnc] plugins now return supported colour spaces and Avidemux converts the decoded picture to the most lossless option
5065 - [win32] fix linking

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1183:

libx264-r1183, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1183M-gcc440-core2-fprofiled.7z)
libx264-r1183, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1183M-gcc440-amdfam10-fprofiled.7z)
libx264-r1183, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1183M-gcc440-pentium2-fprofiled.7z)
libx264-r1183, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1183M-gcc421-pentium2-fprofiled.7z)
libx264-r1183, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1183M-gcc345-pentium2-fprofiled.7z)


libx264 SVN-r1183 using experimental AutoVAQ patch v0.3 by BugMaster:

libx264-r1183, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1183M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1183, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1183M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1183, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1183M-autovaq-gcc440-pentium2-fprofiled.7z)


These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5087 (http://forum.doom9.org/showpost.php?p=1305115&postcount=1184) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster's patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the "force_align_arg_pointer" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.

[Schrade]

Is there a way to load raw .yuv files into Avidemux? I was wanting to encode some of the test clips available here:

http://media.xiph.org/video/derf/

[LoRd_MuldeR]

Is there a way to load raw .yuv files into Avidemux? I was wanting to encode some of the test clips available here:

http://media.xiph.org/video/derf/

Avidemux supports Avisynth input, so you can simply use RawSource(), I think.

Another option would be converting the "raw" YUV files to AVI first. That's what I do. It also saves some diskspace ;)

MEncoder.exe -demuxer rawvideo -rawvideo w=1920:h=1080:format=i420 -ovc lavc -lavcopts vcodec=ffvhuff -o "c:\output.avi" "c:\source.yuv"

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5104 (2009-07-17)
http://www.avidemux.org/

Revision 5104 (17 Jul 2009)
# Added opencore-amr 0.1.1.
# Updated x264 to r1183.

5104 - [codec] remove more old remnants
5103 - [dca] use avcodec dts decoder if libdca isn't found
5102 - [win32] update installer to include opencore plugins
5101 - [x264] load average quantiser in GTK+ config window
5100 - [mpeg1/2] adopt user settings instead of defaults
5095 - [amrnb] opencore-amrwb audio decoder plugin
5094 - [amrnb] opencore-amrnb audio decoder plugin
5092 - [Prefs] Merge patch so that avs4avidemux works without modification
5087 - [lame] save channel mode and bitrate mode on config window

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[Schrade]

Avidemux supports Avisynth input, so you can simply use RawSource(), I think.

Another option would be converting the "raw" YUV files to AVI first. That's what I do. It also saves some diskspace ;)

MEncoder.exe -demuxer rawvideo -rawvideo w=1920:h=1080:format=i420 -ovc lavc -lavcopts vcodec=ffvhuff -o "c:\output.avi" "c:\source.yuv"

Thanks for the command line!

Is there a reason why Avidemux doesn't support importing all the formats that ffmpeg/mencoder support?

[LoRd_MuldeR]

Is there a reason why Avidemux doesn't support importing all the formats that ffmpeg/mencoder support?

Probably because none of the developers had a reason to implement it yet ;)

If you ask why Avidemux doesn't support "raw" input, I think this is because raw YUV data files don't contain any header or meta information.
So there is no way for an application to recognize raw YUV data. The user has to provide all information, including width and height of the video.
Consequently the normal "File" -> "Open" dialog isn't sufficient here. We'd need something like "File" -> "Import" -> "Raw Video".

[LoRd_MuldeR]

libx264 SVN-r1184:

libx264-r1184, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1184M-gcc440-core2-fprofiled.7z)
libx264-r1184, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1184M-gcc440-amdfam10-fprofiled.7z)
libx264-r1184, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1184M-gcc440-pentium2-fprofiled.7z)
libx264-r1184, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1184M-gcc421-pentium2-fprofiled.7z)
libx264-r1184, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1184M-gcc345-pentium2-fprofiled.7z)


libx264 SVN-r1184 with AutoVAQ enabled:

libx264-r1184, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1184M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1184, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1184M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1184, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1184M-autovaq-gcc440-pentium2-fprofiled.7z)


These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5104 (http://forum.doom9.org/showpost.php?p=1306367&postcount=1188) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

[LoRd_MuldeR]

The Avisynth Proxy GUI for Avidemux has been updated.

Get the latest build here:
http://avidemux.org/admForum/viewtopic.php?id=4397

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5152 (2009-07-25)
http://www.avidemux.org/

Revision 5152 (25 Jul 2009)
# Updated Avisynth Proxy GUI to version 2.09d.
# Updated x264 to r1185.

5152 - [dlgFactory] fix crashing when saving profile using GTK config menu control
5151 - [dlgFactory] fix default profile support of GTK config menu control
5150 - [dlgFactory] make updateMe method of GTK toggle control work
5149 - [dlgFactory] make updateMe method of GTK bitrate control work
5147 - [mpeg1] add config menu control to plugin config window
5146 - [dlgFactory] more work on config menu dialog factory control
5145 - [core] move fileExist function to be included with other file I/O functions
5144 - [Check] closes #2 , dummy bug
5140 - [GTK] fix open dialogs performing save and vice versa
5139 - [plugin] fix small memory leaks when loading plugins
5138 - [vidEnc] cosmetics
5137 - [dlgFactory] all dialogFactory controls must now support an updateMe method
5136 - [win32] fix linker error
5128 - [i18n] de update by Joo Martin
5127 - [plugins] gcc 4.4 / linux compilation fix
5123 - [Build] More fixes with gcc 4.4 + fix bootStrap.sh
5122 - [dlgFactory] add config menu dialog factory control (incomplete)
5104 - [codec] remove more old remnants

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1189:

libx264-r1189, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1189M-gcc440-core2-fprofiled.7z)
libx264-r1194, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1189M-gcc440-amdfam10-fprofiled.7z)
libx264-r1189, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1189M-gcc440-pentium2-fprofiled.7z)
libx264-r1189, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1189M-gcc421-pentium2-fprofiled.7z)
libx264-r1189, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1189M-gcc345-pentium2-fprofiled.7z)


libx264 SVN-r1189 with AutoVAQ enabled:

libx264-r1189, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1189M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1189, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1189M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1189, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1189M-autovaq-gcc440-pentium2-fprofiled.7z)


These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5104 (http://forum.doom9.org/showpost.php?p=1306367&postcount=1188) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Now using a custom patch that will increase SubME by one in order to allow the new SubME=10 in Avidemux (until the GUI is updated).
However be aware that SubME=10 requires Trellis=2, otherwise it will fall back to SubeMe=9.

[LoRd_MuldeR]

libx264 SVN-r1190:

libx264-r1190, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1190M-gcc440-core2-fprofiled.7z)
libx264-r1190, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1190M-gcc440-amdfam10-fprofiled.7z)
libx264-r1190, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1190M-gcc440-pentium2-fprofiled.7z)
libx264-r1190, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1190M-gcc421-pentium2-fprofiled.7z)
libx264-r1190, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1190M-gcc345-pentium2-fprofiled.7z)


libx264 SVN-r1190 with AutoVAQ enabled:

libx264-r1190, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1190M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1190, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1190M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1190, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1190M-autovaq-gcc440-pentium2-fprofiled.7z)


These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5152 (http://forum.doom9.org/showpost.php?p=1308435&postcount=1193) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Now using a less "aggressive" patch to enable SubMe=10 in Avidemux:
Only SubMe=9 will be increased to SubMe=10 and even that only if Trellis=2 is used. Other SubMe modes are not effected at all.
This workaround will be used until the x264 GUI in Avidemux is updated with respect to the recent changes...

[LoRd_MuldeR]

libx264 SVN-r1192:

libx264-r1192, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1192M-gcc440-core2-fprofiled.7z)
libx264-r1192, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1192M-gcc440-amdfam10-fprofiled.7z)
libx264-r1192, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1192M-gcc440-pentium2-fprofiled.7z)
libx264-r1192, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1192M-gcc421-pentium2-fprofiled.7z)
libx264-r1192, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1192M-gcc345-pentium2-fprofiled.7z)


libx264 SVN-r1192 with AutoVAQ enabled:

libx264-r1192, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1192M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1192, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1192M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1192, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1192M-autovaq-gcc440-pentium2-fprofiled.7z)


These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5152 (http://forum.doom9.org/showpost.php?p=1308435&postcount=1193) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Now using a less "aggressive" patch to enable SubMe=10 in Avidemux:
Only SubMe=9 will be increased to SubMe=10 and even that only if Trellis=2 is used. Other SubMe modes are not effected at all.
This workaround will be used until the x264 GUI in Avidemux is updated with respect to the recent changes...

[LoRd_MuldeR]

libx264 SVN-r1193:

libx264-r1193, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1193M-gcc440-core2-fprofiled.7z)
libx264-r1193, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1193M-gcc440-amdfam10-fprofiled.7z)
libx264-r1193, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1193M-gcc440-pentium2-fprofiled.7z)
libx264-r1193, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1193M-gcc421-pentium2-fprofiled.7z)
libx264-r1193, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1193M-gcc345-pentium2-fprofiled.7z)


libx264 SVN-r1193 with AutoVAQ enabled:

libx264-r1193, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1193M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1193, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1193M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1193, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1193M-autovaq-gcc440-pentium2-fprofiled.7z)


These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5152 (http://forum.doom9.org/showpost.php?p=1308435&postcount=1193) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Now using a less "aggressive" patch to enable SubMe=10 in Avidemux:
Only SubMe=9 will be increased to SubMe=10 and even that only if Trellis=2 is used. Other SubMe modes are not effected at all.
This workaround will be used until the x264 GUI in Avidemux is updated with respect to the recent changes...

[LoRd_MuldeR]

libx264 SVN-r1195:

libx264-r1195, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1195M-gcc440-core2-fprofiled.7z)
libx264-r1195, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1195M-gcc440-amdfam10-fprofiled.7z)
libx264-r1195, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1195M-gcc440-pentium2-fprofiled.7z)
libx264-r1195, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1195M-gcc421-pentium2-fprofiled.7z)
libx264-r1195, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1195M-gcc345-pentium2-fprofiled.7z)


libx264 SVN-r1195 with AutoVAQ enabled:

libx264-r1195, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1195M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1195, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1195M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1195, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1195M-autovaq-gcc440-pentium2-fprofiled.7z)


These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5152 (http://forum.doom9.org/showpost.php?p=1308435&postcount=1193) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Now using a less "aggressive" patch to enable SubMe=10 in Avidemux:
Only SubMe=9 will be increased to SubMe=10 and even that only if Trellis=2 is used. Other SubMe modes are not effected at all.
This workaround will be used until the x264 GUI in Avidemux is updated with respect to the recent changes.
(SubME=10 was borked in previous revisions of x264, so I recommend updating now)

[bizz & buzz]

There's some info on 'Luma Quantization Deadzones' on http://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping
so maybe the H264 page on the wiki can be updated. I'll leave it to the pros decision.

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5181 (2009-07-30)
http://www.avidemux.org/

Revision 5181 (30 Jul 2009)
# Updated x264 to r1195.

5181 - [win32] fix icon reference in resource file
5180 - [mpeg1] unix build fix
5179 - [dlgFactory] load/save profile on GTK config menu
5178 - [dlgFactory] load/save profile on Qt config menu
5177 - [win32] fix linking
5173 - [Gtk] Fix crash when doing about, introduced by commit 5167
5172 - [build] Also check git/git svn to get the rev number, fixes #7
5171 - [build] Fetch version for svn AND git
5170 - [icons] delete audio-volum-medium
5169 - [Qt] disable configure button when video codec doesn't have settings
5168 - [Qt] disable configure button when video codec doesn't have settings
5167 - [UI] Put in JM icons, reorganize a bit directory , probably breaks win32
5166 - [Qt] fix colour chooser dialog
5165 - [cmake] correctly report existence of Qt and GTK in plugin cmake summary
5163 - [dlgFactory] trigger custom profile on Qt config menu
5162 - [audiodec] remove libamrnb and libdca plugins. They have been replaced by opencore-amrnb and ffmpeg's dca decoder
5159 - [Gtk/Menu] Fix const char/char mixup
5158 - [cmake] add ffmpeg as dependency for coreImage so Make can run using multiple jobs
5157 - [plugins] Fix build with gcc 4.4
5156 - [po] Traditional Chinese update by Dong-Jun Wu, not sure that file is needed
5155 - [po] Traditional Chinese update by Dong-Jun Wu
5154 - [po] Traditional Chinese update by Dong-Jun Wu
5153 - [dlgFactory] make updateMe method of Qt toggle control work
5152 - [dlgFactory] fix crashing when saving profile using GTK config menu control

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1195:

libx264-r1195, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1195M-gcc441-core2-fprofiled.7z)
libx264-r1195, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1195M-gcc441-amdfam10-fprofiled.7z)
libx264-r1195, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1195M-gcc441-pentium2-fprofiled.7z)


libx264 SVN-r1195 with AutoVAQ enabled:

libx264-r1195, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1195M-autovaq-gcc441-core2-fprofiled.7z)
libx264-r1195, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1195M-autovaq-gcc441-amdfam10-fprofiled.7z)
libx264-r1195, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1195M-autovaq-gcc441-pentium2-fprofiled.7z)


These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5181 (http://forum.doom9.org/showpost.php?p=1310205&postcount=1200) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Re-built using Komisar's GCC 4.4.1 with Graphite loop transform framework (Link (http://forum.doom9.org/showpost.php?p=1311229&postcount=2118)).

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5204 (2009-08-03)
http://www.avidemux.org/

5204 - [ffmpeg] update FFmpeg to r19575 & libswscale to r29474
5203 - [x264] gcc 4.4 fix
5200 - [mpeg1] replicate encoding logic for mpeg-1 plugin (only CQ currently done)
5199 - [vidEnc] allow separate schema and xml directories for plugin options
5198 - [gui] fix Go To Frame window (fixes #11)
5197 - [cmake] restore SVN switch
5193 - [UI] Remove all plugin-ified field from the build-in dialog
5192 - [Gtk/icons] Put back the video filter icons, build them properly
5191 - [Ts/i18n] Fix dependancies so that it does not break parallel build (xml and lrelease file could be built // while the latter depends on the former)
5190 - [plugins] remove old ADM_libass, replaced by ADM_libAss
5189 - [dlgFactory] trigger custom profile on GTK config menu (control should now be complete for both toolkits)
5188 - [dlgFactory] make updateMe method of GTK bitrate control work
5187 - [misc] Update gitignore
5186 - [Ass] Simplify fonts to avoid crash + enable freeing stuff as the globals have been remove from libass
5185 - [ass] Update
5184 - [dlgFactory] make updateMe method of menu control work
5183 - [mpeg1] another attempt at unix build fix
5182 - [win32] fix icon reference in installer script
5181 - [win32] fix icon reference in resource file

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[ffmpeg]

Hi, LoRd_MuldeR

Where do you get gcc 4.4.1 for mingw?

Thanks

[LoRd_MuldeR]

Hi, LoRd_MuldeR

Where do you get gcc 4.4.1 for mingw?

Thanks

The link is in the post :p

[TheImperial2004]

Any news when will the x264 dialog will be updated ?

That will be the most exciting revision ever ^_^

[LoRd_MuldeR]

Any news when will the x264 dialog will be updated ?

That will be the most exciting revision ever ^_^

As always: It's done when it's done :D

I've already filed a report in the (internal) bug tracker, so the issue is known...

[TheImperial2004]

Thanks Mulder for keeping an eye on AviDemux development for us :)

Edit : Maybe I'm asking too much , but can you complie a libx264.dll with the new Mbtree patch ? I'm dying to test it ^_^

[akiza]

libx264 SVN-r1195:

libx264-r1195, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1195M-gcc441-core2-fprofiled.7z)
libx264-r1195, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1195M-gcc441-amdfam10-fprofiled.7z)
libx264-r1195, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-68-r1195M-gcc441-pentium2-fprofiled.7z)


libx264 SVN-r1195 with AutoVAQ enabled:

libx264-r1195, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1195M-autovaq-gcc441-core2-fprofiled.7z)
libx264-r1195, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1195M-autovaq-gcc441-amdfam10-fprofiled.7z)
libx264-r1195, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-68-r1195M-autovaq-gcc441-pentium2-fprofiled.7z)


These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5181 (http://forum.doom9.org/showpost.php?p=1310205&postcount=1200) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.

Re-built using Komisar's GCC 4.4.1 with Graphite loop transform framework (Link (http://forum.doom9.org/showpost.php?p=1311229&postcount=2118)).

I have some questions...:)

1.Does the original x264 not optimize for amd/p6/core2 ?

2.Why these optimized-builds not including in the installer,and let user chose(or let program detect) which build sould use ?
:D

[LoRd_MuldeR]

1.Does the original x264 not optimize for amd/p6/core2 ?

There is no "original" x264 binary, because the x264 team only provides source code. They don't provide pre-compiled binaries.

Also keep in mind that these compiler optimizations only effect the plain C code in x264.

All the performance-critical functions are already "hand optimized" as Assembler code by the x264 developers!

So the effect of additional compiler optimizations isn't that huge. But they don't hurt either, so...

2.Why these optimized-builds not including in the installer,and let user chose(or let program detect) which build should use?

Probably Gruntster (the one who provides the Win32 builds of Avidemux) thinks one "generic" (i686) build of libx264 is sufficient.

Also a generic build is less prone to problems, such as people getting crashes by using a wrong build for their machine...

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5234 (2009-08-12)
http://www.avidemux.org/

Revision 5234 (12 Aug 2009)
# Updated Cairo to version 1.8.8-1.
# Updated Fontconfig to version 2.7.1-1.
# Updated Freetype to version 2.3.9-1.
# Updated GLib to version 2.20.4-1.
# Updated GTK+ to version 2.16.5-1.
# Updated Pango to version 1.24.5-1.
# Updated libpng to version 1.2.38-1.
# Updated x264 to r1206.

5234 - [lavDeinterlace] add lowpass5 support (patch by torrentss; fixes #22)
5233 - [asharp] label block filtering checkbox (patch by torrentss)
5232 - [asharp] allow disabling of "Block Adaptive" mode (patch by torrentss)
5231 - [mpeg1] two pass logic for mpeg-1 plugin (incomplete)
5225 - [Demuxer/mp4] dont divide by 0 when STSD is full of zeroes for audio track
5210 - [vidDec] improve null frame check (fixes #15)
5205 - [fraps] add support for fraps video decoder
5204 - [ffmpeg] update FFmpeg to r19575 & libswscale to r29474

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1206 with MB-Tree Ratecontrol:

libx264-r1206, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1206M-gcc441-core2-fprofiled.7z)
libx264-r1206, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1206M-gcc441-amdfam10-fprofiled.7z)
libx264-r1206, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1206M-gcc441-pentium2-fprofiled.7z)


libx264 SVN-r1206 without MB-Tree Ratecontrol:

libx264-r1206, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1206M-nombtree-gcc441-core2-fprofiled.7z)
libx264-r1206, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1206M-nombtree-gcc441-amdfam10-fprofiled.7z)
libx264-r1206, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1206M-nombtree-gcc441-pentium2-fprofiled.7z)


libx264 SVN-r1206 with AutoVAQ enabled:

libx264-r1206, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1206M-autovaq-gcc441-core2-fprofiled.7z)
libx264-r1206, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1206M-autovaq-gcc441-amdfam10-fprofiled.7z)
libx264-r1206, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1206M-autovaq-gcc441-pentium2-fprofiled.7z)


libx264 SVN-r1206 legacy compiler builds:

libx264-r1206, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1206M-gcc421-pentium2-fprofiled.7z)
libx264-r1206, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1206M-gcc345-pentium2-fprofiled.7z)


These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5234 (http://forum.doom9.org/showpost.php?p=1314049&postcount=1210) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

Re-built using Komisar's GCC 4.4.1 with Graphite loop transform framework (Link (http://forum.doom9.org/showpost.php?p=1311229&postcount=2118)).

[Schrade]

Does "libx264 SVN-r1206 with AutoVAQ enabled:" have MB-Tree?

[nakTT]

Avidemux 2.5 SVN-r5234 (2009-08-12)
http://www.avidemux.org/
Hoping to be able to download the zip version from your site.

:thanks:

[LoRd_MuldeR]

Does "libx264 SVN-r1206 with AutoVAQ enabled:" have MB-Tree?

MB-Tree RC is officially committed and enabled by default. So the answer is: Yes.

The "without MB-Tree" build was explicitly patched to disabled MB-Tree RC, because there is no such option in Avidemux yet - and I though people may want to test MB-Tree vs. old school.

(Note that you can always have a look at the Log to see which options are enabled and which aren't)

Hoping to be able to download the zip version from your site.

I don't mirror the ZIP package, but you can find it here on Gruntster's site:

http://avidemux.razorbyte.com.au/

[LoRd_MuldeR]

libx264 SVN-r1210 with MB-Tree Ratecontrol:

libx264-r1210, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1210M-gcc441-core2-fprofiled.7z)
libx264-r1210, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1210M-gcc441-amdfam10-fprofiled.7z)
libx264-r1210, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1210M-gcc441-pentium2-fprofiled.7z)


libx264 SVN-r1210 without MB-Tree Ratecontrol:

libx264-r1210, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1210M-nombtree-gcc441-core2-fprofiled.7z)
libx264-r1210, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1210M-nombtree-gcc441-amdfam10-fprofiled.7z)
libx264-r1210, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1210M-nombtree-gcc441-pentium2-fprofiled.7z)


libx264 SVN-r1210 with AutoVAQ enabled:

libx264-r1210, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1210M-autovaq-gcc441-core2-fprofiled.7z)
libx264-r1210, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1210M-autovaq-gcc441-amdfam10-fprofiled.7z)
libx264-r1210, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1210M-autovaq-gcc441-pentium2-fprofiled.7z)


libx264 SVN-r1210 legacy compiler builds:

libx264-r1210, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1210M-gcc421-pentium2-fprofiled.7z)
libx264-r1210, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1210M-gcc345-pentium2-fprofiled.7z)


These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r5234 (http://forum.doom9.org/showpost.php?p=1314049&postcount=1210) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

Re-built using Komisar's GCC 4.4.1 with Graphite loop transform framework (Link (http://forum.doom9.org/showpost.php?p=1311229&postcount=2118)).

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5249 (2009-08-16)
http://www.avidemux.org/

Revision 5249 [2.5.1 Final] (16 Aug 2009)
# Updated Fontconfig to version 2.7.1-2.

5247 - [version] Bump 2.5.1
5246 - [ffmpeg] update ffmpeg tarballs
5241 - [audioDecoder] Backport audio codec priority from 2.6
5240 - [UI/Gtk] Better looking filter dialog by JM
5239 - [UI/Gtk] New play icon from JM
5234 - [lavDeinterlace] add lowpass5 support (patch by torrentss; fixes #22)

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[TheImperial2004]

WOW , am really surprised that "mean" didn't update x264 dialog this time either .. But I believe , now that we reached a stable release , he should consider adding some new features such as the long-awaited new x264 settings dialog :)

[Betsy25]

I actually went to this thread to post the exact same thing : WOW !

All my previous problems (green video, couldn't open almost any input video, etc....) have all been fixed.

Congrats Lord on this fantastic tool !:)

EDIT: Just a minor problem still exists, sometimes on opening input video, AviDemux shows an Error Cannot open □, retrying a couple of times mostly it's able to load the file.

[LoRd_MuldeR]

Congrats Lord on this fantastic tool !:)

You should express your gratefulness to Mean and especially to Gruntster :)

BTW: For most of the x264 options missing in Avidemux my builds of libx264 (not the ones contained in the installer!) have workarounds.

This includes "Fast First-Pass", "QPRD" (aka SubME=10), "AutoVAQ" and "MB-Tree". I also raised Psy-Trellis to 0.15, as used by the "--tune film" option in x264 CLI.

And, as said before, the (non-public) bug tracker already has a detailed issue for the missing x264 options. Just be patient...

Just a minor problem still exists, sometimes on opening input video, AviDemux shows an Error Cannot open □, retrying a couple of times mostly it's able to load the file.

That sounds weird, because the behavior of Avidemux should be deterministic: Either a file opens or it doesn't. But how can it work after several retries?

Can you open a thread in the Avidemux Forum (http://avidemux.org/admForum/) and provide a sample file?

[LoRd_MuldeR]

libx264 SVN-r1214 with MB-Tree Ratecontrol:

libx264-r1214, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1214M-gcc441-core2-fprofiled.7z)
libx264-r1214, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1214M-gcc441-amdfam10-fprofiled.7z)
libx264-r1214, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1214M-gcc441-pentium2-fprofiled.7z)


libx264 SVN-r1214 without MB-Tree Ratecontrol:

libx264-r1214, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1214M-nombtree-gcc441-core2-fprofiled.7z)
libx264-r1214, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1214M-nombtree-gcc441-amdfam10-fprofiled.7z)
libx264-r1214, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1214M-nombtree-gcc441-pentium2-fprofiled.7z)


libx264 SVN-r1214 with AutoVAQ enabled:

libx264-r1214, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1214M-autovaq-gcc441-core2-fprofiled.7z)
libx264-r1214, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1214M-autovaq-gcc441-amdfam10-fprofiled.7z)
libx264-r1214, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1214M-autovaq-gcc441-pentium2-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 (http://forum.doom9.org/showpost.php?p=1315631&postcount=1216) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

[LoRd_MuldeR]

libx264 SVN-r1217 with MB-Tree Ratecontrol:

libx264-r1217, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1217M-gcc441-core2-fprofiled.7z)
libx264-r1217, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1217M-gcc441-amdfam10-fprofiled.7z)
libx264-r1217, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1217M-gcc441-pentium2-fprofiled.7z)


libx264 SVN-r1217 without MB-Tree Ratecontrol:

libx264-r1217, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1217M-nombtree-gcc441-core2-fprofiled.7z)
libx264-r1217, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1217M-nombtree-gcc441-amdfam10-fprofiled.7z)
libx264-r1217, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1217M-nombtree-gcc441-pentium2-fprofiled.7z)


libx264 SVN-r1217 with AutoVAQ enabled:

libx264-r1217, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1217M-autovaq-gcc441-core2-fprofiled.7z)
libx264-r1217, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1217M-autovaq-gcc441-amdfam10-fprofiled.7z)
libx264-r1217, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1217M-autovaq-gcc441-pentium2-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 (http://forum.doom9.org/showpost.php?p=1315631&postcount=1216) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

This build was patched back to core-70 in order to make it work with Avidemux 2.5.1 release version. Hope I didn't break it ^^

[TheImperial2004]

Hi Mulder ,,

I am woundering , what programming language is AviDemux's source ?

I was just thinking that we can update the x264 dialog ourselves , no ?

[LoRd_MuldeR]

I am woundering , what programming language is AviDemux's source ?

Avidemux is written in C/C++ and the GUI is implemented with the Qt toolkit (there also is a GTK+ GUI).

I was just thinking that we can update the x264 dialog ourselves , no ?

Feel free to do so. Nobody is holding you back. The sources are open :)

[DarkZell666]

Hi Mulder ,,

I am wondering , what programming language is AviDemux's source ?

I was just thinking that we can update the x264 dialog ourselves , no ?

It's in C++, the UI being coded both with GTK+ and QT4.
Check this out : http://avidemux.org/admWiki/index.php?title=Compiling_Avidemux

[TheImperial2004]

Daym!
I can only work on C# sources ...

[LoRd_MuldeR]

libx264 SVN-r1222 with MB-Tree Ratecontrol:

libx264-r1222, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1222M-gcc441-core2-fprofiled.7z)
libx264-r1222, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1222M-gcc441-amdfam10-fprofiled.7z)
libx264-r1222, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-70-r1222M-gcc441-pentium2-fprofiled.7z)


libx264 SVN-r1222 without MB-Tree Ratecontrol:

libx264-r1222, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1222M-nombtree-gcc441-core2-fprofiled.7z)
libx264-r1222, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1222M-nombtree-gcc441-amdfam10-fprofiled.7z)
libx264-r1222, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1222M-nombtree-gcc441-pentium2-fprofiled.7z)


libx264 SVN-r1222 with AutoVAQ enabled:

libx264-r1222, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1222M-autovaq-gcc441-core2-fprofiled.7z)
libx264-r1222, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1222M-autovaq-gcc441-amdfam10-fprofiled.7z)
libx264-r1222, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-70-r1222M-autovaq-gcc441-pentium2-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 (http://forum.doom9.org/showpost.php?p=1315631&postcount=1216) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

This build was patched back to core-70 in order to make it work with Avidemux 2.5.1 release version. Hope I didn't break it ^^

[Poutnik]

I use Avidemux 2.5.1 for cutting and encoding MPEG2 stream to H264,
used mode CRF with Q23. I have noticed quantizers on encoding window
never below 27, usually 27-28. Is it normal ?

Similarly, when used default CRF Q26, there is seen Q30-31.

I was used to, probably in MeGUI, for CRF Q23 to usually see Q 23-26,
sometimes even below 23.

[LoRd_MuldeR]

I use Avidemux 2.5.1 for cutting and encoding MPEG2 stream to H264,
used mode CRF with Q23. I have noticed quantizers on encoding window
never below 27, usually 27-28. Is it normal ?

Yes, it's normal. CRF mode is "Constant Rate Factor" mode, it's not constant quantizer mode. And that for good reasons ;)

So even if the CRF values have the same range as the quantizers (0-51), you can't expect to see quantizer values that are identical to the CRF value (rate factor) you have selected.

Last but not least x264 controls the quantizers on Macroblock-level now, so the (frame) quantizers you see actually don't give you much information...

(BTW: Results from Avidemux and MeGUI are identical, given that the same version/revision of x264 is used, the same encoder settings are chosen and the source is identical)

[Poutnik]

The first 2 paragraphs are obvious to me.

The main change is shift from analog TV to DVB-T, leading probablyX264 to display higher Q.
I suppose X264 changes are minor here.

[LoRd_MuldeR]

The main change is shift from analog TV to DVB-T, leading probablyX264 to display higher Q.

x264 doesn't care where your source came from. Analog TV, digital TV or elsewhere. It only cares about the "complexity" of the content. In 2-Pass mode (and also in CRF mode) quantizers are controlled per block now: Blocks that will have a huge impact on future frames will get a lower quantizer. At the same time blocks that will only have a small impact on future frames will get a higher quantizer. I'm not entirely sure what the quantizer value is that Avidemux displays while encoding, but I assume that it's the average quantizer of all blocks in the current frame. So that value only provides limited information! Anyway, it's perfectly normal to see that value being much higher than your CRF value. Especially in "complex" scenes with a lot of motion. That's because in "fast" scenes x264 will raise the quantizers for the reasons explained before.

BTW: For more useful information inspect the encoded stream with a tool that allows to display the quantizers for individual blocks!

[TheImperial2004]

5268 is out :)

If Lord_Mulder won't mind :

Download : AviDemux Windows Builds (http://avidemux.razorbyte.com.au/)

Change Log :

[win32] bump installer version

[qt] save crash file when Avidemux unexpectedly quits (regression introduced in 2.5.0)

[qt] disable video encoder when muxer set to avi pack/unpack

[gui] prevent opening audio filter window when in copy mode

[gui] prevent opening video filter window when in copy mode (fixes #27)

[Codec] WMVA==VC1 video codec

[Audio/vorbis] Check also for vorbis decoder and build the decoder plugin

[Flv] Backport metadata handling from 2.6, fixes #26


Windows Package Notes :

Revision 5268 (23 Aug 2009) : Updated x264 r1222.

Edit : The VC-1 is not a codec , but : Only the FourCC "WMVA" wasn't recognized properly until now.

[LoRd_MuldeR]

TheImperial2004, you interpreted the log wrong. VC-1 is supported as input for a long time. Only the FourCC "WMVA" wasn't recognized properly until now.

That was fixed in r5263, nothing else. There is no VC-1 encoder in Avidemux. In fact I'm not aware of any OpenSource VC-1 encoder that could be included in Avidemux.

And to be honest, who would want to use VC-1 when we have an excellent H.264 encoder, such as x264, available?

H.264 not only compresses more efficient than VC-1, also the support for H.264 in hardware players is on par with VC-1 or even better ;)

[TheImperial2004]

Sorry for the wrong analysis :)

I just love AviDemux so much and I would happy to see it provide more features , thats why I got excited when I saw VC-1 in the log ;)

Maybe I am wrong , but I got two anime episodes , one encoded with VC-1 and the other with x264 . I can easily say that the VC-1 looks more appealing at the same size . So I got my doubts :) But I think because x264 used was 488 so , maybe it is different with the latest builds (like those I use with AviDemux - 1222 , VC-1 is waaaaaaaaay beyond in quality ;)) ...

Of course , using MSharpen + MPlayer eq2 + CRF : 20 + AQ : 1.50 = No other lossy codec can beat that in Quality <--> Size !!! :)

[LoRd_MuldeR]

libx264 SVN-r1222:

libx264-r1222, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1222M-gcc441-core2-fprofiled.7z)
libx264-r1222, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1222M-gcc441-amdfam10-fprofiled.7z)
libx264-r1222, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1222M-gcc441-pentium2-fprofiled.7z)


libx264 SVN-r1222 without MB-Tree Ratecontrol:

libx264-r1222, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1222M-nombtree-gcc441-core2-fprofiled.7z)
libx264-r1222, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1222M-nombtree-gcc441-amdfam10-fprofiled.7z)
libx264-r1222, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1222M-nombtree-gcc441-pentium2-fprofiled.7z)


libx264 SVN-r1222 with AutoVAQ enabled:

libx264-r1222, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1222M-autovaq-gcc441-core2-fprofiled.7z)
libx264-r1222, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1222M-autovaq-gcc441-amdfam10-fprofiled.7z)
libx264-r1222, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1222M-autovaq-gcc441-pentium2-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5268 (http://forum.doom9.org/showpost.php?p=1317796&postcount=1231) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

Re-built r1222 with core-72, because Avidemux was updated now. So I don't need to patch x264 back to core-70 any longer.

[Poutnik]

.....Anyway, it's perfectly normal to see that value being much higher than your CRF value. Especially in "complex" scenes with a lot of motion. That's because in "fast" scenes x264 will raise the quantizers for the reasons explained before.......


I understand the concept of Q distribution. What I do not understand is why the displayed avg Q is always much higher, even in short test clips with scenes with low details and low motion.

It keeps formula Q = CRFQ + ( 4 - 5 ) no matter what is being processed.

[LoRd_MuldeR]

I understand the concept of Q distribution. What I do not understand is why the displayed avg Q is always much higher, even in short test clips with scenes with low details and low motion.

It keeps formula Q = CRFQ + ( 4 - 5 ) no matter what is being processed.

As said before, just looking at the average quantizer of a frame doesn't yield much information. Just imagine a "complex" object moving very fast in front of a "static" background. In that case x264 would assign much higher quantizers to the blocks representing the foreground object, while assigning much lower quantizers to the blocks representing the background. So looking only at the average quantizer of all blocks in the frame may be completely misleading here! It's just a wrong idea to expect that each frame should have an average quantizer that equals your CRF value.

If you are interested in quantizers, you really should inspect your clip with a tool that displays quantizers for individual blocks, such as ffdshow's "Visualization" feature. Anyway, choosing your CRF value based on the resulting quantizers is the wrong way. You should try to find that highest possible CRF value that still gives satisfactory quality - and use it!

[Dark Shikari]

Is the value printed even the average of the quantizers, or is it the frame quantizer? The latter is even more useless as a metric...

[Poutnik]

......So looking only at the average quantizer of all blocks in the frame may be completely misleading here! It's just a wrong idea to expect that each frame should have an average quantizer that equals your CRF value.

.......Anyway, choosing your CRF value based on the resulting quantizers is the wrong way. You should try to find that highest possible CRF value that still gives satisfactory quality - and use it!

Thank you for your answers.

I do not make any decisions, based on displayed quantizer, nor expecting it should equal nominal CRF.
In fact, I taking it myself quite useless.
Even if displayed CRF bitrate varies in ratio up to 300:3000 in some movies, Q keeps mentioned favorite values.
I was wondering only, why I was used for the same settings CRF23 to see Q 22- 26 in the past,
and 27-28 now, but it is not big deal at all, just curiosity.

BTW, according high values, it seems those low detail low motion scenes are full of fast flying complex objects. :)

I definitely try ffdshow Q feature, I knew it has it, when you are talking about.
_________________________________

other topic: when I was experimenting with video codecs of AD Win32 2.5.1 (5249), DV codec always caused immediate Avidemux shutdown without notice.

[LoRd_MuldeR]

<EDIT>

These builds may be broken. New builds will be up soon!

I noticed that there may be a problem with GCC 4.4.1 and Core2-optimized builds. For more information please see and reply to this (http://forum.doom9.org/showthread.php?p=1318401#post1318401) thread!

</EDIT>


libx264 SVN-r1232:

libx264-r1232, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1232M-gcc441-core2-fprofiled.7z)
libx264-r1232, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1232M-gcc441-amdfam10-fprofiled.7z)
libx264-r1232, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1232M-gcc441-pentium2-fprofiled.7z)


libx264 SVN-r1232 without MB-Tree Ratecontrol:

libx264-r1232, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1232M-nombtree-gcc441-core2-fprofiled.7z)
libx264-r1232, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1232M-nombtree-gcc441-amdfam10-fprofiled.7z)
libx264-r1232, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1232M-nombtree-gcc441-pentium2-fprofiled.7z)


libx264 SVN-r1232 with AutoVAQ enabled:

libx264-r1232, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1232M-autovaq-gcc441-core2-fprofiled.7z)
libx264-r1232, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1232M-autovaq-gcc441-amdfam10-fprofiled.7z)
libx264-r1232, MinGW GCC 4.4.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1232M-autovaq-gcc441-pentium2-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5268 (http://forum.doom9.org/showpost.php?p=1317796&postcount=1231) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

[TheImperial2004]

(broken!?)

Did it crash with a specific clip or all clips ?

How about using 4.3.3 ? Does that decrease performance or omit some features ?

[LoRd_MuldeR]

Did it crash with a specific clip or all clips ?

Specific clip. Maybe even only with specific options (didn't test a lot of combinations). But the crash is re-producible!

How about using 4.3.3 ? Does that decrease performance or omit some features ?

In fact I'm going back to GCC 4.3.3 for now. New builds will be up soon...

[LoRd_MuldeR]

libx264 SVN-r1232:

libx264-r1232, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1232M-gcc433-core2-fprofiled.7z)
libx264-r1232, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1232M-gcc433-amdfam10-fprofiled.7z)
libx264-r1232, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1232M-gcc433-pentium2-fprofiled.7z)


libx264 SVN-r1232 without MB-Tree Ratecontrol:

libx264-r1232, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1232M-nombtree-gcc433-core2-fprofiled.7z)
libx264-r1232, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1232M-nombtree-gcc433-amdfam10-fprofiled.7z)
libx264-r1232, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1232M-nombtree-gcc433-pentium2-fprofiled.7z)


libx264 SVN-r1232 with AutoVAQ enabled:

libx264-r1232, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1232M-autovaq-gcc433-core2-fprofiled.7z)
libx264-r1232, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1232M-autovaq-gcc433-amdfam10-fprofiled.7z)
libx264-r1232, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1232M-autovaq-gcc433-pentium2-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5268 (http://forum.doom9.org/showpost.php?p=1317796&postcount=1231) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

Re-built x264 r1232 with TDM's MinGW/GCC 4.3.3, which hopefully fixes the problem discussed in this (http://forum.doom9.org/showthread.php?p=1318401#post1318401) thread. Waiting for feedback...

[TheImperial2004]

I'll try with various options and see ... :thanks:

Edit : Works like charm encoding these CGs using highest -not overkill- settings ^_^

[LoRd_MuldeR]

libx264 SVN-r1235:

libx264-r1235, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1235M-gcc433-core2-fprofiled.7z)
libx264-r1235, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1235M-gcc433-amdfam10-fprofiled.7z)
libx264-r1235, MinGW GCC 4.3.3, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1235M-gcc433-pentium3-fprofiled.7z)
libx264-r1235, MinGW GCC 4.3.3, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1235M-gcc433-noasm-fprofiled.7z)


libx264 SVN-r1235 without MB-Tree Ratecontrol:

libx264-r1235, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1235M-nombtree-gcc433-core2-fprofiled.7z)
libx264-r1235, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1235M-nombtree-gcc433-amdfam10-fprofiled.7z)
libx264-r1235, MinGW GCC 4.3.3, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1235M-nombtree-gcc433-pentium3-fprofiled.7z)


libx264 SVN-r1235 with AutoVAQ enabled:

libx264-r1235, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1235M-autovaq-gcc433-core2-fprofiled.7z)
libx264-r1235, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1235M-autovaq-gcc433-amdfam10-fprofiled.7z)
libx264-r1235, MinGW GCC 4.3.3, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1235M-autovaq-gcc433-pentium3-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 5273 (http://forum.doom9.org/showpost.php?p=1319348&postcount=1246) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

I added a build with no ASM, because it seems that x264 r1233+ won't run on Non-SSE CPU's, unless I completely disable ASM...

[LoRd_MuldeR]

Builds in previous post (http://forum.doom9.org/showpost.php?p=1319078&postcount=1244) updated!

Dropped the Pentium 2 optimized build, because x264 wouldn't run on such a CPU anyway (at least not with ASM enabled!), and added a Pentium III optimized build instead.
Also the "without ASM" build, which will run on CPU's that don't support SSE (including the Pentium 2 and the Athlon K7), has been fprofiled now - but will be slooooow anyway.
(BTW: Now building under Windows 7 Professional 64-Bit instead of Windows XP 64-Bit Edition. Hope that didn't break anything ^^)

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5273 (2009-08-27)
http://www.avidemux.org/

Revision 5273 (27 Aug 2009)
# Updated x264 r1235.
# Updated Xvid 1.2.2.

Revision 5268 (23 Aug 2009)
# Updated x264 r1222.

5273 - [ffmpeg] update FFmpeg to r19733 & libswscale r29569
5272 - [win32] fix patching to work with latest MSYS tools
5271 - [win32] add libvorbis decoder to Windows installer
5270 - [xvid] adopt vfw defaults instead of xvidcore (fixes #29)
5269 - [xvid] allow max i-frame interval = 0 on GTK config window
5268 - [win32] bump installer version
5267 - [qt] save crash file when Avidemux unexpectedly quits (regression introduced in 2.5.0)
5266 - [qt] disable video encoder when muxer set to avi pack/unpack
5265 - [gui] prevent opening audio filter window when in copy mode
5264 - [gui] prevent opening video filter window when in copy mode (fixes #27)
5263 - [Codec] WMVA==VC1 video codec
5256 - [Audio/vorbis] Check also for vorbis decoder and build the decoder plugin
5255 - [Flv] Backport metadata handling from 2.6, fixes #26

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[TheImperial2004]

I noticed that AviDemux's own builds of Libx264 is bigger than your builds , by 100Kb at least (For the same build number of course) , I tried 1235 with both builds and MediaInfo showed that both builds used the very same encoding settings -including MB-Tree- ... So why does size differ between the two ?

[LoRd_MuldeR]

I noticed that AviDemux's own builds of Libx264 is bigger than your builds , by 100Kb at least (For the same build number of course) , I tried 1235 with both builds and MediaInfo showed that both builds used the very same encoding settings -including MB-Tree- ... So why does size differ between the two ?

I assume that Gruntster doesn't fprofile (http://forum.doom9.org/showthread.php?p=1319384#post1319384) his libx264 builds. Also he doesn't use any CPU-specific optimizations. Last but not least he uses an older MinGW/GCC version than I do (4.2.1 -vs- 4.3.3).

BTW: Builds of libx264 don't "use" any encoding settings. The encoding settings are controlled by the host application (Avidemux) at runtime. Only the defaults are "hardcoded" in the build at compiletime.

[TheImperial2004]

The encoding settings are controlled by the host application (Avidemux) at runtime

Does that means that AviDemux "Knows" and "Uses" the new x264 features , its just that the GUI is not updated to give the user control over them ?

[LoRd_MuldeR]

Does that means that AviDemux "Knows" and "Uses" the new x264 features , its just that the GUI is not updated to give the user control upon them ?

Nope, Avidemux doesn't "know" about the new features (unless the new options are implemented by the Avidemux developers), but it also doesn't need to know about them :D

Every time new features are added to x264, the API is extended accordingly. So there are new interfaces available to the host application (e.g. Avidemux) to control the new x264 features.

However the host application can simply ignore those new interfaces! In that case the new x264 features are still there and will be used with default settings.

For example the MB-Tree RC added a new field to the API, so the host application can enable/disable MB-Tree RC. But if the host application simply ignores that field, MB-Tree RC will be enabled by default.

However there also are features that are disabled by default. Unless the host application explicitly enables those features, they won't be used. That applies to Psy-Trellis for example.

(Since Avidemux doesn't expose an option to enable Psy-Trellis yet, I patched (http://mplayer.somestuff.org/misc/libx264/patches/psy_trellis.diff) my builds of libx264 to enable Psy-Trellis by default. It will use a strength of 0.15)

[TheImperial2004]

So , Every default will be used unelss stated otherwise , or default value changed ....

BTW : Sometimes I need to Deinterlace some videos , Is the "Decomb Telecide" filter is considered "True Deinterlacer" or should I look for another one ? What do you suggest ?

Also , I thought that scan order only exists in interlaced video , see below :

http://theimperial2004.googlepages.com/Capture.JPG

???

[LoRd_MuldeR]

So , Every default will be used unelss stated otherwise , or default value changed ....

Yes. The x264 library will initialize all encoding options with default values. Then the host application can either modify those options or keep them at default (or simply ignore "unknown" options).

Finally x264 will validate all options before the encoding process is started. Even if the host application set an options to an "invalid" value, x264 will correct that...

[TheImperial2004]

Sorry see my edited post ^^

[LoRd_MuldeR]

Sometimes I need to Deinterlace some videos , Is the "Decomb Telecide" filter is considered "True Deinterlacer" or should I look for another one ? What do you suggest ?

The purpose of Decomb Telecide is to restore progressive frames from "Telecined" material. It also has post-processing to remove remaining combing artifacts.

If your material is "true" interlaced (not Telecined), then you should consider using YADIF (preferably in "bob" mode) or TDeint. But for Telecined material stick with Decomb Telecide!

Also , I thought that scan order only exists in interlaced video , see below :???

That's right. IMHO it doesn't make sense to print out "scan order" for progressive video. But maybe that's the scan order that would be used for psF (progressive with segmented frames).

[TheImperial2004]

not Telecined

How to find that out ?

[LoRd_MuldeR]

By looking at it. For example if you apply YADIF (in "Bob" mode!) and in the result there's actual motion between each pair of consecutive frames, then it was "true" interlaced.

But if the original was 24 fps progressive and had been telecined to 29.97 fps interlaced, there will still be only motion for 24 fps after you bobbed it 60 fps ;)

Also a plain IVTC (Inverese Telecine) filter would simply fail to deinterlace a "true" interlaced video. But Decomb Telecide probably wouldn't fail, because it has additional post-processing.

Anyway, you can also post a short sample of your unprocessed(!) source and I'll tell you whether it's Telecined or not...

[TheImperial2004]

I used AviDemux to "Copy" 10MB of the video stream into a nice MPG container ^^ Everyday I love AviDemux even more ^^

Here (http://theimperial2004.googlepages.com/FFX7.mpg)

I used YADIF on this specific clip and I noticed that annoying scanning lines are gone and I saved around half the file size using the same x264 settings compared to encoding without deinterlacing ^^

BTW : Can't we just use YADIF to Deinterlace both types of streams ?

[LoRd_MuldeR]

BTW : Can't we just use YADIF to Deinterlace both types of streams ?

That would be the "dumb" method. If the video is Telecined, then the original(!) progressive frames can be reconstructed by an IVTC filter, just by putting together the fields in the proper way.

Since a deinterlacer like YADIF unavoidably interpolates, you'd be throwing away a lot of quality for no benefit! However if the video is "true" interlaced, then IVTC cannot be used and a dinterlacer is needed.

Your video appears to be interlaced. And it's full of ugly aliasing by the way! I bobbed it with YADIF:
http://www.mediafire.com/?nx43kztknrm

[TheImperial2004]

I bobbed it with YADIF and I got rid of the "scanning lines" and saved half the space .. That means YADIF got rid of the "useless" frames . No ?

What will happen if I just encoded the video using x264 without Deinterlacing it (In a tech. point of view) ?

P.S. : I didn't create this video , so blame S.E. ;)

[LoRd_MuldeR]

I bobbed it with YADIF and I got rid of the "scanning lines" and saved half the space .. That means YADIF got rid of the "useless" frames . No ?

No! Yadif will take each field and interpolate the "missing" lines to get a full frame.

This way we get from 29.97 interlaced frames per second (actually 59.940 fields per second) to 59.940 progressive frames per second.

Details: http://trac.handbrake.fr/wiki/yadif

What will happen if I just encoded the video using x264 without Deinterlacing it (In a tech. point of view) ?

If you encode interlaced video in progressive mode, the fields will be weaved together and treated as progressive, which actually destroys the content!

So if you want to retain the interlacing, you must encode in "interlaced" mode.

x264 does support interlaced encoding, but it's less efficient and it requires deinterlacing at playback time (given you are using an LCD screen or projector).

P.S. : I didn't create this video , so blame S.E. ;)

Okay, I do ;)

[LoRd_MuldeR]

libx264 SVN-r1239:

libx264-r1239, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1239M-gcc433-core2-fprofiled.7z)
libx264-r1239, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1239M-gcc433-amdfam10-fprofiled.7z)
libx264-r1239, MinGW GCC 4.3.3, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1239M-gcc433-pentium3-fprofiled.7z)
libx264-r1239, MinGW GCC 4.3.3, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1239M-gcc433-noasm-fprofiled.7z)


libx264 SVN-r1239 without MB-Tree Ratecontrol:

libx264-r1239, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1239M-nombtree-gcc433-core2-fprofiled.7z)
libx264-r1239, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1239M-nombtree-gcc433-amdfam10-fprofiled.7z)
libx264-r1239, MinGW GCC 4.3.3, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1239M-nombtree-gcc433-pentium3-fprofiled.7z)


libx264 SVN-r1239 with AutoVAQ enabled:

libx264-r1239, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1239M-autovaq-gcc433-core2-fprofiled.7z)
libx264-r1239, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1239M-autovaq-gcc433-amdfam10-fprofiled.7z)
libx264-r1239, MinGW GCC 4.3.3, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1239M-autovaq-gcc433-pentium3-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 5273 (http://forum.doom9.org/showpost.php?p=1319348&postcount=1246) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

I added a build with no ASM, because it seems that x264 r1233+ won't run on Non-SSE CPU's, unless I completely disable ASM...

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5281 (2009-08-29)
http://www.avidemux.org/

Revision 5281 (29 Aug 2009)
# Updated x264 r1240.

5281 - [cli] modify behaviour of save-jpg parameter to recognise selection (fixes #14)
5280 - [cli] signal that progress dialog is always alive for CLI since it isn't displayed and can't be aborted
5279 - [flux] correctly initialise fluxsmooth filter (regression introduced in 2.5.0; fixes #23)
5278 - [qt] add responder for cancel button on progress dialog (fixes #24)
5277 - [misc] remove dead code
5276 - [filter] reinstate partial filter support (fixes #28)
5275 - [Flv] Fix extraheader + offset in audio, fix #26
5274 - [Flv] Backport some code from 2.6 to allow new codecs in flv, refs #26
5273 - [ffmpeg] update FFmpeg to r19733 & libswscale r29569

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[TheImperial2004]

Updated x264 r1240.

What ??!! It is not available here (http://mplayer.somestuff.org/misc/libx264/) ! @_@

[LoRd_MuldeR]

What ??!! It is not available here (http://mplayer.somestuff.org/misc/libx264/) ! @_@

If you look at the x264 changelog (http://mirror01.x264.nl/x264/changelog.txt), you will see that there is no relevant difference between r1239 and r1240 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=35627b63c31bcd143413c10dce1ead8015448f7b) for us ;)

So the libx264 binary of r1240 probably would be bit-identical to r1239. Of course I'll make fresh builds as soon as there's a relevant change...

(Anyway, I can't make fresh builds day and night - only at night when I'm awake. So you may need to be patient sometimes ^^)

[LoRd_MuldeR]

libx264 SVN-r1243:

libx264-r1243, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1243M-gcc433-core2-fprofiled.7z)
libx264-r1243, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1243M-gcc433-amdfam10-fprofiled.7z)
libx264-r1243, MinGW GCC 4.3.3, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1243M-gcc433-pentium3-fprofiled.7z)
libx264-r1243, MinGW GCC 4.3.3, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-72-r1243M-gcc433-noasm-fprofiled.7z)


libx264 SVN-r1243 using four slices:

libx264-r1243, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1243M-slices-gcc433-core2-fprofiled.7z)
libx264-r1243, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1243M-slices-gcc433-amdfam10-fprofiled.7z)
libx264-r1243, MinGW GCC 4.3.3, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1243M-slices-gcc433-pentium3-fprofiled.7z)


libx264 SVN-r1243 with AutoVAQ enabled:

libx264-r1243, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1243M-autovaq-gcc433-core2-fprofiled.7z)
libx264-r1243, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1243M-autovaq-gcc433-amdfam10-fprofiled.7z)
libx264-r1243, MinGW GCC 4.3.3, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-72-r1243M-autovaq-gcc433-pentium3-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 5281 (http://forum.doom9.org/showpost.php?p=1319838&postcount=1262) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

Now with support for slices (http://img525.imageshack.us/img525/3856/slices.jpg), for details have a look at this (http://forum.doom9.org/showthread.php?p=1320574#post1320574) thread! Patched back to core 72 to make it work with current (http://forum.doom9.org/showpost.php?p=1319838&postcount=1262) Avidemux.

[LoRd_MuldeR]

Updated the builds in my previous post (http://forum.doom9.org/showpost.php?p=1320672&postcount=1265) with a more "safe" patch, I hope ;)

[TheImperial2004]

I understand that Slices is a feature for stand-alone players only , No ?

[LoRd_MuldeR]

I understand that Slices is a feature for stand-alone players only , No ?

Well, it's not only for standalone players. Multi-sliced streams allow slice-bases multithreading (instead of frame-based multithreading), which may be used by software decoders too.
Remember, there was a time not too long ago when libavcodec (this includes ffdshow and friends) only supported multithreaded decoding for multi-sliced H.264 streams.
However the most important reason why people need multi-sliced encoding nowadays is BluRay support. The BluRay specs require that 4+ slices must be used (at least for Level 4.1).

Anyway, the rule of thumb says: Don't use slices, unless you have a very good reason to do so. That's because slices hurt coding efficiency!

[Dark Shikari]

Well, it's not only for standalone players. Multi-sliced streams allow slice-bases multithreadingNot with x264's streams, which have deblocking on between slices. At least it won't work with ffmpeg.

[LoRd_MuldeR]

Not with x264's streams, which have deblocking on between slices. At least it won't work with ffmpeg.

I thought BluRay requires multiple slices in order to allow slice-based multithreading in the playback device. So now you are saying this won't work? Problem for the BD guys? :scared:

Or it just doesn't work with ffmpeg's implementation of slice-based multithreading? And what happens if I turn off deblocking ???

[Dark Shikari]

I thought BluRay requires multiple slices in order to allow slice-based multithreading in the playback device. So now you are saying this won't work? Problem for the BD guys?The BD specification does not require that the deblocking filter control be set to "2" (deblocking off between slices).

[TheImperial2004]

there was a time not too long ago when libavcodec (this includes ffdshow and friends) only supported multithreaded decoding for multi-sliced H.264 streams.

So , I can now rely on Libavcodec to decode 1080p-sliced contect with the same performance of FFMpeg-mt or CoreAVC ?

[LoRd_MuldeR]

So , I can now rely on Libavcodec to decode 1080p-sliced contect with the same performance of FFMpeg-mt or CoreAVC ?

Neither ffmpeg-MT nor CoreAVC need slices to enable multi-threaded decoding. You can safely turn off slices, if these are your decoders :)

Of course they would deal with slices just fine. But why use slices (and sacrifice some compression efficiency) when you have no valid reason to do so?

BluRay compliance would be a valid reason to encode with slices, but only if you are targeting for BluRay authoring...

The BD specification does not require that the deblocking filter control be set to "2" (deblocking off between slices).

But what are slices good for, if they can't be used for slice-based multithreading? Maybe the BD specs just missed that part? :confused:

[TheImperial2004]

Perhaps I didn't use the right words >_< Sorry ;)

Rephrase :

I use FFMpeg-mt to decode 1080p contect right now , because Libavcodec can't utilize both cores . You said that Libavcodec does support multi-threaded decoding for Sliced-Encoded contect . So , If I used Libx264 to create a-four-sliced-1080p-video , will Libavcodec decode that using both cores ?

[LoRd_MuldeR]

You said that Libavcodec does support multi-threaded decoding for Sliced-Encoded contect . So , If I used Libx264 to create a-four-sliced-1080p-video , will Libavcodec decode that using both cores ?

In theory yes. But it seems this won't work with x264-encoded streams, even if they are multi-sliced. See what Dark Shikari just explained...

http://forum.doom9.org/showpost.php?p=1321100&postcount=1269

[TheImperial2004]

In theory yes. But it seems this won't work with x264-encoded streams, even if they are multi-sliced. See what Dark Shikari just explained...

Is that an x264 restriction or Libavcodec's ?

[LoRd_MuldeR]

Is that an x264 restriction or Libavcode's ?

Ha, good question :D

Should x264 create sliced streams that don't have deblocking on between slices -or- should libavcodec be able to use slice-based multithreading even if deblocking is on between slices?

I assume a ffmpeg/libavcodec developer and a x264 developer would give different answer to this question ^^

[TheImperial2004]

Should x264 create sliced streams that don't have deblocking on between slices -or- should libavcodec be able to use slice-based multithreading even if deblocking is on between slices?


Let's wait and see how is this gonna unfold http://forum.doom9.org/images/smilies/biggrin.gif

[LoRd_MuldeR]

Let's wait and see how is this gonna unfold http://forum.doom9.org/images/smilies/biggrin.gif

Well, I assume nobody will care about this, because ffmpeg/libavcodec does support frame-based multithreading for quite some time now (in the ffmpeg-MT branch) and hence doesn't need slice-based multithreading any longer. Also the way x264 creates sliced steams seems to be sufficient for BD compliance. So actually there's no need to change anything right now...

[Guest]

Any 4-slice samples from x264 available? I'd like to test the Nvidia GPU decoder with it.

I know, wrong thread. Strike me. :)

[LoRd_MuldeR]

Any 4-slice samples from x264 available? I'd like to test the Nvidia GPU decoder with it.

I know, wrong thread. Strike me. :)

I can upload one, please wait a moment...

[LoRd_MuldeR]

Any 4-slice samples from x264 available? I'd like to test the Nvidia GPU decoder with it.

I know, wrong thread. Strike me. :)
I can upload one, please wait a moment...

Here we go:
http://www.mediafire.com/file/nlz11di0d3m/black_new_sliced.rar

[TheImperial2004]

in the ffmpeg-MT branch

I just wanted to use multi-threaded decoding with MPlayer SVN on Ubuntu . As it comes with FFMpeg not FFMpeg-MT . Since I mentioned that , I tried every procedure to compile MPlayer to use FFMpeg-MT to decode H.264 1080p , But I failed every time (Ubuntu) . It still uses only one core !

[LoRd_MuldeR]

I just wanted to use multi-threaded decoding with MPlayer SVN on Ubuntu . As it comes with FFMpeg not FFMpeg-MT . Since I mentioned that , I tried every procedure to compile MPlayer to use FFMpeg-MT to decode H.264 1080p , But I failed every time (Ubuntu) . It still uses only one core !

I can't really help you with compiling MPlayer on Ubuntu, but the MPlayer Mailing List (https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users) may be the appropriate place to ask for help with compilation problems.

MPlayer with FFmpeg-MT for Win32 is available here:
http://kovensky.project357.com/

[BigDid]

...
MPlayer with FFmpeg-MT for Win32 is available here:
http://kovensky.project357.com/
Hi,

And I confirm there are viewing problems for mpeg2 sources (only) with this MT build.

...
I know, wrong thread. Strike me. :)

Oh boy, already had a storm and rain yesterday, please no snow :D

did

[TheImperial2004]

I reverted back to Windows 7 just because of this very issue . They said that VLC has similar features to FFDShow , Multi-threading is not one of them though ... Nothing wants to work . I spent hours in checking and building from source , just to realize that it doesn't want to work !

MPlayer with FFmpeg-MT for Win32 is available here

I use FFDShow with MT under Windows and that is pretty good ^_^ I was woundering about Linux .. We've got an excellent Video Editing / Encoding program that can run "natively" under Linux which is AviDemux ;) Too shame that we don't have a fast decoder like FFDShow !

[LoRd_MuldeR]

Too shame that we don't have a fast decoder like FFDShow !

FFdshow basically is a wrapper to make ffmpeg/libavcodec available for DirectShow applications under Windows. However be aware that FFmpeg(-MT) originates from the Linux world ;)

I agree that the Linux distributions available nowadays make it very easy to get a running Linux system and ship with a lot of useful software (and software that isn't included can be obtained easily through the package manger). BUT: As soon as you want some software or driver (or even some "development" version) that is Non-standard for your current Linux distribution, things become very nasty again. You need to compile the stuff yourself, which means that you must be willing to do a lot of experimenting, read through more or less up-to-date guides, ask for help in forums and so on...

[Poutnik]

Is possible in Avidemux 2.5.1 to add a job to process queue in already running joblist ?
E.g. from other Avidemux instance ?

[LoRd_MuldeR]

Is possible in Avidemux 2.5.1 to add a job to process queue in already running joblist ?
E.g. from other Avidemux instance ?

I don't think so...

[TheImperial2004]

Its been quite a while since the last Windows build came out , I hope that gruntster is fine :)

[Poutnik]

I don't think so...

What a pity... :) it would be handy.

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5327 (2009-09-09)
http://www.avidemux.org/

Revision 5327 (09 Sep 2009)
# Updated x264 to r1251.

5327 - [xvid] destroy xvid context after each pass
5295 - [FLV] inverted check in audioEncoder, made flv output crash
5294 - [cmake] fix x264 detection
5293 - [cmake] detect new x264 api
5292 - [cmake] add pthread include directory where required
5283 - [Plugins] Build patch from D. Kapusta, cleanup the lib/lib32/lib64 mess
5282 - [Build] Patch from D. Kapusta that fixes a couple of loose ends + enable plugin build with the need to install main by symlinking the libs into the lib dir
5281 - [cli] modify behaviour of save-jpg parameter to recognise selection (fixes #14)

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[TheImperial2004]

Wow Thanks ! Will we expect new customized x264 builds soon ?

[LoRd_MuldeR]

Wow Thanks ! Will we expect new customized x264 builds soon ?

In progress...

[LoRd_MuldeR]

libx264 SVN-r1251:

libx264-r1251, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1251M-gcc433-core2-fprofiled.7z)
libx264-r1251, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1251M-gcc433-amdfam10-fprofiled.7z)
libx264-r1251, MinGW GCC 4.3.3, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1251M-gcc433-pentium3-fprofiled.7z)
libx264-r1251, MinGW GCC 4.3.3, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1251M-gcc433-noasm-fprofiled.7z)


libx264 SVN-r1251 using four slices:

libx264-r1251, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1251M-slices-gcc433-core2-fprofiled.7z)
libx264-r1251, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1251M-slices-gcc433-amdfam10-fprofiled.7z)
libx264-r1251, MinGW GCC 4.3.3, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1251M-slices-gcc433-pentium3-fprofiled.7z)


libx264 SVN-r1251 with AutoVAQ enabled:

libx264-r1251, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1251M-autovaq-gcc433-core2-fprofiled.7z)
libx264-r1251, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1251M-autovaq-gcc433-amdfam10-fprofiled.7z)
libx264-r1251, MinGW GCC 4.3.3, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1251M-autovaq-gcc433-pentium3-fprofiled.7z)


libx264 SVN-r1251 with MB-Tree disabled:

libx264-r1251, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1251M-nombtree-gcc433-core2-fprofiled.7z)
libx264-r1251, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1251M-nombtree-gcc433-amdfam10-fprofiled.7z)
libx264-r1251, MinGW GCC 4.3.3, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1251M-nombtree-gcc433-pentium3-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5327 (http://forum.doom9.org/showpost.php?p=1323744&postcount=1292) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

Now with Threaded Lookahead (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=5b3c89c592e412fc02fd8001ee361ea50c249153) which greatly increases performance with lookahead-intensive settings. This is enabled by default.

[TheImperial2004]

Thanks Mulder !

BTW , I have a question !

Is AutoVAQ always enabled (Now that its officially commited) ? And how to revert to normal VAQ ?

In these builds :

libx264 SVN-r1251:
libx264-r1251, MinGW GCC 4.3.3, optimized for Core 2
libx264-r1251, MinGW GCC 4.3.3, optimized for K10
libx264-r1251, MinGW GCC 4.3.3, optimized for Pentium III
libx264-r1251, MinGW GCC 4.3.3, without ASM (slow!)

[lych_necross]

Thanks Mulder !

BTW , I have a question !

Is AutoVAQ always enabled (Now that its officially commited) ? And how to revert to normal VAQ ?

In these builds :
No. AutoVAQ is only enabled on Avidemux using Mulder's patched x264 build. I guess you could enable AutoVAQ using Avidemux's scripting capabilities, but thats OT. All other builds of x264 do not enable AutoVAQ by default.

[LoRd_MuldeR]

No. AutoVAQ is only enabled on Avidemux using Mulder's patched x264 build.

Correct. Since Avidemux doesn't offer any option to enable AutoVAQ currently the only way to get AutoVAQ in Avidemux is using the patched build.

But even with the AutoVAQ patched build, AutoVAQ will only be used (instead of "normal" VAQ), if AQ is enabled in the GUI.

So you can still disable AQ entirely, which of course would not a very good idea :eek:

(Also note that AutoVAQ has been offically committed, but is not the new default. x264's default AQ mode still is the "normal" VAQ algorithm)

I guess you could enable AutoVAQ using Avidemux's scripting capabilities, but thats OT.

I don't think so. Avidemux scripting engine uses XML syntax to load or save encoder configuration.

But there's just no option for AutoVAQ in the Schema (http://en.wikipedia.org/wiki/XML_Schema_(W3C)) yet. The "adaptiveQuantiserMode" element only allows "none" or "variance" ;)

We'll have to wait for Gruntster to update Avimdeux and include all the new x264 options. This will be some work, I guess...

<xs:element name="adaptiveQuantiserMode" minOccurs="0">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="variance"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

[lych_necross]

I don't think so. Avidemux scripting engine uses XML syntax to load or save encoder configuration.

But there's just no option for AutoVAQ in the Schema (http://en.wikipedia.org/wiki/XML_Schema_(W3C)) yet. The "adaptiveQuantiserMode" element only allows "none" or "variance" ;)

We'll have to wait for Gruntster to update Avimdeux and include all the new x264 options. This will be some work, I guess...

Darn it. I take it one just can't modify the schema to allow for this.

[LoRd_MuldeR]

Darn it. I take it one just can't modify the schema to allow for this.

Well, you could probably hack the XML Schema file to make the XML Parser accept additional values for the "adaptiveQuantiserMode" element (e.g. "autoVariance"), but this doesn't mean that the application can actually interpret those values correctly and pass the corresponding parameters to x264. Unless Avidemux (or at least the x264 Plugin) is updated, there's no way around a patched x264 library...

[TheImperial2004]

No. AutoVAQ is only enabled on Avidemux using Mulder's patched x264 build
Also note that AutoVAQ has been offically committed, but is not the new default. x264's default AQ mode still is the "normal" VAQ algorithm

I see , the default remains VAQ in the primary code . Only AutoVAQ builds uses it as default instead of VAQ ;)

:thanks: to both of you ;)

[LoRd_MuldeR]

libx264 SVN-r1259:

libx264-r1259, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1259M-gcc433-core2-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1259M-gcc433-amdfam10-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.3, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1259M-gcc433-pentium3-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.3, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1259M-gcc433-noasm-fprofiled.7z)


libx264 SVN-r1259 using four slices:

libx264-r1259, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-slices-gcc433-core2-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-slices-gcc433-amdfam10-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.3, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-slices-gcc433-pentium3-fprofiled.7z)


libx264 SVN-r1259 with AutoVAQ enabled:

libx264-r1259, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-autovaq-gcc433-core2-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-autovaq-gcc433-amdfam10-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.3, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-autovaq-gcc433-pentium3-fprofiled.7z)


libx264 SVN-r1259 with MB-Tree disabled:

libx264-r1259, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-nombtree-gcc433-core2-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-nombtree-gcc433-amdfam10-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.3, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-nombtree-gcc433-pentium3-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5327 (http://forum.doom9.org/showpost.php?p=1323744&postcount=1292) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

This build fixes the crash that occured when the encode was aborted prematurely. It turns out that was a x264 bug. Fixed in r1253.

[Chikuzen]

I am using mulder 's latest buid(r5327) on Windows7RC_x64(build7100).
When I tried to use the Audio->MainTrack->AudioSource-External MP3,I got an message.
"Cannnot load The selected audio file does not exist."
I investigated this for about ten minutes, and found an answer.
The cause of this error was to have used Japanese(multibyte) characters for the filename.
I hope to come to be able to use multibyte characters also for the audio file as well as the video file:)

[LoRd_MuldeR]

I am using mulder 's latest buid(r5327) on Windows7RC_x64(build7100).
When I tried to use the Audio->MainTrack->AudioSource-External MP3,I got an message.
"Cannnot load The selected audio file does not exist."
I investigated this for about ten minutes, and found an answer.
The cause of this error was to have used Japanese(multibyte) characters for the filename.
I hope to come to be able to use multibyte characters also for the audio file as well as the video file:)

You should report this at the Avidemux forum. So the devs may possibly fix it ;)

http://avidemux.org/admForum/

[Chikuzen]

You should report this at the Avidemux forum. So the devs may possibly fix it ;)

http://avidemux.org/admForum/

okay.
I reported on this to Avidemux forum. :thanks:

[LoRd_MuldeR]

I reported on this to Avidemux forum. :thanks:

Fixed r5329.

That was quick :)

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5341 (2009-09-17)
http://www.avidemux.org/

Revision 5341 (17 Sep 2009)
# Updated x264 to r1259.

5341 - [win32] include new colour curve editor filter in Windows installer
5340 - [ffmpeg] update FFmpeg to r19894 & libswscale r29686
5338 - [MKV] Add another alias for AAC
5333 - [plugin] Curve editor, by janec
5332 - [mkv] Derive frame type while indexing (merge from 2.6)
5331 - [mkv] Derive frame type while indexing (merge from 2.6)
5330 - [win32] fix mpeg muxer to handle unicode file names (fixes #38)
5329 - [win32] handle unicode names when checking for file existence
5328 - [Po] Polish translation by Aleksander Łukasiewicz
5327 - [xvid] destroy xvid context after each pass

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[lansing]

could there be a 3 way color wheel like the one in sony vegas for tuning color? It's a very good tool for color correction on old anime.

http://img132.imageshack.us/img132/4517/colorwheelu.png

[TheImperial2004]

could there be a 3 way color wheel like the one in sony vegas for tuning color? It's a very good tool for color correction on old anime.

I guess that you should make a "feature request" at AviDemux's official forums (http://avidemux.org/admForum/viewforum.php?id=18) ;)

[Brazil2]

libx264 SVN-r1259: libx264-r1259, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1259M-gcc433-core2-fprofiled.7z)
This build fixes the crash that occured when the encode was aborted prematurely. It turns out that was a x264 bug. Fixed in r1253.
Unfortunately it still crashes Avidemux if I abort the encoding (H264 + AAC in MP4).
Using Avidemux SVN Build 5341 on Windows XP Pro 32 bits.

[Dark Shikari]

Fixed in r1267 (http://git.videolan.org/?p=x264.git;a=commit;h=c62060d242879d8271c22a486b286b91147d2ebf).

[LoRd_MuldeR]

Fixed in r1267 (http://git.videolan.org/?p=x264.git;a=commit;h=c62060d242879d8271c22a486b286b91147d2ebf).

Too bad this was fixed after the major API change :D

[LoRd_MuldeR]

libx264 SVN-r1259:

libx264-r1259, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1259M-gcc434-core2-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1259M-gcc434-amdfam10-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1259M-gcc434-pentium3-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.4, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1259M-gcc434-noasm-fprofiled.7z)


libx264 SVN-r1259 using four slices:

libx264-r1259, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-slices-gcc434-core2-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-slices-gcc434-amdfam10-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-slices-gcc434-pentium3-fprofiled.7z)


libx264 SVN-r1259 with AutoVAQ enabled:

libx264-r1259, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-autovaq-gcc434-core2-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-autovaq-gcc434-amdfam10-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-autovaq-gcc434-pentium3-fprofiled.7z)


libx264 SVN-r1259 with MB-Tree disabled:

libx264-r1259, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-nombtree-gcc434-core2-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-nombtree-gcc434-amdfam10-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-nombtree-gcc434-pentium3-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5327 (http://forum.doom9.org/showpost.php?p=1323744&postcount=1292) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

I re-compiled r1259, this time with the "real" fix for the encoder_close crash. Cannot provide builds of r1260 or later for Avidemux yet.

[Brazil2]

libx264 SVN-r1259:
libx264-r1259, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1259M-gcc434-core2-fprofiled.7z)
libx264 SVN-r1259 with MB-Tree disabled:
libx264-r1259, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-nombtree-gcc434-core2-fprofiled.7z)

I re-compiled r1259, this time with the "real" fix for the encoder_close crash. Cannot provide builds of r1260 or later for Avidemux yet.
I've done some quick tests with the above builds, still with Avidemux SVN Build 5341 on Windows XP 32 bits and a Core2Duo, and the patch seems to work so far, no crashes anymore on abort.

Thanks :)

[wata]

using libx264 SVN-r1259 with MB-Tree disabled, why is the result file psy_rd=1.00:0.15 instead of psy_rd=1.0:0.0

[LoRd_MuldeR]

using libx264 SVN-r1259 with MB-Tree disabled, why is the result file psy_rd=1.00:0.15 instead of psy_rd=1.0:0.0

Because that's what the "--tune film" option does in the x264 command-line encoder. It should help to preserve more detail!

Unfortunately in Avidemux there are no GUI options to control Psy-Trellis, so I use a simple patch (http://mplayer.somestuff.org/misc/libx264/patches/psy_trellis.diff) for libx264 that changes the default Psy-Trellis from 0.0 to 0.15 ;)

(Note: You can still disable Psy-Trellis by setting Trellis to "0" in the Avidemx configuration dialog)

Also you shouldn't use the "MB-Tree disabled" build, except for testing purposes. The new MB-Tree RC greatly improves the overall quality in many situations...

[wata]

i am not ready to test/try new stuff yet
anyway i go back to avidemux_2.5_r5104_full_win32.zip, which use the same version of x264 as current megui (r1183)
i grab your compile of r1183 for core2 cpu, again Psy-Trellis increase from 0.0 to 0.15
it may help to preserve more detail but at the same time filesize increase too (5-6%) with the same crf.

[LoRd_MuldeR]

anyway i go back to avidemux_2.5_r5104_full_win32.zip, which use the same version of x264 as current megui (r1183)

You shouldn't use that outdated version! Get Avidemux r5341, it ships with an unpatched and (almost) up-to-date libx264 build ;)

Also MeGUI uses x264 r1259 now. If your MeGUI doesn't update via auto-update you probably didn't adjust the update URL to the new server.

http://kurtnoise.free.fr/MeGUI/

i grab your compile of r1183 for core2 cpu, again Psy-Trellis increase from 0.0 to 0.15

Yes, that's exactly how it is supposed to be. However you should grab the r1259 build now!

it may help to preserve more detail but at the same time filesize increase too (5-6%) with the same crf.

It has been explained about one million times why CRF can not be used as a "quality -vs- size" measure :rolleyes:

If you get a bigger file and better quality, how do you want to decided whether the increase in file size was worth the increase in quality or not ???

Yes, you can't :eek:

So if you want to compare setting A against setting B (e.g. Psy-Trellis 0.15 -vs- 0.0), you must visually compare files of identical size. So use 2-Pass mode for this kind of test!

And if it turns out that Psy-Trellis gives better quality at same size (which it probably will!), then that means Psy-Trellis will improve your encode in CRF mode as well.

However you may need to adjust your CRF value. But that's perfectly normal! CRF did always change when you change other settings ;)

In other words: With Psy-Trellis enabled and your CRF value properly re-adjusted, you should be able to get better quality at same size -or- same quality at an even lower size.

This applies to "filmic" content (and similar) at least. Psy-Trellis seems to be less suitable for "animated" content...

[w0rd™]

I've got 2.51 installed, just downloaded 2.51r5341, before I run it, just wondering about a few quick things, thought I might ask here.

If I have some xvid avi files, and I cut them in avidemux, and leave vid/audio same, but change container to .mkv, does that do anything, or just basically changes the extension to mkv, like one could do within windows?

Also, is there another way to create a job list, does one always have to fill out the file name, file extension and save location manually, for every file added?
It's just usually with other programs that have batch processing, it usually automatically inputs the same file name+extension, and remembers last save folder, but avidemux doesn't seem to do this. It could take a while to do this for many files.


Thanks.

[LoRd_MuldeR]

If I have some xvid avi files, and I cut them in avidemux, and leave vid/audio same, but change container to .mkv, does that do anything, or just basically changes the extension to mkv, like one could do within windows?

Of course it does do something! And nope, it does not just change the extension!

Changing the extension can be done in Explorer using the "rename" function. But renaming an AVI file to "foo.mkv" doesn't make it an MKV file. It's still an AVI file, only with "wrong" extension :sly:

However if you open an existing AVI file in Avidemux and then save it to an MKV file (that means "Format" is set to "MKV" in the left side menu), then it will be properly re-muxed to a MKV container.

Re-muxing doesn't change the video (it won't re-encode!), but will change the container. In this case from AVI to Matroska (MKV).

Also, is there another way to create a job list, does one always have to fill out the file name, file extension and save location manually, for every file added?
It's just usually with other programs that have batch processing, it usually automatically inputs the same file name+extension, and remembers last save folder, but avidemux doesn't seem to do this. It could take a while to do this for many files.

Avidemux does offer powerful scripting capabilities. See the Avidemux Wiki for details please!

Command-Line usage:
http://avidemux.org/admWiki/index.php?title=Command_line_usage

Scripting:
http://avidemux.org/admWiki/index.php?title=Scripting

Scripting Tutorial:
http://avidemux.org/admWiki/index.php?title=Scripting_tutorial

[w0rd™]

Thanks LM.

I knew that changing extension in Explorer just changes the name and not the actual type, that's why I was curious about Ademux if it remuxed into an actual mkv.
I read that it's better to use mkv instead of avi for xvid/mp3, so that why I want to remux them all at the same time as I have to cut out bits of each video anyway, so I'm hoping its true.



About the scripting, that really is out of my depth, that's why I use the GUI. Even though I don't really understand it, I couldn't tell where it mentions auto filling a job control, or maybe that's just because I couldn't understand much :o

I'm basically really wanting it to act like the VDub job control.
That is, I open clip1.avi, edit out the cuts, choose save, and it automatically adds "clip1.avi" as the filename(or mkv if chosen) and opens the last folder, so basically one just have to press the save button (adding it to the job list).

If there's a simple method using scripts, that maybe I could follow, specifically to autofill the filenames of the clip opened, and the destination, from within the GUI, then it would be great.

Would be even better if something like the vdub method could be added to the gui, just as the basic method, but then again, I wouldn't know how software works behind the scenes :cool:

[LoRd_MuldeR]

I knew that changing extension in Explorer just changes the name and not the actual type, that's why I was curious about Ademux if it remuxed into an actual mkv.
I read that it's better to use mkv instead of avi for xvid/mp3, so that why I want to remux them all at the same time as I have to cut out bits of each video anyway, so I'm hoping its true.

MPEG-4 ASP (Xvid, DivX, etc) video and MP3 audio in an AVI container is perferctly fine. In fact it's the preferred combination, even for hardware playback!
Older standalone players often support the AVI container, but do not support the MKV or MP4 container!

H.264/AVC (e.g. x264) is a different story. It can be stored in AVI and with software players there usually is no problem at all.
However for hardware players H.264 must be stored in MP4, M2TS or MKV container. Support for MKV in standalones is getting more widespread now...

Anyway, for re-muxing AVI files to MKV I would use MKVToolnix (http://www.videohelp.com/tools/MKVtoolnix) instead of Avidemux ;)

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5369 (2009-10-05)
http://www.avidemux.org/

Revision 5369 (05 Oct 2009)
# Updated ATK to version 1.28.0-1.
# Updated Fontconfig to version 2.7.3-1.
# Updated GLib to version 2.22.1-1.
# Updated GTK+ to version 2.18.1-1.
# Updated libpng to version 1.2.39-1.
# Updated Libxml2 to version 2.7.4-1.
# Updated NSPR to version 4.8.
# Updated opencore-amr to version 0.1.2.
# Updated Qt to version 4.5.3.
# Updated x264 to r1271.

5369 - [win32] update installer to support latest dependencies
5362 - [macosx] build script tweaks by surfer
5361 - [x264] compilation fix for older API
5360 - [x264] support API version 76
5359 - [PO] SR translation by popac
5358 - [macosx] keep original ffmpeg library names on Mac
5350 - [backtrace] Better backtrace using glibc functions (backport from 2.6)
5349 - [Video/Filters] Move convolution filter to the sharpness category, closes #10
5348 - [Filter/Field] Cleanup/rename filters, ref #10
5347 - [macosx] fix reference to icon file
5341 - [win32] include new colour curve editor filter in Windows installer

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1271:

libx264-r1271, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1271M-gcc434-core2-fprofiled.7z)
libx264-r1271, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1271M-gcc434-amdfam10-fprofiled.7z)
libx264-r1271, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1271M-gcc434-pentium3-fprofiled.7z)
libx264-r1271, MinGW GCC 4.3.4, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1271M-gcc434-noasm-fprofiled.7z)


libx264 SVN-r1271 using four slices:

libx264-r1271, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1271M-slices-gcc434-core2-fprofiled.7z)
libx264-r1271, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1271M-slices-gcc434-amdfam10-fprofiled.7z)
libx264-r1271, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1271M-slices-gcc434-pentium3-fprofiled.7z)


libx264 SVN-r1271 with AutoVAQ enabled:

libx264-r1271, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1271M-autovaq-gcc434-core2-fprofiled.7z)
libx264-r1271, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1271M-autovaq-gcc434-amdfam10-fprofiled.7z)
libx264-r1271, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1271M-autovaq-gcc434-pentium3-fprofiled.7z)


libx264 SVN-r1271 with MB-Tree disabled:

libx264-r1271, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1271M-nombtree-gcc434-core2-fprofiled.7z)
libx264-r1271, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1271M-nombtree-gcc434-amdfam10-fprofiled.7z)
libx264-r1271, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1271M-nombtree-gcc434-pentium3-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5369 (http://forum.doom9.org/showpost.php?p=1331731&postcount=1323) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

Avidemux has been updated for the new x264 API (http://forum.doom9.org/showthread.php?t=149593), finally. Please update Avidemux before installing the core-76 builds of libx264!

[boyumeow]

Hi LRMR, I have a small little question for U... I think I understand that ur compiled libx264 (the 2nd, 3rd and 4th) is with some added modification, how about the first 1 listed, what does or does it not contains? I'm not sure U might have explain it before but I think I missed it. Sorry about my english if U do not understand, I believe sometimes or most of the time I have problem in explaining to people in written words. Thanks.

[LoRd_MuldeR]

Hi LRMR, I have a small little question for U... I think I understand that ur compiled libx264 (the 2nd, 3rd and 4th) is with some added modification, how about the first 1 listed, what does or does it not contains? I'm not sure U might have explain it before but I think I missed it. Sorry about my english if U do not understand, I believe sometimes or most of the time I have problem in explaining to people in written words. Thanks.

Each download (7z file) contains a "patches.tar" file that contains all the patches I used for the individual build. Just have a look ;)

Anyway, these patches are used in all of my builds:
fast_firstpass.diff: Do exactly what x264.exe does, if the "--slow-firstpass" param isn't specify. Speeds up the first pass of a 2-Pass encode significantly.
print_params.diff: Make x264 be more verbose on the Avidemux log. This is especially useful if people are submitting Avidemux crash log files and ask for help.
psy_trellis.diff: Raise the default Psy-Trellis strength from 0.0 to 0.15. This is the same that will happen if you use x264.exe's "--tune film" parameter.

These patches are only used in some of my builds and only when explicitly stated:
no_mbtree.diff: Disable the MB-Tree Rate Control. Enabled by default.
four slices.diff: Encode with four slices. Default is one (multi-slices disabled).
auto_vaq.diff: Use AutoVAQ instead of "normal" VAQ, iff AQ is enabled.

I recommend going with one of the builds from the first list (hint: pick the one that suits your CPU best). The other builds are intended for testing purposes.

Multiple slices are mainly interesting for BD authoring, AutoVAQ is an alternative (but not always better) AQ algorithm and disabling MB-Tree RC will use the "old" RC algorithm.

Please note: If Avidemux did offer all those options at run-time, we wouldn't need various builds. But it does not do so yet, so we need those patches...

[Brazil2]

Multiple slices are mainly interesting for BD authoring
But in this specific case isn't NAL_HRD required as well ?

[LoRd_MuldeR]

But in this specific case isn't NAL_HRD required as well ?

Yes, NAL_HRD would be required for full BD compatibility too, but x264 can not do it yet. So let's wait for the commit ;)

I know there's an experimental NAL_HRD patch floating around, but according to the devs, 100% correct NAL_HRD is only possible after the latest x264 API change.

As far as I know, the "old" patch was not updated for the "new" API yet, although some people made a working build somehow. Good? Well, I will simply wait...

[LoRd_MuldeR]

libx264 SVN-r1278:

libx264-r1278, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc434-core2-fprofiled.7z)
libx264-r1278, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc434-amdfam10-fprofiled.7z)
libx264-r1278, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc434-pentium3-fprofiled.7z)
libx264-r1278, MinGW GCC 4.3.4, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc434-noasm-fprofiled.7z)


libx264 SVN-r1278 using four slices:

libx264-r1278, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-slices-gcc434-core2-fprofiled.7z)
libx264-r1278, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-slices-gcc434-amdfam10-fprofiled.7z)
libx264-r1278, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-slices-gcc434-pentium3-fprofiled.7z)


libx264 SVN-r1278 with AutoVAQ enabled:

libx264-r1278, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-autovaq-gcc434-core2-fprofiled.7z)
libx264-r1278, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-autovaq-gcc434-amdfam10-fprofiled.7z)
libx264-r1278, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-autovaq-gcc434-pentium3-fprofiled.7z)


libx264 SVN-r1278 with MB-Tree disabled:

libx264-r1278, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-nombtree-gcc434-core2-fprofiled.7z)
libx264-r1278, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-nombtree-gcc434-amdfam10-fprofiled.7z)
libx264-r1278, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-nombtree-gcc434-pentium3-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5369 (http://forum.doom9.org/showpost.php?p=1331731&postcount=1323) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

[Brazil2]

Are there any BT.709 <-> BT.601 conversion filters available for Avidemux ? And if so where can I find them ?

[LoRd_MuldeR]

The "Avisynth ColorYUV" filter should be able to do that, I think ;)

[Brazil2]

The "Avisynth ColorYUV" filter should be able to do that, I think ;)
That looks nice but I can't figure how to make a simple BT.709 -> BT.601 conversion with this filter. And yes, I've read the documentation about ColorYUV.
Any tips are welcome :)

[LoRd_MuldeR]

libx264 SVN-r1278:

libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc441-core2-fprofiled.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc441-amdfam10-fprofiled.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc441-pentium3-fprofiled.7z)
libx264-r1278, MinGW GCC 4.4.1, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc441-noasm-fprofiled.7z)


libx264 SVN-r1278 using four slices:

libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-slices-gcc441-core2-fprofiled.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-slices-gcc441-amdfam10-fprofiled.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-slices-gcc441-pentium3-fprofiled.7z)


libx264 SVN-r1278 with AutoVAQ enabled:

libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-autovaq-gcc441-core2-fprofiled.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-autovaq-gcc441-amdfam10-fprofiled.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-autovaq-gcc441-pentium3-fprofiled.7z)


libx264 SVN-r1278 with MB-Tree disabled:

libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-nombtree-gcc441-core2-fprofiled.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-nombtree-gcc441-amdfam10-fprofiled.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-nombtree-gcc441-pentium3-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5369 (http://forum.doom9.org/showpost.php?p=1331731&postcount=1323) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

Re-compiled r1278 with GCC 4.4.1 TDM-2 (http://www.tdragon.net/recentgcc/), which is supposed to fix the "increased CPU usage" bug in TDM's previous GCC 4.4.1 release.

[Brazil2]

Are there any advantages with these new builds compiled with GCC 4.4.1 compared to the previous ones that you have compiled with GCC 4.3.4 since it's the same version of x264 ?

[LoRd_MuldeR]

Well, newer compiler versions hopefully produce (slightly) faster code and/or fix bugs of earlier compiler versions. But ideally there's no noteworthy difference for the user ;)

Unfortunately there is always the risk of regressions/miscompilation, so use the "new" builds with care and report any problems you may encounter...

[LoRd_MuldeR]

libx264 SVN-r1278:

libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc441-core2-fprofiled.try-2.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc441-amdfam10-fprofiled.try-2.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc441-pentium3-fprofiled.try-2.7z)
libx264-r1278, MinGW GCC 4.4.1, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc441-noasm-fprofiled.try-2.7z)


libx264 SVN-r1278 using four slices:

libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-slices-gcc441-core2-fprofiled.try-2.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-slices-gcc441-amdfam10-fprofiled.try-2.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-slices-gcc441-pentium3-fprofiled.try-2.7z)


libx264 SVN-r1278 with AutoVAQ enabled:

libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-autovaq-gcc441-core2-fprofiled.try-2.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-autovaq-gcc441-amdfam10-fprofiled.try-2.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-autovaq-gcc441-pentium3-fprofiled.try-2.7z)


libx264 SVN-r1278 with MB-Tree disabled:

libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-nombtree-gcc441-core2-fprofiled.try-2.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-nombtree-gcc441-amdfam10-fprofiled.try-2.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-nombtree-gcc441-pentium3-fprofiled.try-2.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5369 (http://forum.doom9.org/showpost.php?p=1331731&postcount=1323) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

Re-compiled r1278 with GCC 4.4.1, again. This time I included a patch (http://pastebin.ca/1612400) to avoid miscompilation with GCC 4.4.x, as suggested here (http://forum.doom9.org/showthread.php?p=1333035#post1333035).
So if you used one of the previous GCC 4.4.1 builds, then you are urged to update now!
I'm not sure whether the GCC 4.3.4 or GCC 4.3.3 builds were effected too, as the visual difference is generally unnoticeable...

[Brazil2]

Well, newer compiler versions hopefully produce (slightly) faster code and/or fix bugs of earlier compiler versions. But ideally there's no noteworthy difference for the user ;)
I've done some tests and I can't notice any speed difference between "libx264-r1278, MinGW GCC 4.3.4, optimized for Core 2 (http://forum.doom9.org/showpost.php?p=1332340&postcount=1329)" and "libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://forum.doom9.org/showpost.php?p=1333497&postcount=1336)".

There is however a huge speed difference between Avidemux 2.5 using "libx264-r1173, MinGW GCC 4.4.0, optimized for Core 2 (http://forum.doom9.org/showpost.php?p=1300329&postcount=1162)" and Avidemux 2.5.1 SVN-r5369 using any of your libx264 SVN-r1278 optimized for Core 2 builds with MB-Tree disabled.
For instance, with the same given source and the exact same settings Avidemux 2.5 is encoding at about 14 fps average while Avidemux 2.5.1 is encoding at about 10 fps average. Although I've noticed a short delay at the beginning of the encoding with v2.5.1 before the counters start to run while it's instant with v2.5. Maybe because of the lookahead ? But I thought this feature was related to MB-Tree only, I might be wrong though.


And I have some improvement suggestions for future versions of Avidemux:
Port ColorMatrix to Avidemux filters
Accept MP2 as an allowed format for external audio track
Allow AC3 to be muxed in MP4

[LoRd_MuldeR]

I've done some tests and I can't notice any speed difference between "libx264-r1278, MinGW GCC 4.3.4, optimized for Core 2 (http://forum.doom9.org/showpost.php?p=1332340&postcount=1329)" and "libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://forum.doom9.org/showpost.php?p=1333497&postcount=1336)".

Not surprising!

Or did you really expect an enormous speed-up between GCC 4.3.4 and 4.4.1? If at all, we can expect a very subtle speed-up from compiler optimizations ;)

All the performance-critical code in x264 is hand-optimized ASM anyway...

There is however a huge speed difference between Avidemux 2.5 using "libx264-r1173, MinGW GCC 4.4.0, optimized for Core 2 (http://forum.doom9.org/showpost.php?p=1300329&postcount=1162)" and Avidemux 2.5.1 SVN-r5369 using any of your libx264 SVN-r1278 optimized for Core 2 builds with MB-Tree disabled.
For instance, with the same given source and the exact same settings Avidemux 2.5 is encoding at about 14 fps average while Avidemux 2.5.1 is encoding at about 10 fps average. Although I've noticed a short delay at the beginning of the encoding with v2.5.1 before the counters start to run while it's instant with v2.5. Maybe because of the lookahead ? But I thought this feature was related to MB-Tree only, I might be wrong though.

Are you sure you are really using identical settings ???

In my latest builds there are workarounds to use even "slower" settings than those available in Avidemux. Those are triggered by certain combinations ;)

Please use Avinaptic or MediaInfo to read out the actual x264 settings from the encoded file!

BTW: The startup delay is caused by MB-Tree and/or Threaded Look-ahead. That's perfectly normal. It just didn't exist in older x264 builds.

And I have some improvement suggestions for future versions of Avidemux:
Port ColorMatrix to Avidemux filters
Accept MP2 as an allowed format for external audio track
Allow AC3 to be muxed in MP4

You better put feature requests to the official Avidemux board. The developers won't hear you here...

[Brazil2]

Are you sure you are really using identical settings ???
I've made a profile that I'm using with both versions.


In my latest builds there are workarounds to use even "slower" settings than those available in Avidemux. Those are triggered by certain combinations ;)

Please use Avinaptic or MediaInfo to read out the actual x264 settings from the encoded file!
Ah yep, subme=9 with r1173 and subme=10 with r1278. I guess that's one of your workarounds since the GUI doesn't allow to select subme=10 yet :)


BTW: The startup delay is caused by MB-Tree and/or Threaded Look-ahead. That's perfectly normal. It just didn't exist in older x264 builds.
As I've said I've used the NON MB-Tree build for the comparison because there was no MB-Tree in older builds, obviously.
The subme might explain the speed difference but where the short delay comes from ?
mbtree=0 and there is no rc_lookahead shown in the encoding settings.


You better put feature requests to the official Avidemux board. The developers won't hear you here...
No offense but these forums look like a no man's land to me so maybe I'll have more luck talking to one of the saints who can talk to God himself ;)

[DarkZell666]

No offense but these forums look like a no man's land to me so maybe I'll have more luck talking to one of the saints who can talk to God himself ;)

Not having 1000's of posts per day doesn't mean it's dead :rolleyes:. There are new topics and answers every day :)

[LoRd_MuldeR]

Ah yep, subme=9 with r1173 and subme=10 with r1278. I guess that's one of your workarounds since the GUI doesn't allow to select subme=10 yet :)

SubME=9 + Trellis=2 + ME=UMH (or higher) will trigger SubME=10 in my builds. That explains the speed-difference indeed.

As I've said I've used the NON MB-Tree build for the comparison because there was no MB-Tree in older builds, obviously.
The subme might explain the speed difference but where the short delay comes from ?
mbtree=0 and there is no rc_lookahead shown in the encoding settings.

Threaded Lookahead (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=5b3c89c592e412fc02fd8001ee361ea50c249153) is enabled, even with MB-Tree RC disabled. Right?

No offense but these forums look like a no man's land to me so maybe I'll have more luck talking to one of the saints who can talk to God himself ;)

Both, Mean and Gruntster, are visiting the Avidemux board regularly. So that's your best chance to get any feature requests done ;)

There also is a non-public bug tracker that is maintained!

[LoRd_MuldeR]

libx264 SVN-r1286:

libx264-r1286, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1286M-gcc441-core2-fprofiled.7z)
libx264-r1286, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1286M-gcc441-amdfam10-fprofiled.7z)
libx264-r1286, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1286M-gcc441-pentium3-fprofiled.7z)
libx264-r1286, MinGW GCC 4.4.1, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1286M-gcc441-noasm-fprofiled.7z)


libx264 SVN-r1286 using four slices:

libx264-r1286, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1286M-slices-gcc441-core2-fprofiled.7z)
libx264-r1286, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1286M-slices-gcc441-amdfam10-fprofiled.7z)
libx264-r1286, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1286M-slices-gcc441-pentium3-fprofiled.7z)


libx264 SVN-r1286 with AutoVAQ enabled:

libx264-r1286, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1286M-autovaq-gcc441-core2-fprofiled.7z)
libx264-r1286, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1286M-autovaq-gcc441-amdfam10-fprofiled.7z)
libx264-r1286, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1286M-autovaq-gcc441-pentium3-fprofiled.7z)


libx264 SVN-r1286 with MB-Tree disabled:

libx264-r1286, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1286M-nombtree-gcc441-core2-fprofiled.7z)
libx264-r1286, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1286M-nombtree-gcc441-amdfam10-fprofiled.7z)
libx264-r1286, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1286M-nombtree-gcc441-pentium3-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5369 (http://forum.doom9.org/showpost.php?p=1331731&postcount=1323) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

There still is a potential miscompilation with GCC 4.4.x, use those builds with care and report any problems you may encounter...

[Brazil2]

SubME=9 + Trellis=2 + ME=UMH (or higher) will trigger SubME=10 in my builds.
That's the settings I'm using :)
I'll try another comparison with trellis=1 then to force subme=9 in both cases.


Threaded Lookahead (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=5b3c89c592e412fc02fd8001ee361ea50c249153) is enabled, even with MB-Tree RC disabled. Right?
OK then. But still rc_lookahead parameter is not shown at all in the encoding settings when MB-Tree is disabled. I don't know if it's a x264 kind of 'bug' or if it's related to your builds only.


Both, Mean and Gruntster, are visiting the Avidemux board regularly. So that's your best chance to get any feature requests done ;)
Done (http://avidemux.org/admForum/viewtopic.php?id=6767).
And you already solved one of my requests about MP2, bah stupid me I should have thought that MP2 or MP3 is still MPEG audio pfff...


Until we eliminate all such uses of 2D arrays, I don't trust GCC 4.4 to produce valid output.
I see. Thanks for info. Awaiting official commit :)
Or still compile your builds with GCC 4.3.4 in the meanwhile since they seem to work pretty fine ;)

[LoRd_MuldeR]

Or still compile your builds with GCC 4.3.4 in the meanwhile since they seem to work pretty fine ;)

Not really. We had broken GCC 4.3.4 builds too:

1281 builds:
x264.nl gcc 3.4.6 -- OK
BugMaster gcc 4.3.3 TDM -- OK
BugMaster gcc 4.3.4 20090220 (prerelease) (x32.generic.Komisar) (not profiled) -- OK
Komisar gcc 4.3.4 (x86_64.core2.Komisar) -- OK
Komisar gcc 4.3.4 (x86.generic.Komisar) -- OK
Komisar gcc 4.4.1 (x86.core2.Komisar) -- FAILURE
JEEB gcc 4.3.4 20090220 (prerelease) (x64.generic.Komisar) -- FAILURE
techouse gcc 4.4.1 (x86_64.core2.Komisar) -- FAILURE
rack04 (patched build) gcc 4.3.4 (x86.core2.Komisar) -- FAILURE


gcc sucks again... :eek:

Anyway, the fix for the miscompilation problem has now been committed officially:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=3cb2d8b8be36badcbef37b336b9e06867c9ab91d

So I will make new builds as soon as I return back home. But this won't happen before tomorrow...

[LoRd_MuldeR]

libx264 SVN-r1292:

libx264-r1292, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1292M-gcc441-core2-fprofiled.7z)
libx264-r1292, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1292M-gcc441-amdfam10-fprofiled.7z)
libx264-r1292, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1292M-gcc441-pentium3-fprofiled.7z)
libx264-r1292, MinGW GCC 4.4.1, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1292M-gcc441-noasm-fprofiled.7z)


libx264 SVN-r1292 using four slices:

libx264-r1292, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1292M-slices-gcc441-core2-fprofiled.7z)
libx264-r1292, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1292M-slices-gcc441-amdfam10-fprofiled.7z)
libx264-r1292, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1292M-slices-gcc441-pentium3-fprofiled.7z)


libx264 SVN-r1292 with AutoVAQ enabled:

libx264-r1292, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1292M-autovaq-gcc441-core2-fprofiled.7z)
libx264-r1292, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1292M-autovaq-gcc441-amdfam10-fprofiled.7z)
libx264-r1292, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1292M-autovaq-gcc441-pentium3-fprofiled.7z)


libx264 SVN-r1292 with MB-Tree disabled:

libx264-r1292, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1292M-nombtree-gcc441-core2-fprofiled.7z)
libx264-r1292, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1292M-nombtree-gcc441-amdfam10-fprofiled.7z)
libx264-r1292, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1292M-nombtree-gcc441-pentium3-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5369 (http://forum.doom9.org/showpost.php?p=1331731&postcount=1323) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

Miscompilation with GCC 4.4.x should be fixed (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=287641a7c54d525e0eb74925431541ffb5f9471d) now, finally. So if you used one of the previous builds, you are urged to update now!

[LoRd_MuldeR]

libx264 SVN-r1301:

libx264-r1301, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc441-core2-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc441-amdfam10-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc441-pentium3-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc441-noasm-fprofiled.7z)


libx264 SVN-r1301 using four slices:

libx264-r1301, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1301M-slices-gcc441-core2-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1301M-slices-gcc441-amdfam10-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1301M-slices-gcc441-pentium3-fprofiled.7z)


libx264 SVN-r1301 with AutoVAQ enabled:

libx264-r1301, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1301M-autovaq-gcc441-core2-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1301M-autovaq-gcc441-amdfam10-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1301M-autovaq-gcc441-pentium3-fprofiled.7z)


libx264 SVN-r1301 with MB-Tree disabled:

libx264-r1301, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1301M-nombtree-gcc441-core2-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1301M-nombtree-gcc441-amdfam10-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1301M-nombtree-gcc441-pentium3-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5369 (http://forum.doom9.org/showpost.php?p=1331731&postcount=1323) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

These builds were patched from core-78 to core-76 in order to make them work with the latest Avidemux build! Hope I didn't break it ^^

[LoRd_MuldeR]

libx264 SVN-r1301:

libx264-r1301, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc442-core2-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc442-amdfam10-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc442-pentium3-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc442-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5369 (http://forum.doom9.org/showpost.php?p=1331731&postcount=1323) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

New experimental builds using Komisar's MinGW/GCC 4.4.2 compiler. Use with care any report any problem you may encounter...

[lych_necross]

@LoRd_MuldeR: Aside from this forum, I also browse the Avidemux for and I have a question for you about your libx264 svn-r1301 builds. On this thread, you have posted:
libx264 SVN-r1301:

libx264-r1301, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc442-core2-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc442-amdfam10-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc442-pentium3-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc442-noasm-fprofiled.7z)


But on the other forum you posted:
libx264 SVN-r1301:

libx264-r1301, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc441-core2-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc441-amdfam10-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc441-pentium3-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc441-noasm-fprofiled.7z)


Which one should we/I be testing? The GCC 4.4.1 or 4.4.2?

[LoRd_MuldeR]

Misunderstanding. I posted a full set of libx264 r1301 builds compiled with GCC 4.4.1 on both forums.

Then, after Komisar kindly provided MingGW/GCC 4.4.2, I also made same test builds with GCC 4.4.2, to see whether GCC 4.4.2 is usable for x264.

So far it seems GCC 4.4.2 isn't worse than GCC 4.4.1 at least, so the next builds will probably be GCC 4.4.2 only...

[lych_necross]

Misunderstanding. I posted a full set of libx264 r1301 builds compiled with GCC 4.4.1 on both forums.

Then, after Komisar kindly provided MingGW/GCC 4.4.2, I also made same test builds with GCC 4.4.2, to see whether GCC 4.4.2 is usable for x264.

So far it seems GCC 4.4.2 isn't worse than GCC 4.4.1 at least, so the next builds will probably be GCC 4.4.2 only...

Since GCC 4.4.x (and higher) seems to be less than reliable, why not downgrade to GCC 4.2?

[LoRd_MuldeR]

Since GCC 4.4.x (and higher) seems to be less than reliable, why not downgrade to GCC 4.2?

It seems GCC 4.x.x isn't very reliable in general, but GCC 3.x.x is very outdated nowadays. So I try to use the latest GCC 4.x.x, which is GCC 4.4.2 by now.

In a quick test I encoded the same source with x264 r1301 compiled with GCC 4.4.1 and with GCC 4.4.2. The files came out bit-identical. So if GCC 4.4.1 was okay, then GCC 4.4.2 is too ;)

There was a known issue with x264 and GCC 4.x.x, but it has been fixed in revision r1287. Currently I'm not aware of any known issues with GCC 4.4.x, so...

[lych_necross]

That makes sense.

[LoRd_MuldeR]

libx264 SVN-r1309:

libx264-r1309, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1309M-gcc442-core2-fprofiled.7z)
libx264-r1309, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1309M-gcc442-amdfam10-fprofiled.7z)
libx264-r1309, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1309M-gcc442-pentium3-fprofiled.7z)
libx264-r1309, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1309M-gcc442-noasm-fprofiled.7z)


libx264 SVN-r1309 using four slices:

libx264-r1309, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1309M-slices-gcc442-core2-fprofiled.7z)
libx264-r1309, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1309M-slices-gcc442-amdfam10-fprofiled.7z)
libx264-r1309, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1309M-slices-gcc442-pentium3-fprofiled.7z)


libx264 SVN-r1309 with AutoVAQ enabled:

libx264-r1309, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1309M-autovaq-gcc442-core2-fprofiled.7z)
libx264-r1309, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1309M-autovaq-gcc442-amdfam10-fprofiled.7z)
libx264-r1309, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1309M-autovaq-gcc442-pentium3-fprofiled.7z)


libx264 SVN-r1309 with MB-Tree disabled:

libx264-r1309, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1309M-nombtree-gcc442-core2-fprofiled.7z)
libx264-r1309, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1309M-nombtree-gcc442-amdfam10-fprofiled.7z)
libx264-r1309, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1309M-nombtree-gcc442-pentium3-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5369 (http://forum.doom9.org/showpost.php?p=1331731&postcount=1323) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5422 (2009-10-27)
http://www.avidemux.org/

Revision 5422 (27 Oct 2009)
# Updated SDL to version 1.2.14.
# Updated x264 to r1310.

5422 - [x264] support API version 78
5421 - [ffmpeg] update FFmpeg to r20383 & libswscale r29799
5411 - [Lame] Properly export lame VBR settings, ref #45
5410 - [AudioEnCoder] export VBR through wrapper, ref #45
5405 - [DCA] Fix # of channels + backport channel reordering from 2.6
5400 - [codec] Add SEDG (? samsung electronic d?? g??) fourcc, patch from colinl
5382 - [H264/TS] Fix loading of lumix file
5378 - [AudioDevice] Set alsa to use default instead of dmix
5371 - [Jack] Update author
5370 - [Jack] Re-enable jack plugin
5369 - [win32] update installer to support latest dependencies

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1310:

libx264-r1310, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1310M-gcc442-core2-fprofiled.7z)
libx264-r1310, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1310M-gcc442-amdfam10-fprofiled.7z)
libx264-r1310, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1310M-gcc442-pentium3-fprofiled.7z)
libx264-r1310, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1310M-gcc442-noasm-fprofiled.7z)


libx264 SVN-r1310 using four slices:

libx264-r1310, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1310M-slices-gcc442-core2-fprofiled.7z)
libx264-r1310, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1310M-slices-gcc442-amdfam10-fprofiled.7z)
libx264-r1310, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1310M-slices-gcc442-pentium3-fprofiled.7z)


libx264 SVN-r1310 with AutoVAQ enabled:

libx264-r1310, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1310M-autovaq-gcc442-core2-fprofiled.7z)
libx264-r1310, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1310M-autovaq-gcc442-amdfam10-fprofiled.7z)
libx264-r1310, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1310M-autovaq-gcc442-pentium3-fprofiled.7z)


libx264 SVN-r1310 with MB-Tree disabled:

libx264-r1310, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1310M-nombtree-gcc442-core2-fprofiled.7z)
libx264-r1310, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1310M-nombtree-gcc442-amdfam10-fprofiled.7z)
libx264-r1310, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1310M-nombtree-gcc442-pentium3-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5422 (http://forum.doom9.org/showpost.php?p=1338882&postcount=1354) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

[LoRd_MuldeR]

libx264 SVN-r1318:

libx264-r1318, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1318M-gcc442-core2-fprofiled.7z)
libx264-r1318, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1318M-gcc442-amdfam10-fprofiled.7z)
libx264-r1318, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1318M-gcc442-pentium3-fprofiled.7z)
libx264-r1318, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1318M-gcc442-noasm-fprofiled.7z)

______________________________________________________


libx264 SVN-r1318 using four slices:

libx264-r1318, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1318M-slices-gcc442-core2-fprofiled.7z)
libx264-r1318, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1318M-slices-gcc442-amdfam10-fprofiled.7z)
libx264-r1318, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1318M-slices-gcc442-pentium3-fprofiled.7z)


libx264 SVN-r1318 with AutoVAQ enabled:

libx264-r1318, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1318M-autovaq-gcc442-core2-fprofiled.7z)
libx264-r1318, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1318M-autovaq-gcc442-amdfam10-fprofiled.7z)
libx264-r1318, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1318M-autovaq-gcc442-pentium3-fprofiled.7z)


libx264 SVN-r1318 with MB-Tree disabled:

libx264-r1318, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1318M-nombtree-gcc442-core2-fprofiled.7z)
libx264-r1318, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1318M-nombtree-gcc442-amdfam10-fprofiled.7z)
libx264-r1318, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1318M-nombtree-gcc442-pentium3-fprofiled.7z)

______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5422 (http://forum.doom9.org/showpost.php?p=1338882&postcount=1354) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

[wata]

anyone know why libx264-76.dll and libx264-78.dll don't have x264 settings use for encoding written in output mp4 file now?

before i can just use any file viewer and take a look at the starting of the output mp4 to see what x264 settings is use for encoding

[LoRd_MuldeR]

anyone know why libx264-76.dll and libx264-78.dll don't have x264 settings use for encoding written in output mp4 file now?

They definitely do write the info to the H.264 bistream. Maybe the muxer discards the info? Try another container, e.g. AVI, for testing purpsoe ;)

[LoRd_MuldeR]

Here is a highly experimental build of libx264 with Weighted P-frame Prediction:
(link removed)

For more info see here:
http://wiki.videolan.org/SoC_2009/Weighted_P-frame_Prediction

[Dark Shikari]

You have to be careful when muxing to mp4, as the SEI message cannot be put in the header; the spec doesn't allow it.

The muxer has to actively take it and move it to the start of the first frame instead (if you're using encoder_headers() to get the headers).

[LoRd_MuldeR]

libx264 SVN-r1318+291 with Weighted P-Frame Prediction:

libx264-r1318+291, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-weightp-r1318+291-gcc442-core2-fprofiled.7z)
libx264-r1318+291, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-weightp-r1318+291-gcc442-amdfam10-fprofiled.7z)
libx264-r1318+291, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-weightp-r1318+291-gcc442-pentium3-fprofiled.7z)
libx264-r1318+291, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-weightp-r1318+291-gcc442-noasm-fprofiled.7z)


For information about Weighted P-Frame Prediction have a look here:
http://wiki.videolan.org/SoC_2009/Weighted_P-frame_Prediction
______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5422 (http://forum.doom9.org/showpost.php?p=1338882&postcount=1354) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

These builds are highly experimental, use them for testing only! Furthermore these builds won't work with "interlaced" mode.
Also note that CoreAVC 1.x is known to be broken with the "smart" weight-p mode, but libavcodec (MPlayer, ffdshow, etc) works fine.

[LoRd_MuldeR]

libx264 SVN-r1331 with Weighted P-Frame Prediction:

libx264-r1331, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1331M-gcc442-core2-fprofiled.7z)
libx264-r1331, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1331M-gcc442-amdfam10-fprofiled.7z)
libx264-r1331, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1331M-gcc442-pentium3-fprofiled.7z)
libx264-r1331, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1331M-gcc442-noasm-fprofiled.7z)

______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5422 (http://forum.doom9.org/showpost.php?p=1338882&postcount=1354) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

Weighted P-Frame Prediction is now officially committed. For details please read the official commit message at this (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=87de2346225721e8ca68a1b59bc87133fc598a42) location.
I used a custom patch to make these builds work with current Avidemux (r5422). Unfortunately interlaced encoding won't work yet!
Note that CoreAVC 1.x is known to be broken with the "smart" weight-p mode, but libavcodec (MPlayer, ffdshow, etc) works fine.

[LoRd_MuldeR]

libx264 SVN-r1332 with Weighted P-Frame Prediction:

libx264-r1332, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1332M-gcc442-core2-fprofiled.7z)
libx264-r1332, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1332M-gcc442-amdfam10-fprofiled.7z)
libx264-r1332, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1332M-gcc442-pentium3-fprofiled.7z)
libx264-r1332, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1332M-gcc442-noasm-fprofiled.7z)

______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5422 (http://forum.doom9.org/showpost.php?p=1338882&postcount=1354) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

This revision fixes one (of possibly many) miscompilations in weightp. Therefore people are highly encouraged to update asap!

[Yobbo]

What happened to the "Auto/DVD" setting? Is it going to be re-introduced? It was a nice little time-saver.

[LoRd_MuldeR]

What happened to the "Auto/DVD" setting? Is it going to be re-introduced? It was a nice little time-saver.

It has been explained a dozen of times: The hardcoded "Auto" menu of Avidemux 2.4 has been replaced with custom "Auto" scripts in Avidemux 2.5.

So you can create your own "Auto" entries now and share them with the community easily. However there is no "DVD" auto-script included in the Installer yet.

But some efforts have been made already. Read through this thread please:
http://avidemux.org/admForum/viewtopic.php?id=6278

[Yobbo]

It has been explained a dozen of times: The hardcoded "Auto" menu of Avidemux 2.4 has been replaced with custom "Auto" scripts in Avidemux 2.5.

Yuck. Think I'll give that a miss.

Sorry, I never heard before about this scripts thing before now. Seems silly to remove the hardcode when it was already there and working well...?

[LoRd_MuldeR]

Seems silly to remove the hardcode when it was already there and working well...?

Sometimes "legacy" stuff needs to be removed, before new/improved features can grow. The old system was too limited. To add/modify one of the "Auto" wizards, Avidemux had to be re-compiled every single time. So for "regular" users it was almost impossible to create their own "Auto" wizards. And the Avidemux devs can't maintain "Auto" wizards for dozens of target devices (Video-DVD is just one out of many). Now the "Auto" menu is script based, which means we can add new scripts (or edit existing ones) easily and share them with the community. Just be a little more patient until more "custom" scripts become available...

[boyumeow]

Hi LM, I m encountering problem with r5422, unable to open .avi and although able to open .mkv but error while quit. Not sure how to explain but I attached admlog.txt. Btw, tested ok with r5369. Thanks.

Edit: Yes, I having the same problem with the thread U link. I m using Vista32. While using ur AVS proxy GUI, I do not get such thing happens. I think I did not get any crash report too. Thanks again.

P.S. Just wonder do U have any free time to compile latest libx264 for use in r5369, its only a small request from me and U do not have to do it if U r not free or not necessary cos I do not want to make U unhappy. Thanks again.

[LoRd_MuldeR]

I can't see your Log yet (Attachments Pending Approval), but there are known problems with the latest (r5422) Avidemux build:
http://avidemux.org/admForum/viewtopic.php?id=6840

[LoRd_MuldeR]

libx264 SVN-r1336 with Weighted P-Frame Prediction:

libx264-r1336, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1336M-gcc442-core2-fprofiled.7z)
libx264-r1336, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1336M-gcc442-amdfam10-fprofiled.7z)
libx264-r1336, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1336M-gcc442-pentium3-fprofiled.7z)
libx264-r1336, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1336M-gcc442-noasm-fprofiled.7z)

______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5422 (http://forum.doom9.org/showpost.php?p=1338882&postcount=1354) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

This revision contains various weightp fixes, including thread-related issues. Therefore people are highly encouraged to update asap!

[LoRd_MuldeR]

libx264 SVN-r1339 with Weighted P-Frame Prediction:

libx264-r1339, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1339M-gcc442-core2-fprofiled.7z)
libx264-r1339, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1339M-gcc442-amdfam10-fprofiled.7z)
libx264-r1339, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1339M-gcc442-pentium3-fprofiled.7z)
libx264-r1339, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1339M-gcc442-noasm-fprofiled.7z)

______________________________________________________


libx264 SVN-r1339 without Weighted P-Frame Prediction and MB-Tree:

libx264-r1339, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1339M-noweightp-gcc442-core2-fprofiled.7z)
libx264-r1339, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1339M-noweightp-gcc442-amdfam10-fprofiled.7z)
libx264-r1339, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1339M-noweightp-gcc442-pentium3-fprofiled.7z)
libx264-r1339, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1339M-noweightp-gcc442-noasm-fprofiled.7z)

______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5422 (http://forum.doom9.org/showpost.php?p=1338882&postcount=1354) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

This revision fixes possible Deadlocks in Weighted P-Frame Prediction. Therefore people are highly encouraged to update asap!

[LoRd_MuldeR]

libx264 SVN-r1342 with Weighted P-Frame Prediction:

libx264-r1342, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1342M-gcc442-core2-fprofiled.7z)
libx264-r1342, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1342M-gcc442-amdfam10-fprofiled.7z)
libx264-r1342, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1342M-gcc442-pentium3-fprofiled.7z)
libx264-r1342, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-78-r1342M-gcc442-noasm-fprofiled.7z)

______________________________________________________


libx264 SVN-r1342 without Weighted P-Frame Prediction and MB-Tree:

libx264-r1342, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1342M-noweightp-gcc442-core2-fprofiled.7z)
libx264-r1342, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1342M-noweightp-gcc442-amdfam10-fprofiled.7z)
libx264-r1342, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1342M-noweightp-gcc442-pentium3-fprofiled.7z)
libx264-r1342, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-78-r1342M-noweightp-gcc442-noasm-fprofiled.7z)

______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5422 (http://forum.doom9.org/showpost.php?p=1338882&postcount=1354) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on AutoVAQ (now officially committed) can be found in this (http://forum.doom9.org/showthread.php?t=147067) thread.
Information about the new "Macroblock Tree" ratecontrol, which redefines the CRF scale, can be found in this (http://forum.doom9.org/showthread.php?t=148686) thread.

This revision contains yet another bugfix for Weighted P-Frame Prediction. Therefore people are highly encouraged to update asap!

[roozhou]

Does avidemux support smart rendering similar to that in VirtualDub?

[buzzqw]

yes (and before virtualdub...)

BHH

[LoRd_MuldeR]

It should be noted that it works for MPEG-4 ASP (Xvid) only at the moment.

[buzzqw]

i used with mpeg2 too...

is it broken now ?

BHH

[roozhou]

And it seems smart copy only works on avi output. It's not available when using mkv/mp4 output.

[LoRd_MuldeR]

i used with mpeg2 too...

is it broken now ?

BHH

I don't think it was ever implemented for anything else bu MPEG-4 ASP, but I may be mistaken :p

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5530 (2009-11-19)
http://www.avidemux.org/

Revision 5530 (19 Nov 2009)
# Updated x264 to r1342.

5530 - [build] compilation fix
5529 - [build] compilation fix
5526 - [VideoFilter] Add configure stubs so that filters are available from avidemux2_cli
5525 - [VideoFilter] Mplayer Resize, cli version
5524 - [Filter] Add cli cmake helper
5519 - [i18n] Regenerate po from mo for zh_CN
5516 - [I18N] Traditional chinese by zdw
5502 - [x264] Fix locales for x264 settings in xml, patch from KrissN
5492 - [MKV] Add PCM support (2.5)
5460 - [Demuxer] Initialize to 0 all static members of ADM_video
5452 - [FAAC/Calculator] Dont use null encoder if initiliazing audio encoder fails, fixes #25
5450 - [audioEncoder] Remove static enc, refs #49, probably hides memory corruption
5447 - [Filter] Make partial works again, patch by forumer ratte

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1342 with Weighted P-Frame Prediction:

libx264-r1342, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-79-r1342M-gcc442-core2-fprofiled.7z)
libx264-r1342, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-79-r1342M-gcc442-amdfam10-fprofiled.7z)
libx264-r1342, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-79-r1342M-gcc442-pentium3-fprofiled.7z)
libx264-r1342, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-79-r1342M-gcc442-noasm-fprofiled.7z)

______________________________________________________


libx264 SVN-r1342 without Weighted P-Frame Prediction:

libx264-r1342, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-79-r1342M-noweightp-gcc442-core2-fprofiled.7z)
libx264-r1342, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-79-r1342M-noweightp-gcc442-amdfam10-fprofiled.7z)
libx264-r1342, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-79-r1342M-noweightp-gcc442-pentium3-fprofiled.7z)
libx264-r1342, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-79-r1342M-noweightp-gcc442-noasm-fprofiled.7z)

______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5530 (http://forum.doom9.org/showpost.php?p=1345642&postcount=1379) or later now!

Recompiled x264 r1342 for the latest Avidemux build, which finally supports x264 core-79. Interlaced encoding should work again.

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5546 (2009-11-23)
http://www.avidemux.org/

Revision 5546 (23 Nov 2009)
# Updated x264 to r1347.

5546 - [win32] bundle cli filters
5541 - [resize] keep same name for cli filter library
5540 - [x264] locale neutral parsing
5539 - [filter] mplayer_cli does not need gtk
5536 - [avcodec] Set codec type for audio to avoid crash
5533 - [qt] fix kino files reading
5532 - [mov] Dont close the file twice in case of error
5530 - [build] compilation fix

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1347 with Weighted P-Frame Prediction:

libx264-r1347, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-79-r1347M-gcc442-core2-fprofiled.7z)
libx264-r1347, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-79-r1347M-gcc442-amdfam10-fprofiled.7z)
libx264-r1347, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-79-r1347M-gcc442-pentium3-fprofiled.7z)
libx264-r1347, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-79-r1347M-gcc442-noasm-fprofiled.7z)

______________________________________________________


libx264 SVN-r1347 without Weighted P-Frame Prediction:

libx264-r1347, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-79-r1347M-noweightp-gcc442-core2-fprofiled.7z)
libx264-r1347, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-79-r1347M-noweightp-gcc442-amdfam10-fprofiled.7z)
libx264-r1347, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-79-r1347M-noweightp-gcc442-pentium3-fprofiled.7z)
libx264-r1347, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-79-r1347M-noweightp-gcc442-noasm-fprofiled.7z)


libx264 SVN-r1347 without MB-Tree RC:

libx264-r1347, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-79-r1347M-nombtree-gcc442-core2-fprofiled.7z)
libx264-r1347, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-79-r1347M-nombtree-gcc442-amdfam10-fprofiled.7z)
libx264-r1347, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-79-r1347M-nombtree-gcc442-pentium3-fprofiled.7z)
libx264-r1347, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-79-r1347M-nombtree-gcc442-noasm-fprofiled.7z)

______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5558 (http://forum.doom9.org/showpost.php?p=1347175&postcount=1383) or later now!

This revision fixes a (rare) deadlock with sync-lookahead and improves the speed of the weightp analysis. Update is recommended.

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5558 (2009-11-24)
http://www.avidemux.org/

Revision 5558 (24 Nov 2009)

5558 - [x264] add macroblock-tree optimisation option
5557 - [ffmpeg] update FFmpeg to r20602 & libswscale r29964
5556 - [A52] Revert eac3 part, not enough
5555 - [A52] Use ffmpeg ac3 parser to correctly parse eac3
5554 - [FFmpeg] Enable ac3 parser, needed for eac3
5553 - [x264] add psychovisual RDO option
5551 - [win32] only install cli filters if command line version is selected
5550 - [win32] use wide char load library function for plugins (fixes #56)
5549 - [win32] retrieve wide char version of program folder (refs #56)
5546 - [win32] bundle cli filters
5541 - [resize] keep same name for cli filter library
5540 - [x264] locale neutral parsing
5539 - [filter] mplayer_cli does not need gtk
5536 - [avcodec] Set codec type for audio to avoid crash
5533 - [qt] fix kino files reading
5532 - [mov] Dont close the file twice in case of error

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[DarkZell666]

MB-Tree and Psy-Rdo in avidemux, yay ! :D

[LoRd_MuldeR]

MB-Tree and Psy-Rdo in avidemux, yay ! :D

Those feature were available and working in Avidemux since they were added to x264 :eek:

Only Avidemux didn't expose them as options. So the x264 defaults were used. Now you can configure them yourself. That's all.

Options still missing: Psy Trellis, SubME=10, Weighted P-Prediction, RC Lookahead, Slices.

[DarkZell666]

Only Avidemux didn't expose them as options. So the x264 defaults were used. Now you can configure them yourself. That's all.
Yeah that's what I meant. I know about your special libx264 builds, many thanks for sharing them ! ;)

[LoRd_MuldeR]

You don't need "special" builds to use those features. Any vanilla build of libx264 will work with Avidemux, as long as the core API version matches.

Every feature that is available in x264 and enabled by default, will be available/enabled in Avidemux automatically, even if there's no option for that feature exposed in the GUI.

However you do need a "special" (patched) build, if you want to change the x264 defaults (e.g. disable Weight-P), but Avidemux doesn't offer that option yet...

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5567 (2009-11-26)
http://www.avidemux.org/

Revision 5567 (26 Nov 2009)

5567 - [x264] add frametype lookahead option for Qt interface
5566 - [x264] increase minimum supported core version to 67
5565 - [lame] add support for 256 and 320kbps (patch by surfer)
5564 - [xvid] save settings when using GTK+ (fixes #55)
5563 - [win32] convert CLI parameters from ANSI to UTF-8
5562 - [win32] remove intl.dll from GTK+ installer
5561 - [i18n] Hungarian translation by alaci
5560 - [ASF] Switch to dynamically created ASF index
5559 - [Build] Add bootstrap debug script

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[boyumeow]

Hi LM, whenever I select x264 configuration => Motion => Direct Prediction Mode to [None/Auto/Temporal] and Save As, it would just revert back to [Spatial]. Just wonder was it the result of ur compile x264.dll, r U getting the same thing too? If it is already a known bug, pls forgive me too. Thanks.

[LoRd_MuldeR]

What do you mean? :confused:

Does it revert to "Spatial" in the encoded file after you saved the video (in that case: how did you check it?) or does it revert when you save a project/javascript file ???

[EDIT]

It works exactly as expected, so what is the problem?

With "Auto" selected:
x264 [info]: options: cabac=1 ref=8 deblock=1:-1:-1 analyse=0x3:0x133 me=umh subme=10 psy=1 psy_rd=1.00:0.15 mixed_ref=1 me_range=24 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=-3 threads=6 nr=0 decimate=1 mbaff=0 constrained_intra=0 bframes=5 b_pyramid=0 b_adapt=2 b_bias=0 direct=3 wpredb=1 wpredp=2 keyint=500 keyint_min=25 scenecut=40 rc_lookahead=40 rc=crf mbtree=1 crf=20.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 aq=1:1.00

With "Temporal" selected:
x264 [info]: options: cabac=1 ref=8 deblock=1:-1:-1 analyse=0x3:0x133 me=umh subme=10 psy=1 psy_rd=1.00:0.15 mixed_ref=1 me_range=24 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=-3 threads=6 nr=0 decimate=1 mbaff=0 constrained_intra=0 bframes=5 b_pyramid=0 b_adapt=2 b_bias=0 direct=2 wpredb=1 wpredp=2 keyint=500 keyint_min=25 scenecut=40 rc_lookahead=40 rc=crf mbtree=1 crf=20.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 aq=1:1.00

With "Spatial" selected:
x264 [info]: options: cabac=1 ref=8 deblock=1:-1:-1 analyse=0x3:0x133 me=umh subme=10 psy=1 psy_rd=1.00:0.15 mixed_ref=1 me_range=24 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=-3 threads=6 nr=0 decimate=1 mbaff=0 constrained_intra=0 bframes=5 b_pyramid=0 b_adapt=2 b_bias=0 direct=1 wpredb=1 wpredp=2 keyint=500 keyint_min=25 scenecut=40 rc_lookahead=40 rc=crf mbtree=1 crf=20.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 aq=1:1.00

With "None" selected:
x264 [info]: options: cabac=1 ref=8 deblock=1:-1:-1 analyse=0x3:0x133 me=umh subme=10 psy=1 psy_rd=1.00:0.15 mixed_ref=1 me_range=24 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=-3 threads=6 nr=0 decimate=1 mbaff=0 constrained_intra=0 bframes=5 b_pyramid=0 b_adapt=2 b_bias=0 direct=0 wpredb=1 wpredp=2 keyint=500 keyint_min=25 scenecut=40 rc_lookahead=40 rc=crf mbtree=1 crf=20.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 aq=1:1.00

[EDIT 2]

Actually the Direct Prediction Mode was used correctly, but was not saved correct to project/javascript file.

It's fixed now:
http://svn.berlios.de/wsvn/avidemux/?rev=5568&sc=1

[LoRd_MuldeR]

libx264 SVN-r1352 with Weighted P-Frame Prediction:

libx264-r1352, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-79-r1352M-gcc442-core2-fprofiled.7z)
libx264-r1352, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-79-r1352M-gcc442-amdfam10-fprofiled.7z)
libx264-r1352, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-79-r1352M-gcc442-pentium3-fprofiled.7z)
libx264-r1352, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-79-r1352M-gcc442-noasm-fprofiled.7z)

______________________________________________________


libx264 SVN-r1352 without Weighted P-Frame Prediction:

libx264-r1352, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-79-r1352M-noweightp-gcc442-core2-fprofiled.7z)
libx264-r1352, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-79-r1352M-noweightp-gcc442-amdfam10-fprofiled.7z)
libx264-r1352, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-79-r1352M-noweightp-gcc442-pentium3-fprofiled.7z)
libx264-r1352, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-79-r1352M-noweightp-gcc442-noasm-fprofiled.7z)

______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5567 (http://85.230.118.136/showpost.php?p=1347616&postcount=1388) or later now!

This revision contains even more bugfixes and massive speed-up for Weighted-P Prediction. Update is recommended!
Also note that Avidemux now offers options for MB-Tree RC, Psy RDO and RC Lookahead.

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5590 (2009-11-28)
http://www.avidemux.org/

Revision 5590 (28 Nov 2009)
# Updated Cairo to version 1.8.8-3.
# Updated Fontconfig to version 2.8.0-1.
# Updated Freetype to version 2.3.11-1.
# Updated GLib to version 2.22.2-1.
# Updated GTK+ to version 2.18.3-1.
# Updated Pango to version 1.26.0-1.
# Updated x264 to r1352.

5590 - [x264] add threaded lookahead option to Qt interface
5589 - [x264] fix typo
5588 - [x264] add slicing options to Qt interface
5587 - [win32] update installer for latest Pango runtime
5586 - [gui] protect frame seeking to prevent crashes in Qt interface (fixes #53)
5585 - [vobsub] remove Extra Shrink Factor option from GTK+ settings window since it's not used (refs #59)
5568 - [x264] save direct prediction mode (regression introduced r5566)

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[boyumeow]

Sorry LM, sorry for not being reporting clear enough and cause U to edit twice :p. Was glad that U understand it and was fixed so fast. Thanks again, to U and the Developers of Avidemux.

[TheImperial2004]

I can see Gruntster is doing well adding missing x264 options to the QT interface ... Well done . ;)

I felt like dropping by to say :thanks:

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5602 (2009-11-30)
http://www.avidemux.org/

Revision 5602 (30 Nov 2009)

Revision 5590 (28 Nov 2009)
# Updated Cairo to version 1.8.8-3.
# Updated Fontconfig to version 2.8.0-1.
# Updated Freetype to version 2.3.11-1.
# Updated GLib to version 2.22.2-1.
# Updated GTK+ to version 2.18.3-1.
# Updated Pango to version 1.26.0-1.
# Updated x264 to r1352.

5602 - [gui] fix cut and paste - it never seems to have worked??? (fixes #41)
5597 - [x264] add weighted prediction for pframe option to Qt interface
5593 - [x264] add constrained intra prediction option to Qt interface
5592 - [x264] extend bframe as references option on Qt interface
5590 - [x264] add threaded lookahead option to Qt interface

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[lych_necross]

I'm loving these new GUI options. A new build every two days, we're getting spoiled. :)

EDIT:
Hey Mulder, since Avidemux has added the weighted prediction option to the gui, do your x264 builds "with Weighted P-Frame Prediction" interfere in any way the updated gui?

[LoRd_MuldeR]

EDIT:
Hey Mulder, since Avidemux has added the weighted prediction option to the gui, do your x264 builds "with Weighted P-Frame Prediction" interfere in any way the updated gui?

No they don't. The "with weightp" build doesn't contain any patches specific to weightp, as weightp is officially committed and enabled by default. Avidemux now offers options to configure (e.g. disable) weightp at runtime, which will work perfectly fine with the aforementioned build. Therefore the "without weightp" build is superfluous now. However even that one will work with latest Avidemux just fine, as Avidemux will simply overwrite the default weightp mode with the GUI option - no matter if the default was ON or OFF. Conclusion: From now on, I will only make one kind of builds...

[lych_necross]

Very cool. Thanks M.

[LoRd_MuldeR]

libx264 SVN-r1360:

libx264-r1360, MinGW GCC 4.4.2, optimized for Core 2 (http://dl.dropbox.com/u/3191920/Beta/libx264/r1360/libx264-79-r1360M-gcc442-core2-fprofiled.7z)
libx264-r1360, MinGW GCC 4.4.2, optimized for K10 (http://dl.dropbox.com/u/3191920/Beta/libx264/r1360/libx264-79-r1360M-gcc442-amdfam10-fprofiled.7z)
libx264-r1360, MinGW GCC 4.4.2, optimized for Pentium III (http://dl.dropbox.com/u/3191920/Beta/libx264/r1360/libx264-79-r1360M-gcc442-pentium3-fprofiled.7z)
libx264-r1360, MinGW GCC 4.4.2, without ASM (slow!) (http://dl.dropbox.com/u/3191920/Beta/libx264/r1360/libx264-79-r1360M-gcc442-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5602 (http://forum.doom9.org/showpost.php?p=1348253&postcount=1395) or later now!

[boyumeow]

Hi LM, yes... with me popping up means I have encountered some problem again, and its the same problem... Yes, about the project/javascript file, r5602 on x264 configuration(I did not test out the rest sorry), this time it was not saved correctly again I assume, once save and it will just revert all setting back to default, although we could see the save file in drop-down list but cannot be initiated. Even I save it as 'Save Project' and config it to be used in 'Custom' and the configuration just switch back to default setting. Hope I didn't report the wrong bug.

Just wonder has this It was caused by a bug in the newly released Qt 4.6.0 RC1. Whenever one moved the mouse cursor over the main window in the Windows port, the frame rate was immediately cut in half, which effectively ruined Mouse, Super Scope and Justifier support. had anything to do with it, just curious but I assume it different and might already been fixed.

Hope U understand what I m trying to report, and great thanks:thanks:.

[LoRd_MuldeR]

Boyumeow, see:
http://avidemux.org/admForum/viewtopic.php?id=7002

[boyumeow]

Hi LM, thanks. I did look in avidemux.org but only under "Window", should have look into "Dev Branche", sorry for that again. Thanks.

[wata]

Quote:
Originally Posted by wata View Post
anyone know why libx264-76.dll and libx264-78.dll don't have x264 settings use for encoding written in output mp4 file now?

They definitely do write the info to the H.264 bistream. Maybe the muxer discards the info? Try another container, e.g. AVI, for testing purpsoe ;)

hi, today i try the latest avidemux 5602 with output to mp4 and mkv both doesn't have the x264 info included in the encoded file, only avi have it
is it possible to get back to previous version behavior (last know version r5341)

[LoRd_MuldeR]

Quote:
Originally Posted by wata View Post
anyone know why libx264-76.dll and libx264-78.dll don't have x264 settings use for encoding written in output mp4 file now?



hi, today i try the latest avidemux 5602 with output to mp4 and mkv both doesn't have the x264 info included in the encoded file, only avi have it
is it possible to get back to previous version behavior (last know version r5341)

Probably an issue with Avidemux' MKV/MP4 muxer. I can reproduce it and will open an issue on the Avidemux bug tracker.

Update:This isn't a bug in Avidemux. x264 now encapsulates NALs (http://git.videolan.org/?p=x264.git;a=commit;h=031e25d8cc909af2d138f9fedc8252961f34a6ac).

The additional metadata is generated by x264 for the first frame if repeat headers are used (i.e. SPS/PPS is required before each keyframe). Containers like FLV, MOV and MP4 use global headers and therefore the additional metadata isn't generated.

I'd imagine other software that uses the latest x264 like FFmpeg and MEncoder would act the same.

[LoRd_MuldeR]

libx264 SVN-r1360:

libx264-r1360, MinGW GCC 4.4.2, optimized for Core 2 (http://www.mediafire.com/file/rgjnm2zmzjz/libx264-79-r1360M-gcc442-core2-fprofiled.7z)
libx264-r1360, MinGW GCC 4.4.2, optimized for K10 (http://www.mediafire.com/file/1ygtmvemkqn/libx264-79-r1360M-gcc442-amdfam10-fprofiled.7z)
libx264-r1360, MinGW GCC 4.4.2, optimized for Pentium III (http://www.mediafire.com/file/jnmmzm3m3tm/libx264-79-r1360M-gcc442-pentium3-fprofiled.7z)
libx264-r1360, MinGW GCC 4.4.2, without ASM (slow!) (http://www.mediafire.com/file/tzgtmyz54jg/libx264-79-r1360M-gcc442-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5602 (http://forum.doom9.org/showpost.php?p=1348253&postcount=1395) or later now!

Re-uploaded, as the previous mirror, DropBox, is not available anymore. They disabled my account. Reason: Too much traffic.

[LoRd_MuldeR]

libx264 SVN-r1369:

libx264-r1369, MinGW GCC 4.4.2, optimized for Core 2 (http://www.mediafire.com/file/diiwitzyjw2/libx264-79-r1369M-gcc442-core2-fprofiled.7z)
libx264-r1369, MinGW GCC 4.4.2, optimized for K10 (http://www.mediafire.com/file/nw1ux5xgyty/libx264-79-r1369M-gcc442-amdfam10-fprofiled.7z)
libx264-r1369, MinGW GCC 4.4.2, optimized for Pentium III (http://www.mediafire.com/file/nd2kd3eoi1e/libx264-79-r1369M-gcc442-pentium3-fprofiled.7z)
libx264-r1369, MinGW GCC 4.4.2, without ASM (slow!) (http://www.mediafire.com/file/wzymyanwwyt/libx264-79-r1369M-gcc442-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5602 (http://forum.doom9.org/showpost.php?p=1348253&postcount=1395) or later now!

MB-Tree + B-Pyramid works now. Also slice-based threading is back (optionally), but cannot be used with Avidemux yet.

[LoRd_MuldeR]

libx264 SVN-r1373:

libx264-r1373, MinGW GCC 4.4.2, optimized for Core 2 (http://www.mediafire.com/file/3inzozz2g2q/libx264-79-r1373M-gcc442-core2-fprofiled.7z)
libx264-r1373, MinGW GCC 4.4.2, optimized for K10 (http://www.mediafire.com/file/ldyzwmklzv4/libx264-79-r1373M-gcc442-amdfam10-fprofiled.7z)
libx264-r1373, MinGW GCC 4.4.2, optimized for Pentium III (http://www.mediafire.com/file/nygdzzznwzm/libx264-79-r1373M-gcc442-pentium3-fprofiled.7z)
libx264-r1373, MinGW GCC 4.4.2, without ASM (slow!) (http://www.mediafire.com/file/zgynz2yqwmh/libx264-79-r1373M-gcc442-noasm-fprofiled.7z)



libx264-r1373, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/zkgzyhxdkdj/libx264-79-r1373M-gcc450-core2-fprofiled.7z)
libx264-r1373, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/kj2zdytum3n/libx264-79-r1373M-gcc450-amdfam10-fprofiled.7z)
libx264-r1373, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/z5zntmzg2wd/libx264-79-r1373M-gcc450-pentium3-fprofiled.7z)
libx264-r1373, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/zltyfafjnry/libx264-79-r1373M-gcc450-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5602 (http://forum.doom9.org/showpost.php?p=1348253&postcount=1395) or later now!

This build fixes a crash (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=65b3d0fd9f8167a6d0772a29e8fcf1a66ee7f8af) introduced in the previous build. People are highly encouraged to update asap!

[wata]

Probably an issue with Avidemux' MKV/MP4 muxer. I can reproduce it and will open an issue on the Avidemux bug tracker.

Update:
Originally Posted by Grant Pedersen
This isn't a bug in Avidemux. x264 now encapsulates NALs (http://git.videolan.org/?p=x264.git;...8252961f34a6ac).

The additional metadata is generated by x264 for the first frame if repeat headers are used (i.e. SPS/PPS is required before each keyframe). Containers like FLV, MOV and MP4 use global headers and therefore the additional metadata isn't generated.

I'd imagine other software that uses the latest x264 like FFmpeg and MEncoder would act the same.

i got no idea what Grant Pedersen are talking about

you mean from now on x264 encoding to mp4/mkv encode setting are not embeded, so if i want to check later what setting/version i use to encode those files there would be no way


i just try the latest version r1373 it still produce mp4/mkv with x264 settings embedded

[LoRd_MuldeR]

He mans that x264 now encapsulates the NAL units itself. Before the API change, a while ago, the application had to do that.

This, in combination with the fact that MP4/MKV doesn't use repeat headers (it only stores a global header once), has the effect that no meta data is written.

If you (or one of the x264 developers) know a workaround, then let use know please...

[Brazil2]

The point is that it's working with a standalone x264.exe and we can see the SEI informations in all of these cases:
raw .h264 stream
MP4 muxed with MP4Box with the above raw stream
MKV muxed with MKVmerge with the above raw stream
MP4 directly created by x264.exe

It's only Avidemux which stopped doing it after r5341 IIRC. It was working fine before.
Not to mention that sometimes I have troubles with MP4 files created by Avidemux but remuxing them with MP4Box (through YAMB) is making them playing fine.

[Ryo94]

When I use the zoom x2 the playing becomes slow and glitchy, I thought that could be lack of memory but this happen even with low quality files (320x240) while in Virtualdub I can zoom till 300% without problem, I have this problem with the 2.5 stable and with the latest beta too. I'm running avidemux in a pc with an athlon 1.5Ghz, 1GB ram, WinXP SP3.

[LoRd_MuldeR]

I added experimental GCC 4.5.0 builds of libx264 r1373. Have fun testing :)
http://forum.doom9.org/showpost.php?p=1351705&postcount=1407

In my quick test the encoded H.264 streams came out bit-identical for the GCC 4.4.2 and GCC 4.5.0 builds (verified using MD5 and RIPEMD160 hashes).

[Brazil2]

I added experimental GCC 4.5.0 builds of libx264 r1373. Have fun testing :)
http://forum.doom9.org/showpost.php?p=1351705&postcount=1407
I can't download it, looks like the server hosting it is down :(
However I can download the 4.4.2 version.

[LoRd_MuldeR]

I can't download it, looks like the server hosting it is down :(
However I can download the 4.4.2 version.

It's both hosted on MediaFire, so how is it possible that you can download the one but not the other? :confused:

However I just checked and I currently cannot download anything, so it's probably a temporary problem at MediaFire...

EDIT: Seems to work again here. Please try again!

[Brazil2]

Seems to work again here. Please try again!
4.4.2 works
4.5.0 still doesn't work :(

[LoRd_MuldeR]

Strange. Definitely works for me. And I wonder how it is possible that the 4.5.0 downloads don't work while the 4.4.2 downloads do work. They are hosted on the same site!

As I can download the files, it's not a server problem. And as you can download at least some files from MediaFire, it also can't be a "connection" problem on your side...

[kypec]

4.4.2 works
4.5.0 still doesn't work :(
I can confirm this:
libx264-79-r1373M-gcc442-core2-fprofiled.7z downloaded fine for me.
http://download636.mediafire.com/u3wruk4mbwog/zkgzyhxdkdj/libx264-79-r1373M-gcc450-core2-fprofiled.7z fails with the following error:Network Timeout

The operation timed out when attempting to contact download636.mediafire.com.

The requested site did not respond to a connection request and the browser has stopped waiting for a reply.
Tried several refresh procedures, still doesn't work.

[LoRd_MuldeR]

I can confirm this:
libx264-79-r1373M-gcc442-core2-fprofiled.7z downloaded fine for me.
http://download636.mediafire.com/u3wruk4mbwog/zkgzyhxdkdj/libx264-79-r1373M-gcc450-core2-fprofiled.7z fails with the following error:Network Timeout

The operation timed out when attempting to contact download636.mediafire.com.

The requested site did not respond to a connection request and the browser has stopped waiting for a reply.

Deep links won't work with MediaFire. Anyway, it seems that one of their mirrors is currently down. Unfortunately the one where my files are located :p

Re-uploading the files now, please stay tuned...

[LoRd_MuldeR]

libx264 SVN-r1373:

libx264-r1373, MinGW GCC 4.4.2, optimized for Core 2 (http://dl.dropbox.com/u/3191920/Beta/libx264/r1373/libx264-79-r1373M-gcc442-core2-fprofiled.7z)
libx264-r1373, MinGW GCC 4.4.2, optimized for K10 (http://dl.dropbox.com/u/3191920/Beta/libx264/r1373/libx264-79-r1373M-gcc442-amdfam10-fprofiled.7z)
libx264-r1373, MinGW GCC 4.4.2, optimized for Pentium III (http://dl.dropbox.com/u/3191920/Beta/libx264/r1373/libx264-79-r1373M-gcc442-pentium3-fprofiled.7z)
libx264-r1373, MinGW GCC 4.4.2, without ASM (slow!) (http://dl.dropbox.com/u/3191920/Beta/libx264/r1373/libx264-79-r1373M-gcc442-noasm-fprofiled.7z)



libx264-r1373, MinGW GCC 4.5.0, optimized for Core 2 (http://dl.dropbox.com/u/3191920/Beta/libx264/r1373/libx264-79-r1373M-gcc450-core2-fprofiled.7z)
libx264-r1373, MinGW GCC 4.5.0, optimized for K10 (http://dl.dropbox.com/u/3191920/Beta/libx264/r1373/libx264-79-r1373M-gcc450-amdfam10-fprofiled.7z)
libx264-r1373, MinGW GCC 4.5.0, optimized for Pentium III (http://dl.dropbox.com/u/3191920/Beta/libx264/r1373/libx264-79-r1373M-gcc450-pentium3-fprofiled.7z)
libx264-r1373, MinGW GCC 4.5.0, without ASM (slow!) (http://dl.dropbox.com/u/3191920/Beta/libx264/r1373/libx264-79-r1373M-gcc450-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5602 (http://forum.doom9.org/showpost.php?p=1348253&postcount=1395) or later now!

This build fixes a crash (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=65b3d0fd9f8167a6d0772a29e8fcf1a66ee7f8af) introduced in the previous build. People are highly encouraged to update asap! Re-uploaded.

[LoRd_MuldeR]

libx264 SVN-r1376:

libx264-r1376, MinGW GCC 4.5.0, optimized for Core 2 (http://dl.dropbox.com/u/3191920/Beta/libx264/r1376/libx264-79-r1376M-gcc450-core2-fprofiled.7z)
libx264-r1376, MinGW GCC 4.5.0, optimized for K10 (http://dl.dropbox.com/u/3191920/Beta/libx264/r1376/libx264-79-r1376M-gcc450-amdfam10-fprofiled.7z)
libx264-r1376, MinGW GCC 4.5.0, optimized for Pentium III (http://dl.dropbox.com/u/3191920/Beta/libx264/r1376/libx264-79-r1376M-gcc450-pentium3-fprofiled.7z)
libx264-r1376, MinGW GCC 4.5.0, without ASM (slow!) (http://dl.dropbox.com/u/3191920/Beta/libx264/r1376/libx264-79-r1376M-gcc450-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5602 (http://forum.doom9.org/showpost.php?p=1348253&postcount=1395) or later now!

This build should ignificantly increase quality with many threads in 2-pass mode, especially in cases with extremely large I-frames.

[LoRd_MuldeR]

Avidemux 2.5.2 Final (2009-12-19)
http://www.avidemux.org/

Revision 5660 [2.5.2 Final] (19 Dec 2009)

What's New in Avidemux 2.5.2
* Re-enabled Vorbis decoder (regression introduced 2.5.0)
* Improved channel mapping of multichannel DTS & Vorbis audio
* Fixed decoding of 5.1 channel Vorbis audio in MKV files
* Updated the FFmpeg libraries
* Added support for latest x264 core and updated Qt interface
* Added support for H264 video, VP6A video and AAC audio in FLV container
* Added support for SEDG and WMVA four CCs
* Various fixes related to Xvid settings
* Fixed Xvid stat files remaining locked after encoding (regression introduced 2.5.0)
* Improved MKV demuxer
* New Colour Curve Editor plugin for Qt interface
* Fixed partial filter support (regression introduced 2.5.0)
* Fixed FluxSmooth filter plugin (regression introduced 2.5.0)
* Fixed saving of filter parameters for Rotate and Equaliser plugins (regression introduced 2.5.0)
* Added extra bitrate settings for LAME audio encoder
* Enabled JACK audio device plugin (regression introduced 2.5.0)
* Various GUI fixes for GTK+ and Qt interface
* Fixed command-line interface support for various video filters
* Changed "save-jpg" parameter of command-line interface to honour "begin" parameter
* Fixed saving of crash file when Avidemux unexpectedly quits (regression introduced in 2.5.0)
* Fixed GUI quirks when using Copy mode and AVI un/packing
* Further improvements to Unicode support for filenames on MS Windows
* Various minor fixes and enhancements

5659 - [Equalizer] Fix load/save
5658 - [Rotate] Fix load/save of rotate filter
5657 - [i18n] Fix buffer overflow with large language (greek) launchpad 344528
5656 - [i18n] Italian translation update by zoppo
5655 - [Osx] Patch by surfer
5636 - [po] Chinese traditional update by Dongjun Wu
5624 - [VORBIS] Fix channel layout for multichannel vorbis track, refs #60 and #61
5623 - [MKV] Fix vorbis multichannel loading, fixes #61
5617 - [mkv] Dont trow away headers if they are short
5616 - [AAC] encoder, channel mapping take two , ref #60
5615 - [AAC] Slightly better channel mapping (?) ref #60
5611 - [x264] support old bframe as references setting
5610 - [DTS] Change channel decoding layout
5609 - [i18n] Hu update by alaci
5608 - [core] fcntl.h include (arch/jh3h3 post)
5605 - [ffmpeg] update ffmpeg & libswscale tarballs
5604 - [win32] use avidemux open function instead when checking if file system is writeable
5603 - [x264] add bframe as references option to correct xml block

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

Avidemux 2.5.2 r5676 (2009-12-20)
http://www.avidemux.org/

Revision 5676 (20 Dec 2009)
# Packaged using NSIS 2.46.
# Updated GTK+ to version 2.18.5-1.
# Updated libpng to version 1.2.40-1.
# Updated Pango to version 1.26.1-1.
# Updated Qt to version 4.6.0.
# Updated x264 to r1376.

5676 - [Win64] don't enable FFmpeg memalign hack for Win64 since it isn't necessary
5675 - [Win64] disable custom memory functions for Win64 since Qt doesn't like it and mingw-w64 allocates 4-byte aligned
5674 - [ffmpeg] no need to build ffplay
5673 - [ffmpeg] update FFmpeg to r20900 & libswscale r30075
5672 - [general] bump version
5671 - [Win64] compilation fix for srt plugin
5670 - [general] tweaks to remove unnecessary compiler warning
5669 - [odml] fix calculation of extra data - use struct size not pointer size
5668 - [GTK] remove unused files
5667 - [Win32] update build scripts to support 64-bit build
5666 - [Win32] bump version of installer
5665 - [Win32] detect Windows 7
5664 - [ffmpeg] change usage of deprecated functions to new API
5663 - [ffmpeg] use av_free to clean up avcodec contexts
5662 - [mcdeint] link to libavutil since it was using an override function for av_free
5661 - [ffmpeg] remove overloaded av* memory functions and let ffmpeg libs look after themselves - it might break things that aren't correctly freed using av_free

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1376:

libx264-r1376, MinGW GCC 4.5.0, optimized for Core 2 (http://dl.dropbox.com/u/3191920/Beta/libx264/r1376/libx264-80-r1376M-gcc450-core2-fprofiled.7z)
libx264-r1376, MinGW GCC 4.5.0, optimized for K10 (http://dl.dropbox.com/u/3191920/Beta/libx264/r1376/libx264-80-r1376M-gcc450-amdfam10-fprofiled.7z)
libx264-r1376, MinGW GCC 4.5.0, optimized for Pentium III (http://dl.dropbox.com/u/3191920/Beta/libx264/r1376/libx264-80-r1376M-gcc450-pentium3-fprofiled.7z)
libx264-r1376, MinGW GCC 4.5.0, without ASM (slow!) (http://dl.dropbox.com/u/3191920/Beta/libx264/r1376/libx264-80-r1376M-gcc450-noasm-fprofiled.7z)
libx264-r1376, MinGW GCC 3.4.5, legacy build (http://dl.dropbox.com/u/3191920/Beta/libx264/r1376/libx264-80-r1376M-gcc345-i686-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5676 (http://forum.doom9.org/showpost.php?p=1355245&postcount=1422) or later now!

Re-compiled x264 r1376 with core-80. This will make it work with the latest Avidemux 2.5.2 SVN build, not with the 2.5.2 Final!

[Abradoks]

I don't use Avidemux much, but I've noticed some problems with it. Here are samples:
1) s.avi (http://rghost.ru/763711) — problem with sound (maybe corrupted source). Audio device: Win32 — crash; SDL — silence; Dummy — OK.
2) huff.mkv (http://rghost.ru/763714) — huffyuv in mkv. Isn't decoded correctly, junk instead of picture. huffyuv in avi works correctly.
3) x264.mp4 (http://rghost.ru/763716) — x264 (cli) output. No first frame (sometimes can display random or last decoded frame instead of it), no last frame.
4) x264.mkv (http://rghost.ru/763715) — x264 (cli) output. Not working at all.
Windows XP, Avidemux 2.5.2.5660.

[LoRd_MuldeR]

Avidemux 2.5.2 r5747 (2009-12-28)
http://www.avidemux.org/

Revision 5747 (28 Dec 2009)

Revision 5676 (20 Dec 2009)
# Packaged using NSIS 2.46.
# Updated GTK+ to version 2.18.5-1.
# Updated libpng to version 1.2.40-1.
# Updated Pango to version 1.26.1-1.
# Updated Qt to version 4.6.0.
# Updated x264 to r1376.

5747 - [mpeg-1] add Video CD configuration
5746 - [qt] add a recent projects menu option to Qt interface
5745 - [qt] increase recent files list from 4 to 6 for Qt interface and smarten saving of prefs
5744 - [mpeg-1] unix compilation fix
5743 - [mpeg-1] add Xvid rate control to MPEG-1 avcodec video plugin
5735 - [x264] fix handling of bFrameReferences with earlier versions of x264
5734 - [i420] support I420 video
5713 - [Win64] fix compilation error (r5712)
5712 - [Win64] fix fast memory copy
5680 - [Win64] fix script to use correct config path for 64-bit build
5679 - [Win64] fix compilation error for Yadif plugin on Win64
5678 - [Win32] remove 32-bit object files since they're already dynamically built and not 64-bit compatible
5677 - [Win64] check for existing definition of constants to suppress unnecessary warnings with mingw-w64

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

Avidemux 2.5.2 r5775 (2009-12-29)
http://www.avidemux.org/

Revision 5775 (29 Dec 2009)

Revision 5747 (28 Dec 2009)

Revision 5676 (20 Dec 2009)
# Packaged using NSIS 2.46.
# Updated GTK+ to version 2.18.5-1.
# Updated libpng to version 1.2.40-1.
# Updated Pango to version 1.26.1-1.
# Updated Qt to version 4.6.0.
# Updated x264 to r1376.

5775 - [qt] increase number of visible items for comboboxes on main Qt gui
5774 - [mjpeg] remove old mjpeg logic
5773 - [dlgFactory] increase the number of controls the dialogFactory's frame can host
5772 - [jpeg] use avcodec directly for jpeg instead of old mjpeg plugin
5771 - [mjpeg] avcodec M-JPEG video plugin
5757 - [flv1] remove old flv1 logic
5756 - [flv1] avcodec FLV1 video plugin
5755 - [moeg] remove more remnants
5754 - [dlgFactory] initialise variable to prevent crash with GTK config menu
5753 - [mpeg] remove more remnants
5752 - [mpeg] remove old avcodec mpeg-1 and mpeg-2 logic
5751 - [win32] update installer to include configurations and delete old installer
5750 - [mpeg-2] add SVCD and DVD configurations
5749 - [mpeg2] avcodec MPEG-2 video plugin
5748 - [vidEnc] change plugin options class so it is no longer intended as singleton

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

Avidemux 2.5.2 r5801 (2010-01-02)
http://www.avidemux.org/

5810 - [muxer] always set muxer back to defaults if config not specified in JavaScript
5809 - [win32] tweaks to build scripts
5808 - [mpeg2enc] skeleton for mpeg2enc plugin
5807 - [gui] update copyright year
5806 - [gui] remove avi muxer menu option and redundant Qt actions
5805 - [mpeg-ps] make mpeg-ps muxer configurable
5804 - [Filter] Fix partial filer, closes #66
5803 - [win32] update scripts to package 32 & 64-bit
5802 - [mkv] Ignore CRC and other tags when present, fixes #70
5801 - [vidEnc] fix installation of UI libraries

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

Avidemux 2.5.2 r5830 (2010-01-07)
http://www.avidemux.org/

Revision 5830 (07 Jan 2010)
# Compiled with GCC 4.4.3 pre-release (r155431).

5830 - [ffmpeg] update FFmpeg to r21066 & libswscale r30236
5829 - [win32] fast memory copy fix for mingw-w32
5828 - [win32] update installer script to bundle different GCC files
5827 - [Avi] Fix weird dv-avi files with fq=0, put 48kHz
5823 - [macosx] disable correct preferences action on main Qt interface
5818 - [mpeg-ps] fix regression in mpeg-ps muxer preventing mpeg2enc SVCD and DVD from working
5817 - [js] fix output when there are no muxer settings
5810 - [muxer] always set muxer back to defaults if config not specified in JavaScript
5809 - [win32] tweaks to build scripts
5808 - [mpeg2enc] skeleton for mpeg2enc plugin
5807 - [gui] update copyright year
5806 - [gui] remove avi muxer menu option and redundant Qt actions
5805 - [mpeg-ps] make mpeg-ps muxer configurable
5804 - [Filter] Fix partial filer, closes #66
5803 - [win32] update scripts to package 32 & 64-bit
5802 - [mkv] Ignore CRC and other tags when present, fixes #70
5801 - [vidEnc] fix installation of UI libraries

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1378:

libx264-r1378, MinGW GCC 4.5.0, generic build (http://dl.dropbox.com/u/3191920/Beta/libx264/r1378/libx264-80-r1378M-gcc450-i686-fprofiled.7z)
libx264-r1378, MinGW GCC 4.5.0, optimized for Core 2 (http://dl.dropbox.com/u/3191920/Beta/libx264/r1378/libx264-80-r1378M-gcc450-core2-fprofiled.7z)
libx264-r1378, MinGW GCC 4.5.0, optimized for K10 (http://dl.dropbox.com/u/3191920/Beta/libx264/r1378/libx264-80-r1378M-gcc450-amdfam10-fprofiled.7z)
libx264-r1378, MinGW GCC 4.5.0, optimized for Pentium III (http://dl.dropbox.com/u/3191920/Beta/libx264/r1378/libx264-80-r1378M-gcc450-pentium3-fprofiled.7z)
libx264-r1378, MinGW GCC 4.5.0, without ASM (slow!) (http://dl.dropbox.com/u/3191920/Beta/libx264/r1378/libx264-80-r1378M-gcc450-noasm-fprofiled.7z)
libx264-r1378, MinGW GCC 3.4.5, legacy build (http://dl.dropbox.com/u/3191920/Beta/libx264/r1378/libx264-80-r1378M-gcc345-i686-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5830 (http://forum.doom9.org/showpost.php?p=1361233&postcount=1428) or later now!

The libx264 DLL is now compiled with static pthreads library. So far this seems to work fine for me...

[lych_necross]

The libx264 DLL is now compiled with static pthreads library. So far this seems to work fine for me...
What is the risk of using static pthreads?

[LoRd_MuldeR]

What is the risk of using static pthreads?

There is no "risk". Or there shouldn't be a risk, at least ;)

All those builds of x264.exe usually link pthreads as a static library (no dependency on pthreadsGC2.dll). It only didn't work with the libx264 DLL before that (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=d26e79d982ec6d0aea40e6d0b21ee799994007ca) revision.

[LoRd_MuldeR]

My libx264 r1378 (http://forum.doom9.org/showpost.php?p=1364712&postcount=1429) builds have been updated. Previous builds would have crashed with ME=ESA, at least the "Core2" optimized ones :o

It turns out that GCC 4.x with "-march=core2" breaks the DLL, unless "-fno-tree-vectorize" is used. There is no such problem with the CLI encoder through.

Apparently only ESA mode was broken. So as long as you didn't use such "placebo" setting, you probably never ran into the problem :)

[wata]

i stop updating Avidemux after r5341 because x264 SEI/encoding informations is not embedded into mp4/mkv final encode files
anyone encoding to mp4/mkv with the latest version can check for me if sei info is restore
thanks

[LoRd_MuldeR]

i stop updating Avidemux after r5341 because x264 SEI/encoding informations is not embedded into mp4/mkv final encode files
anyone encoding to mp4/mkv with the latest version can check for me if sei info is restore
thanks

It has been explained more than enough that this the result of the major x264 API change, back in r1260 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=031e25d8cc909af2d138f9fedc8252961f34a6ac) ;)

[Dark Shikari]

It has been explained more than enough that this the result of the major x264 API change, back in r1260 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=031e25d8cc909af2d138f9fedc8252961f34a6ac) ;)No it isn't. If Avidemux does not write the SEI header, it is bugged and broken and should not be used.

[DarkZell666]

No it isn't. If Avidemux does not write the SEI header, it is bugged and broken and should not be used.

If by "bugged" you mean "Avidemux wasn't updated to support the new API fully" then yes, it's true. Otherwise I don't understand. Do you mean the produced MP4 files aren't spec-compliant in this case ?

[Dark Shikari]

If by "bugged" you mean "Avidemux wasn't updated to support the new API fully" then yes, it's true. Otherwise I don't understand.But there's nothing different about the new API that would result in the SEI not being written now. Absolutely nothing whatsoever changed with respect to SEI handling.Do you mean the produced MP4 files aren't spec-compliant in this case ?If an application that claims to be an x264 frontend is throwing out some of the information that x264 told it to write, it's doing it very wrong.

[LoRd_MuldeR]

No it isn't. If Avidemux does not write the SEI header, it is bugged and broken and should not be used.

That statement is grossly exaggerated!

If Avidemux discards the SEI header when it shouldn't, then there's a bug hiding somewhere in the muxer code. Plain and simple.

Bugs occasionally occur in software development, that's a fact. The 100% bug-free software doesn't exist. I think I don't need to explain that to you ;)

Also this bug definitely is a result of the aforementioned x264 API change, because before the API change Avidemux didn't exhibit the bug.

Furthermore I wouldn't consider that a serious bug. Anyway, I will try to bug Gruntster about the issue again...

If an application that claims to be an x264 frontend is throwing out some of the information that x264 told it to write, it's doing it very wrong.

Avidemux never claimed to be a x264 front-end. It's a fully-fledged video editor, which offers many editing, filtering and encoding capabilities.

More specifically it supports many audio and video encoders. x264 is only one of them.

Yes, currently there is a (minor) bug that occurs if one specific encoder (x264) is combined with a specific muxer (MP4 or MKV). So what?

Supporting a great variety of audio and video encoders in combination with several muxers isn't as simple as creating a GUI around an existing CLI tool!

What we need here is some helpful information to track down the bug, not polemics...

[Dark Shikari]

That statement is grossly exaggerated!

If Avidemux discards the SEI header when it shouldn't, then there's a bug hiding somewhere in the muxer code. Plain and simple.

Bugs occasionally occur in software development, that's a fact. The 100% bug-free software doesn't exist. I think I don't need to explain that to you ;)Yes, but at least I go immediately fix bugs when people report them to me ;)

[shiloto]

Hello. Im having some troubles with avidemux. Using version 2.5.2 to split and reencode video files - x264(720p) in this case. Problem is when i load the video i get heavy suttering of audio and video. I tryed using both the normal method and the alternitive for B-frames in h264. Same thing. I used to do the same stuff with avidemux before didnt have such problems.

I saw now that changing video display to MS directx fixed video lag, and theres only 2-3 seconds audio delay, but copying video copies the audio delay too....

[Brazil2]

If Avidemux discards the SEI header when it shouldn't, then there's a bug hiding somewhere in the muxer code. Plain and simple.
Just a reminder ;)

http://forum.doom9.org/showthread.php?p=1351866#post1351866

[Abradoks]

BTW, what about problem samples I've posted (http://forum.doom9.org/showthread.php?p=1357266#post1357266)? Are they known issues (especially x264 outputs)?
Also I have MPEG-TS AVC 1080i sample, that avidemux can't decode properly (loses frame accuracy) even aften remuxing into mkv. Should I upload it?

[LoRd_MuldeR]

Yes, but at least I go immediately fix bugs when people report them to me ;)

Avidemux developers try to do the same. But they don't have an infinite amount of time, so not everything can be fixed "immediately" ;)

Rev & Author: Rev 5868 - gruntster - Go to most recent revision
Last modification: Rev 5868 - 2010-01-23 14:31:40 GMT
Log message: [x264] don't drop SEI userdata from x264 encoder.
FFmpeg muxers ignore the SEI when placed in extradata so insert in front of first video frame instead.

[LoRd_MuldeR]

libx264 SVN-r1378:

libx264-r1378, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/wyejiw5jmae/libx264-80-r1378M-gcc450-i686-fprofiled.7z)
libx264-r1378, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/5zmm3zjzjty/libx264-80-r1378M-gcc450-core2-fprofiled.7z)
libx264-r1378, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/rmyzqtdhiyy/libx264-80-r1378M-gcc450-amdfam10-fprofiled.7z)
libx264-r1378, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/nzy4hnmotyn/libx264-80-r1378M-gcc450-pentium3-fprofiled.7z)
libx264-r1378, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/nuntwntv1wy/libx264-80-r1378M-gcc450-noasm-fprofiled.7z)
libx264-r1378, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/tmjnnwydw40/libx264-80-r1378M-gcc345-i686-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5830 (http://forum.doom9.org/showpost.php?p=1361233&postcount=1428) or later now!

Re-uploaded the r1378 builds to a new mirror, as the Dropbox links are currently disabled...

[LoRd_MuldeR]

Avidemux 2.5.2 r5869 (2010-01-23)
http://www.avidemux.org/

Revision 5869 (23 Jan 2010)
# Updated GLib to version 2.22.4-1.
# Updated Qt to version 4.6.1.
# Updated x264 to r1400.

5869 - [win32] update build script to include DirectX headers
5868 - [x264] don't drop SEI userdata from x264 encoder. FFmpeg muxers ignore the SEI when placed in extradata so insert in front of first video frame instead.
5867 - [ffmpeg] move from newly deprecated function
5866 - [ffmpeg] ensure Yasm is installed and DXVA2 is detected on Win32
5865 - [ffmpeg] update FFmpeg to r21394 & libswscale to r30400
5862 - [ffmpeg] update FFmpeg to r21328 & libswscale to r30376
5859 - [avsProxy] Audio support (not tested much)
5858 - [avsproxy] Sync with avsproxy from 2.6, part 1, no audio
5848 - [i18n] Catalan update by Joan Farrerons
5832 - [Ass] Update libass to git version + tweak a bit CMakelist.txt to enable fontconfig/freetype if they are there
5831 - [filter] fix partial when child has parameters, fixes #66, again.
5830 - [ffmpeg] update FFmpeg to r21066 & libswscale r30236

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[Dark Shikari]

Ah, so Avidemux uses the lavf muxers; that would explain the disappearing SEI.

We had to compensate for that in libx264.c in ffmpeg too.

[LoRd_MuldeR]

libx264 SVN-r1400:

libx264-r1400, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/j2dzmlgzzmh/libx264-83-r1400M-gcc450-core2-fprofiled.7z)
libx264-r1400, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/iyaiijfr22w/libx264-83-r1400M-gcc450-amdfam10-fprofiled.7z)
libx264-r1400, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/ttrym0z0ayl/libx264-83-r1400M-gcc450-pentium3-fprofiled.7z)
libx264-r1400, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/iwtfocz1rjz/libx264-83-r1400M-gcc450-i686-fprofiled.7z)
libx264-r1400, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/ykxemz21uyz/libx264-83-r1400M-gcc450-noasm-fprofiled.7z)

libx264-r1400, MinGW GCC 4.4.3, optimized for Core 2 (http://www.mediafire.com/file/iaiuniruyyy/libx264-83-r1400M-gcc443-core2-fprofiled.7z)
libx264-r1400, MinGW GCC 4.4.3, optimized for K10 (http://www.mediafire.com/file/4zbdhmkr4ml/libx264-83-r1400M-gcc443-amdfam10-fprofiled.7z)
libx264-r1400, MinGW GCC 4.4.3, optimized for Pentium III (http://www.mediafire.com/file/mizlnz5klux/libx264-83-r1400M-gcc443-pentium3-fprofiled.7z)
libx264-r1400, MinGW GCC 4.4.3, generic build (http://www.mediafire.com/file/dcxkvmnjjjn/libx264-83-r1400M-gcc443-i686-fprofiled.7z)
libx264-r1400, MinGW GCC 4.4.3, without ASM (slow!) (http://www.mediafire.com/file/hvyr2wjm54e/libx264-83-r1400M-gcc443-noasm-fprofiled.7z)

libx264-r1400, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/nkyuuzh0vmo/libx264-83-r1400M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1400 with Periodic Intra Refresh:

libx264-r1400, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/4mzvz5kj4lj/libx264-83-r1400M-PIR-gcc450-core2-fprofiled.7z)
libx264-r1400, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/nivrqom20x1/libx264-83-r1400M-PIR-gcc450-amdfam10-fprofiled.7z)
libx264-r1400, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/kehdjuhejkg/libx264-83-r1400M-PIR-gcc450-pentium3-fprofiled.7z)
libx264-r1400, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/huyzictv32g/libx264-83-r1400M-PIR-gcc450-i686-fprofiled.7z)
libx264-r1400, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/zy3qzbmjzyz/libx264-83-r1400M-PIR-gcc450-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5869 (http://forum.doom9.org/showpost.php?p=1367103&postcount=1445) or later now!

Now that the latest Avidemux supports x264 r1400+, here's a full set of GCC 4.5.0 (experimental) and GCC 4.4.3 (stable) builds.

[LoRd_MuldeR]

Announcement: I have updated the AVS Proxy GUI to support Audio delivery! :cool:
http://avidemux.org/admForum/viewtopic.php?id=4397

Please note that you will need Avidemux 2.5 r5869 or later to make this work. The Avidemux 2.6 nightly works too.

Also note that currently there MUST be audio. If the AVS script doesn't return Audio, it will be refused!

[arapkadri]

thanks so much for this beautiful presentation LoRd_MuldeR :):p

[LoRd_MuldeR]

Announcement: I have updated the AVS Proxy GUI to support Audio delivery! :cool:
http://avidemux.org/admForum/viewtopic.php?id=4397

Please note that you will need Avidemux 2.5 r5869 or later to make this work. The Avidemux 2.6 nightly works too.

Also note that currently there MUST be audio. If the AVS script doesn't return Audio, it will be refused!

The AVS Proxy has been updated again in order to support both, AVS scripts with and without audio.

[LoRd_MuldeR]

libx264 SVN-r1414:

libx264-r1414, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/u2yfntwydz2/libx264-83-r1414M-gcc450-core2-fprofiled.7z)
libx264-r1414, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/umwmmm0xc0r/libx264-83-r1414M-gcc450-amdfam10-fprofiled.7z)
libx264-r1414, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/gezmqanojfj/libx264-83-r1414M-gcc450-pentium3-fprofiled.7z)
libx264-r1414, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/jknnnjylnzz/libx264-83-r1414M-gcc450-i686-fprofiled.7z)
libx264-r1414, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/njznmhizwin/libx264-83-r1414M-gcc450-noasm-fprofiled.7z)

libx264-r1414, MinGW GCC 4.4.3, optimized for Core 2 (http://www.mediafire.com/file/gujhftwdzmz/libx264-83-r1414M-gcc443-core2-fprofiled.7z)
libx264-r1414, MinGW GCC 4.4.3, optimized for K10 (http://www.mediafire.com/file/tntzmtmmofw/libx264-83-r1414M-gcc443-amdfam10-fprofiled.7z)
libx264-r1414, MinGW GCC 4.4.3, optimized for Pentium III (http://www.mediafire.com/file/zyin5dnqdz5/libx264-83-r1414M-gcc443-pentium3-fprofiled.7z)
libx264-r1414, MinGW GCC 4.4.3, generic build (http://www.mediafire.com/file/n0nmmmtywoz/libx264-83-r1414M-gcc443-i686-fprofiled.7z)
libx264-r1414, MinGW GCC 4.4.3, without ASM (slow!) (http://www.mediafire.com/file/gqjdmtoyukm/libx264-83-r1414M-gcc443-noasm-fprofiled.7z)

libx264-r1414, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/y3v3n4wew2t/libx264-83-r1414M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1414 with Periodic Intra Refresh:

libx264-r1414, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/1y235nzzjly/libx264-83-r1414M-PIR-gcc450-core2-fprofiled.7z)
libx264-r1414, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/zzvgzunzmi3/libx264-83-r1414M-PIR-gcc450-amdfam10-fprofiled.7z)
libx264-r1414, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/45qbtmwwncz/libx264-83-r1414M-PIR-gcc450-pentium3-fprofiled.7z)
libx264-r1414, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/mmazzmt4mkm/libx264-83-r1414M-PIR-gcc450-i686-fprofiled.7z)
libx264-r1414, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/21dimyjmwmg/libx264-83-r1414M-PIR-gcc450-noasm-fprofiled.7z)

libx264-r1414, MinGW GCC 4.4.3, optimized for Core 2 (http://www.mediafire.com/file/mjgmiznzzgj/libx264-83-r1414M-PIR-gcc443-core2-fprofiled.7z)
libx264-r1414, MinGW GCC 4.4.3, optimized for K10 (http://www.mediafire.com/file/4njhe4umtxt/libx264-83-r1414M-PIR-gcc443-amdfam10-fprofiled.7z)
libx264-r1414, MinGW GCC 4.4.3, optimized for Pentium III (http://www.mediafire.com/file/jznmztn4dkn/libx264-83-r1414M-PIR-gcc443-pentium3-fprofiled.7z)
libx264-r1414, MinGW GCC 4.4.3, generic build (http://www.mediafire.com/file/hzdzmgnoniy/libx264-83-r1414M-PIR-gcc443-i686-fprofiled.7z)
libx264-r1414, MinGW GCC 4.4.3, without ASM (slow!) (http://www.mediafire.com/file/ymlx1fmmhit/libx264-83-r1414M-PIR-gcc443-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5869 (http://forum.doom9.org/showpost.php?p=1367103&postcount=1445) or later now!

[LoRd_MuldeR]

libx264 SVN-r1416:

libx264-r1416, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/rtlln2dimem/libx264-83-r1416M-gcc450-core2-fprofiled.7z)
libx264-r1416, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/rwinyzzzmww/libx264-83-r1416M-gcc450-amdfam10-fprofiled.7z)
libx264-r1416, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/ndvqozygdhg/libx264-83-r1416M-gcc450-pentium3-fprofiled.7z)
libx264-r1416, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/zzzjwbdzrqb/libx264-83-r1416M-gcc450-i686-fprofiled.7z)
libx264-r1416, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/zyzzejdzyng/libx264-83-r1416M-gcc450-noasm-fprofiled.7z)

libx264-r1416, MinGW GCC 4.4.3, optimized for Core 2 (http://www.mediafire.com/file/nmuwonmimnj/libx264-83-r1416M-gcc443-core2-fprofiled.7z)
libx264-r1416, MinGW GCC 4.4.3, optimized for K10 (http://www.mediafire.com/file/y1jotyatnt0/libx264-83-r1416M-gcc443-amdfam10-fprofiled.7z)
libx264-r1416, MinGW GCC 4.4.3, optimized for Pentium III (http://www.mediafire.com/file/zd2yzmhonlm/libx264-83-r1416M-gcc443-pentium3-fprofiled.7z)
libx264-r1416, MinGW GCC 4.4.3, generic build (http://www.mediafire.com/file/jnfz1zmqyd5/libx264-83-r1416M-gcc443-i686-fprofiled.7z)
libx264-r1416, MinGW GCC 4.4.3, without ASM (slow!) (http://www.mediafire.com/file/ujiul2zamml/libx264-83-r1416M-gcc443-noasm-fprofiled.7z)

libx264-r1416, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/znxeqzwnmdl/libx264-83-r1416M-gcc345-i686-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5869 (http://forum.doom9.org/showpost.php?p=1367103&postcount=1445) or later now!

[lych_necross]

Do your builds still include the subme 10 patch?

[LoRd_MuldeR]

Do your builds still include the subme 10 patch?

Sure. Look at the log ;)

That "hack" will remain, until Avidemux finally exposes SubME=10 in the GUI. Unfortunately it seems that request got lost in the noise somehow...

[lych_necross]

Well, there it is. Can't believe I missed. Must be astigmatism :D

[LoRd_MuldeR]

libx264 SVN-r1442:

libx264-r1442, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/5kmnw1mmzze/libx264-83-r1442M-gcc450-core2-fprofiled.7z)
libx264-r1442, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/m0hznzeukvj/libx264-83-r1442M-gcc450-amdfam10-fprofiled.7z)
libx264-r1442, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/4lozqz4qzqg/libx264-83-r1442M-gcc450-pentium3-fprofiled.7z)
libx264-r1442, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/id1akmzmjwy/libx264-83-r1442M-gcc450-i686-fprofiled.7z)
libx264-r1442, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/j3xtmon3wgm/libx264-83-r1442M-gcc450-noasm-fprofiled.7z)

libx264-r1442, MinGW GCC 4.4.3, optimized for Core 2 (http://www.mediafire.com/file/kmkynnmvhvy/libx264-83-r1442M-gcc443-core2-fprofiled.7z)
libx264-r1442, MinGW GCC 4.4.3, optimized for K10 (http://www.mediafire.com/file/udnyfmnemmr/libx264-83-r1442M-gcc443-amdfam10-fprofiled.7z)
libx264-r1442, MinGW GCC 4.4.3, optimized for Pentium III (http://www.mediafire.com/file/tmmywmjjx3n/libx264-83-r1442M-gcc443-pentium3-fprofiled.7z)
libx264-r1442, MinGW GCC 4.4.3, generic build (http://www.mediafire.com/file/yfy1ajuhyzi/libx264-83-r1442M-gcc443-i686-fprofiled.7z)
libx264-r1442, MinGW GCC 4.4.3, without ASM (slow!) (http://www.mediafire.com/file/xcqizmurlnj/libx264-83-r1442M-gcc443-noasm-fprofiled.7z)

libx264-r1442, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/jzw0nzxyidm/libx264-83-r1442M-gcc345-i686-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5869 (http://forum.doom9.org/showpost.php?p=1367103&postcount=1445) or later now!

[LoRd_MuldeR]

Avidemux 2.5.2 r5955 (2010-02-28)
http://www.avidemux.org/

Revision 5955 (28 Feb 2010)
# Compiled with GCC 4.4.3.
# Updated Cairo to version 1.8.10-1.
# Updated Freetype to version 2.3.11-2.
# Updated GTK+ to version 2.18.7-1.
# Updated LAME to version 3.98.3.
# Updated libpng to version 1.4.0-1.
# Updated NSPR to version 4.8.3.
# Updated Pango to version 1.26.2-1.
# Updated Qt to version 4.6.2.
# Updated x264 to r1471.

5955 - [ffmpeg] update FFmpeg to r22111 & libswscale to r30800
5954 - [lavc audio] fix undefined references
5953 - [audio-lavcodec] Fix crash when deleting encoder
5952 - [mpeg1/2-lavcodec] Fix crash when encoding single pass
5935 - [win32] update build scripts with latest dependencies
5934 - [ffmpeg] update FFmpeg to r21837 & libswscale to r30589
5933 - [encoder] Cannot use context->pix_fmt in open as context is not allocated yet. it does not crash anymore, not sure it is 100% what was wanted, ref #77
5932 - [script] pal2film != pal2Film, fixes #78
5876 - [editor] remove 100 video restriction
5870 - [ffmpeg] only check for Yasm on x86
5869 - [win32] update build script to include DirectX headers

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[hlrsnd]

I can't get the AVS Proxy to work in r5955. Trying to work with a 640x480 camera mjpeg video. External script, AVISource, and DShowSource all crash.

Video and external script open fine in Virtualdub. Running Win7 32 bit and ffdshow tryouts. Suggestions welcome.

[lych_necross]

Avidemux 2.5.2 r5955 still contains the old version of AVS Proxy. You need to download the updated version here (http://avidemux.org/admForum/viewtopic.php?id=4397).

[LoRd_MuldeR]

Avidemux 2.5.2 r5955 still contains the old version of AVS Proxy. You need to download the updated version here (http://avidemux.org/admForum/viewtopic.php?id=4397).

..but the good news is: Once you have updated the AVS Proxy GUI it will deliver audio now :)

[LoRd_MuldeR]

libx264 SVN-r1471:

libx264-r1471, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/ydmm3wfizmz/libx264-88-r1471M-gcc450-core2-fprofiled.7z)
libx264-r1471, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/ndkotj0ijtm/libx264-88-r1471M-gcc450-amdfam10-fprofiled.7z)
libx264-r1471, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/n0ydyzh2moy/libx264-88-r1471M-gcc450-pentium3-fprofiled.7z)
libx264-r1471, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/k2coymk2c1j/libx264-88-r1471M-gcc450-i686-fprofiled.7z)
libx264-r1471, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/ydemayjdnmr/libx264-88-r1471M-gcc450-noasm-fprofiled.7z)

libx264-r1471, MinGW GCC 4.4.3, optimized for Core 2 (http://www.mediafire.com/file/3y3zdjmmj1i/libx264-88-r1471M-gcc443-core2-fprofiled.7z)
libx264-r1471, MinGW GCC 4.4.3, optimized for K10 (http://www.mediafire.com/file/2ooyu5izvjz/libx264-88-r1471M-gcc443-amdfam10-fprofiled.7z)
libx264-r1471, MinGW GCC 4.4.3, optimized for Pentium III (http://www.mediafire.com/file/qmiqjytwzty/libx264-88-r1471M-gcc443-pentium3-fprofiled.7z)
libx264-r1471, MinGW GCC 4.4.3, generic build (http://www.mediafire.com/file/tjzmknnvw2m/libx264-88-r1471M-gcc443-i686-fprofiled.7z)
libx264-r1471, MinGW GCC 4.4.3, without ASM (slow!) (http://www.mediafire.com/file/ox2i0zzkaj2/libx264-88-r1471M-gcc443-noasm-fprofiled.7z)

libx264-r1471, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/5mmmhhhn1u2/libx264-88-r1471M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1471 with AutoVAQ enabled:

libx264-r1471, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/bewymwazriw/libx264-88-r1471M-AutoVAQ-gcc450-core2-fprofiled.7z)
libx264-r1471, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/5zmzmyzkymj/libx264-88-r1471M-AutoVAQ-gcc450-amdfam10-fprofiled.7z)
libx264-r1471, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/jmyirmwmmxw/libx264-88-r1471M-AutoVAQ-gcc450-pentium3-fprofiled.7z)
libx264-r1471, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/lqcz3zqm4bg/libx264-88-r1471M-AutoVAQ-gcc450-i686-fprofiled.7z)


libx264 SVN-r1471 with Periodic Intra Refresh enabled:

libx264-r1471, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/mqiwyydz3yg/libx264-88-r1471M-PIR-gcc450-core2-fprofiled.7z)
libx264-r1471, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/dyg4yjzhjjm/libx264-88-r1471M-PIR-gcc450-amdfam10-fprofiled.7z)
libx264-r1471, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/mymnmjmzf0o/libx264-88-r1471M-PIR-gcc450-pentium3-fprofiled.7z)
libx264-r1471, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/ecnzwmjwzth/libx264-88-r1471M-PIR-gcc450-i686-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5955 (http://forum.doom9.org/showpost.php?p=1378821&postcount=1457) or later now!

Note that "AQ method 2" (aka AutoVAQ) now is equal to what was known as "AQ method 4" (only available via patch) before.

[hlrsnd]

..but the good news is: Once you have updated the AVS Proxy GUI it will deliver audio now :)

The new AVS Proxy fixed everything. Thanks. I assumed it was included in r5955.

[LoRd_MuldeR]

The new AVS Proxy fixed everything. Thanks. I assumed it was included in r5955.

Actually it contains the proper AVS Proxy, but an outdated version of the AVS Proxy GUI ;)

[lych_necross]

Actually it contains the proper AVS Proxy, but an outdated version of the AVS Proxy GUI ;)
Well, the devil's in the details. :p

[Romario]

Can you compile new build please ? :)

[LoRd_MuldeR]

Can you compile new build please ? :)

New build of what? Latest revision of x264 still is r1471. And latest revision of Avidemux is r5999, with only three (http://svn.berlios.de/wsvn/avidemux/branches/avidemux_2.5_branch_gruntster/?op=log) minor changes since the r5955 build.

[LoRd_MuldeR]

Here's a new set of libx264 r1471 builds, re-compiled with GCC 4.5.0 2010-03-20:

libx264 SVN-r1471:

libx264-r1471, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/2yicdynyjk5/libx264-88-r1471M-gcc450-core2-fprofiled.7z)
libx264-r1471, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/cnvtromyguq/libx264-88-r1471M-gcc450-amdfam10-fprofiled.7z)
libx264-r1471, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/ruemtnymmwe/libx264-88-r1471M-gcc450-pentium3-fprofiled.7z)
libx264-r1471, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/hbjmhh4vmmy/libx264-88-r1471M-gcc345-i686-fprofiled.7z)
libx264-r1471, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/zzuwdjyomnz/libx264-88-r1471M-gcc450-noasm-fprofiled.7z)


libx264 SVN-r1471 with AutoVAQ (formerly known as "AQ method 4") enabled:

libx264-r1471, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/wndt2yomi40/libx264-88-r1471M-AutoVAQ-gcc450-core2-fprofiled.7z)
libx264-r1471, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/njmmx3ehzzf/libx264-88-r1471M-AutoVAQ-gcc450-amdfam10-fprofiled.7z)
libx264-r1471, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/ktewexzid5n/libx264-88-r1471M-AutoVAQ-gcc450-pentium3-fprofiled.7z)
libx264-r1471, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/yy2zmwnmhfb/libx264-88-r1471M-AutoVAQ-gcc450-i686-fprofiled.7z)
libx264-r1471, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/ij4qutzmohy/libx264-88-r1471M-AutoVAQ-gcc450-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r5955 (http://forum.doom9.org/showpost.php?p=1378821&postcount=1457) or later now!

[Romario]

No,last revision is 6014, look yourself http://svn.berlios.de/wsvn/avidemux/?op=log

Well,why not,it will be good for all of us if you compile newest Avidemux build.

And,I have additioal question,I don't know if you know that answer. What about Win64 support for Avidemux ? Because I saw some works for 64-bit Windows support in earlier revisions. Can you compile 64-bit Avidemux ?

[LoRd_MuldeR]

No,last revision is 6014, look yourself http://svn.berlios.de/wsvn/avidemux/?op=log


Wrong ;)

You are looking at the "root" folder, not at the "Avidemux 2.5" branch. So your log contains all changes, including those from the experimental "Avidemux 2.6" branch!

Currently Avidemux 2.6 is in a very early state: Experimental encoding support for Xvid has been added, but encoding support for x264 is still missing.

So for the time being, Avidemux 2.5 is what we want to use. And thus you have to look at the correct branch: http://svn.berlios.de/wsvn/avidemux/branches/avidemux_2.5_branch_gruntster/?op=log

But if you want to check out Avidemux 2.6 anyway, you can find "nightly" builds at this (http://www.avidemux.org/nightly/win32/) location. Use at your own risk and don't complain ;)

What about Win64 support for Avidemux ? Because I saw some works for 64-bit Windows support in earlier revisions. Can you compile 64-bit Avidemux ?

Gruntster did some work, but there were problems that have not been solved yet. If I remember correctly, some of the dependencies didn't compile properly...

[Romario]

Thank you,you are very kind man. May I ask you from which city are you in Germany ?

I have one more question: what about GCC 4.5, is this realease is stable enough, now ? And what good brings to us GCC 4.50 ? When to expect final version ?

[LoRd_MuldeR]

Thank you,you are very kind man. May I ask you from which city are you in Germany ?

Nope :p

I have one more question: what about GCC 4.5, is this realease is stable enough, now ? And what good brings to us GCC 4.50 ? When to expect final version ?

GCC 4.5.0 currently is in the "regression fix" phase. So they only fix show-stopper bugs which prevent a "stable" release.

http://gcc.gnu.org/gcc-4.5/changes.html · http://gcc.gnu.org/ml/gcc/2010-03/msg00155.html

[Romario]

Well,117 bugs...it's not promising. So before may or june, we can't expect final version of GCC 4.50, I suppose.

I look forward to future Avidemux 2.52 build. :)

[LoRd_MuldeR]

Well,117 bugs...it's not promising.

But only 16 out of 117 bugs are considered important enough to "block" a release. And I wouldn't assume that they had fewer bugs in previous versions ;)

Furthermore not all the bugs in GCC are necessarily related to C and/or x86. Remember that they support a lot of languages and architectures...

[Romario]

Yes,I forgot this, I get very strange videos when I put me-range=64 in Avidemux x264 1471 revision. My ffdshow won't decode it properly.

Can you look into this issue, please?

I have thread here, look http://forum.doom9.org/showthread.php?t=153162

[LoRd_MuldeR]

Yes,I forgot this, I get very strange videos when I put me-range=64 in Avidemux x264 1471 revision. My ffdshow won't decode it properly.

Can you look into this issue, please?

I have thread here, look http://forum.doom9.org/showthread.php?t=153162

ME-Range 64 is totally insane. Even the "placebo" preset uses only 24. And anything below "veryslow" preset uses the default (i.e. 16). Please don't do insane things ;)

Anyway, I encoded a clip with ME-Range 64 in Avidemux (using my r1471 build of libx264), just for testing, and the results plays just fine in MPlayer...

[Romario]

Oh,ok.Thanks for telling me this.

[LoRd_MuldeR]

Avidemux 2.5.2 r6028 (2010-03-27)
http://www.avidemux.org/

Revision 6028 (27 Mar 2010)
# Updated Avisynth Proxy GUI to version 2.11.
# Updated GLib to version 2.22.5-1.
# Updated GTK+ to version 2.18.9-1.
# Updated LAME to version 3.98.4.
# Updated Ogg to version 1.2.0.
# Updated NSPR to version 4.8.4.
# Updated Vorbis to version 1.3.1.

6028 - [ffmpeg] update FFmpeg to r22703 & libswscale to r30970
5999 - [Ac3] Handle dual channel audio, fixes #84
5963 - [aften] Fix channel reordering, backport from 2.6, fixes #81, refs #60
5962 - [Aften] Add support for aften svn as bundled by ubuntu + fix compilation flags for aften 0.8 and 0.8svn, probably still broken for 0.5/6/7
5955 - [ffmpeg] update FFmpeg to r22111 & libswscale to r30800

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1478:

libx264-r1478, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/onjznumzrcx/libx264-88-r1478M-gcc450-core2-fprofiled.7z)
libx264-r1478, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/z1bh4mzirtm/libx264-88-r1478M-gcc450-amdfam10-fprofiled.7z)
libx264-r1478, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/jmky03zdyim/libx264-88-r1478M-gcc450-pentium3-fprofiled.7z)
libx264-r1478, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/e5zdtj1tmyj/libx264-88-r1478M-gcc450-i686-fprofiled.7z)
libx264-r1478, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/wnmmwjxbwvz/libx264-88-r1478M-gcc450-noasm-fprofiled.7z)
libx264-r1478, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/zmwwgz1w3dr/libx264-88-r1478M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1478 with AutoVAQ enabled:

libx264-r1478, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/zmmr2mnyjyy/libx264-88-r1478M-AutoVAQ-gcc450-core2-fprofiled.7z)
libx264-r1478, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/z5nzq0ondkn/libx264-88-r1478M-AutoVAQ-gcc450-amdfam10-fprofiled.7z)
libx264-r1478, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/zxmzjqjinjw/libx264-88-r1478M-AutoVAQ-gcc450-pentium3-fprofiled.7z)
libx264-r1478, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/uookn4fygmo/libx264-88-r1478M-AutoVAQ-gcc450-i686-fprofiled.7z)
libx264-r1478, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/li3qzztzim3/libx264-88-r1478M-AutoVAQ-gcc450-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6028 (http://forum.doom9.org/showpost.php?p=1386813&postcount=1477) or later now!

Note: I currently cannot update libx264 beyond r1478, because there was yet another major API change (NAL-HRD support).

[Romario]

Wow,alerady build 1510 showed...it's so fast today. :))))

[LoRd_MuldeR]

Avidemux 2.5.2 r6064 (2010-04-05)
http://www.avidemux.org/

Revision 6064 (05 Apr 2010)
# Updated x264 to r1510.

6064 - [win32] update installer to include mpeg2enc plugin
6063 - [misc] cosmetic tidy-ups
6062 - [mpeg] update mpeg muxer to support mpeg2enc plugin
6061 - [mpeg2enc] port mpeg2enc logic for MPEG-1 to plugin
6060 - [avcodec] video encoder tidy-ups for avcodec plugin
6059 - [mpeg] add support for delayed frames to mpeg muxer
6058 - [mpeg2enc] finish porting of mpeg2enc logic for MPEG-2 to plugin
6032 - [mpeg demuxer] fix bad usage of getFlags() method
6031 - [bootstrap] Fix bootstrap_debug
6030 - [prefs] message level filter was not saved, closes #83
6029 - [mpeg2enc] more moving mpeg2enc to plugin
6028 - [ffmpeg] update FFmpeg to r22703 & libswscale to r30970

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1510:

libx264-r1510, MinGW GCC 4.4.3, optimized for Core 2 (http://www.mediafire.com/file/ymnggdi5go2/libx264-92-r1510M-gcc443-core2-fprofiled.7z)
libx264-r1510, MinGW GCC 4.4.3, optimized for K10 (http://www.mediafire.com/file/gmyctzdmzyz/libx264-92-r1510M-gcc443-amdfam10-fprofiled.7z)
libx264-r1510, MinGW GCC 4.4.3, optimized for Pentium III (http://www.mediafire.com/file/zmnndvgodej/libx264-92-r1510M-gcc443-pentium3-fprofiled.7z)
libx264-r1510, MinGW GCC 4.4.3, generic build (http://www.mediafire.com/file/um4t0jtmlm5/libx264-92-r1510M-gcc443-i686-fprofiled.7z)
libx264-r1510, MinGW GCC 4.4.3, without ASM (slow!) (http://www.mediafire.com/file/umw3qugz4rt/libx264-92-r1510M-gcc443-noasm-fprofiled.7z)
libx264-r1510, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/nwtmw1umkwz/libx264-92-r1510M-gcc345-i686-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6064 (http://forum.doom9.org/showpost.php?p=1389207&postcount=1480) or later now!

[LoRd_MuldeR]

libx264 SVN-r1510:

libx264-r1510, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/iymxzowwzyt/libx264-92-r1510M-gcc450-core2-fprofiled.7z)
libx264-r1510, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/53jemztziky/libx264-92-r1510M-gcc450-amdfam10-fprofiled.7z)
libx264-r1510, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/zmivzzjmwuz/libx264-92-r1510M-gcc450-pentium3-fprofiled.7z)
libx264-r1510, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/t2ml3m2lgmi/libx264-92-r1510M-gcc450-i686-fprofiled.7z)
libx264-r1510, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/2iymiig2naf/libx264-92-r1510M-gcc450-noasm-fprofiled.7z)


libx264 SVN-r1510 with AutoVAQ enabled:

libx264-r1510, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/wnjjykmyy21/libx264-92-r1510M-AutoVAQ-gcc450-core2-fprofiled.7z)
libx264-r1510, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/mddbii2jjiz/libx264-92-r1510M-AutoVAQ-gcc450-amdfam10-fprofiled.7z)
libx264-r1510, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/wymuthmzymy/libx264-92-r1510M-AutoVAQ-gcc450-pentium3-fprofiled.7z)
libx264-r1510, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/njtme1w2rtz/libx264-92-r1510M-AutoVAQ-gcc450-i686-fprofiled.7z)
libx264-r1510, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/rmgmoey1xmw/libx264-92-r1510M-AutoVAQ-gcc450-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6064 (http://forum.doom9.org/showpost.php?p=1389207&postcount=1480) or later now!

For some reason x264 didn't compile with latest GCC 4.5.0 (2010-04-01), so I stick with the 2010-03-27 release for the time being.

[LoRd_MuldeR]

Avidemux 2.5.2 r6083 (2010-04-06)
http://www.avidemux.org/

6083 - [win32] add mpeg2enc presets to installer
6082 - [vidEnc] clean up source code of various video encoder plugins
6081 - [prefs] remove mpeg split option as its now governed by mpeg2enc plugin
6080 - [mpeg2enc] remove old mpeg2enc and xvid rate control logic
6079 - [ffmpeg] check that all necessary muxers and protocols exist on startup
6078 - [ffmpeg] enable missing codecs and remove unnecessary options
6071 - [misc] minor clean ups
6070 - [avsproxy] backport avisynth proxy from 2.6 branch
6069 - [mpeg2enc] add some presets
6068 - [mpeg2enc] add option for sequence length limit to mpeg2enc plugin
6064 - [win32] update installer to include mpeg2enc plugin

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1523:

libx264-r1523, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/20zo5eob3mo/libx264-92-r1523M-gcc450-core2-fprofiled.7z)
libx264-r1523, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/fkeezz01nuk/libx264-92-r1523M-gcc450-amdfam10-fprofiled.fixed.7z)
libx264-r1523, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/mdzulaythzu/libx264-92-r1523M-gcc450-pentium3-fprofiled.7z)
libx264-r1523, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/5cnzgzdywjm/libx264-92-r1523M-gcc450-i686-fprofiled.7z)
libx264-r1523, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/ijndimzwmon/libx264-92-r1523M-gcc450-noasm-fprofiled.7z)
libx264-r1523, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/ugjz2djwynm/libx264-92-r1523M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1523 with AutoVAQ enabled:

libx264-r1523, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/ornna2klriu/libx264-92-r1523M-AutoVAQ-gcc450-core2-fprofiled.7z)
libx264-r1523, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/wdmwiygn0v5/libx264-92-r1523M-AutoVAQ-gcc450-amdfam10-fprofiled.fixed.7z)
libx264-r1523, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/y3jk01rweyd/libx264-92-r1523M-AutoVAQ-gcc450-pentium3-fprofiled.7z)
libx264-r1523, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/nn0tjd1zt1l/libx264-92-r1523M-AutoVAQ-gcc450-i686-fprofiled.7z)
libx264-r1523, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/izxwlz2ztwg/libx264-92-r1523M-AutoVAQ-gcc450-noasm-fprofiled.7z)


libx264 SVN-r1523 with NAL-HRD enabled:

libx264-r1523, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/yxjuyrzzoyi/libx264-92-r1523M-NAL_HRD-gcc450-core2-fprofiled.7z)
libx264-r1523, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/twnmc2uymgz/libx264-92-r1523M-NAL_HRD-gcc450-amdfam10-fprofiled.fixed.7z)
libx264-r1523, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/4imz2zy4wmm/libx264-92-r1523M-NAL_HRD-gcc450-pentium3-fprofiled.7z)
libx264-r1523, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/gjmtzyx2znl/libx264-92-r1523M-NAL_HRD-gcc450-i686-fprofiled.7z)
libx264-r1523, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/rmyn2mm3kcd/libx264-92-r1523M-NAL_HRD-gcc450-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6083 (http://forum.doom9.org/showpost.php?p=1389424&postcount=1483) or later now!

Update 2: The AMD K10 (amdfam10) optimized builds have been replaced with "fixed" versions.
They will now throw an error on unsupported None-SSE4a CPU's instead of producing broken output. (http://forum.doom9.org/showthread.php?p=1389891#post1389891)

[boyumeow]

I assume its not much different with zlib1 version 1.2.3 and 1.2.4, cause it is not updated yet in the Avidemux. Just thought I report it in case the Devs might have overlooked. Thanks.

[LoRd_MuldeR]

Avidemux 2.5.2 r6121 (2010-04-11)
http://www.avidemux.org/

Revision 6121 (11 Apr 2010)
# Updated ATK to version 1.30.0-1.
# Updated Cairo to version 1.8.10-3.
# Updated GLib to version 2.24.0-2.
# Updated GTK+ to version 2.20.0-1.
# Updated Libxml2 to version 2.7.7-1.
# Updated Pango to version 1.28.0-1.
# Updated x264 to r1523.
# Updated zlib to version 1.2.4-2.

6121 - [ffmpeg] update FFmpeg to r22831 & libswscale to r31028
6120 - [auto] remove remnants of internal auto wizards
6119 - [auto] remove internal auto wizards from GTK+ interface and populate with contents of script dir
6113 - [auto] set audio to copy if existing track is appropriate when using auto wizards
6112 - [auto] add optical disc auto wizards
6111 - [script] tweak system scripts so they're a bit more reusable
6110 - [x264/xvid] don't explicitly set the font family on Qt dialogs
6102 - [vidEnc] fix single pass of H.263 and MPEG-4 ASP avcodec encoder
6101 - [ffmpeg] compilation fix for osx
6100 - [ffmpeg] replace XPLATFORM cmake flag with CROSS_ARCH and CROSS_OS
6083 - [win32] add mpeg2enc presets to installer

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1538:

libx264-r1538, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/zty2ydemb2t/libx264-92-r1538M-gcc450-core2-fprofiled.7z)
libx264-r1538, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/moczlzn2kyy/libx264-92-r1538M-gcc450-amdfam10-fprofiled.7z)
libx264-r1538, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/jjk2jmguxny/libx264-92-r1538M-gcc450-pentium3-fprofiled.7z)
libx264-r1538, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/wmoitemtzxl/libx264-92-r1538M-gcc450-i686-fprofiled.7z)
libx264-r1538, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/mmg3ezhzomj/libx264-92-r1538M-gcc450-noasm-fprofiled.7z)
libx264-r1538, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/3wwyor20z3n/libx264-92-r1538M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1538 with AutoVAQ enabled:

libx264-r1538, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/mdyydm0xome/libx264-92-r1538M-AutoVAQ-gcc450-core2-fprofiled.7z)
libx264-r1538, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/oqnhth3tknj/libx264-92-r1538M-AutoVAQ-gcc450-amdfam10-fprofiled.7z)
libx264-r1538, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/mztodqywzf4/libx264-92-r1538M-AutoVAQ-gcc450-pentium3-fprofiled.7z)
libx264-r1538, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/tgqtynczhqw/libx264-92-r1538M-AutoVAQ-gcc450-i686-fprofiled.7z)
libx264-r1538, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/zzd24itjgyz/libx264-92-r1538M-AutoVAQ-gcc450-noasm-fprofiled.7z)


libx264 SVN-r1538 with NAL-HRD enabled:

libx264-r1538, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/iwhzozn2lry/libx264-92-r1538M-NAL_HRD-gcc450-core2-fprofiled.7z)
libx264-r1538, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/czryego2mht/libx264-92-r1538M-NAL_HRD-gcc450-amdfam10-fprofiled.7z)
libx264-r1538, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/ztoky5yjytj/libx264-92-r1538M-NAL_HRD-gcc450-pentium3-fprofiled.7z)
libx264-r1538, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/zgmzghdyfmh/libx264-92-r1538M-NAL_HRD-gcc450-i686-fprofiled.7z)
libx264-r1538, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/jy2zz24y0nt/libx264-92-r1538M-NAL_HRD-gcc450-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6121 (http://forum.doom9.org/showpost.php?p=1390665&postcount=1486) or later now!

All clear: With this release onwards, using the AMD K10 (amdfam10) builds should be safe again.

[LoRd_MuldeR]

libx264 SVN-r1542:

libx264-r1542, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/yzzztjjhhdm/libx264-92-r1542M-gcc450-core2-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/uigydjfyymx/libx264-92-r1542M-gcc450-amdfam10-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/bynzyoulwud/libx264-92-r1542M-gcc450-pentium3-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/ijjwmgotyyz/libx264-92-r1542M-gcc450-i686-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/yey10djinng/libx264-92-r1542M-gcc450-noasm-fprofiled.7z)
libx264-r1542, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/diyw4wfgn4o/libx264-92-r1542M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1542 with AutoVAQ enabled:

libx264-r1542, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/m3ryzkwywmz/libx264-92-r1542M-AutoVAQ-gcc450-core2-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/mmdm1tmtt1q/libx264-92-r1542M-AutoVAQ-gcc450-amdfam10-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/zyg4mtoz0vz/libx264-92-r1542M-AutoVAQ-gcc450-pentium3-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/tammjfyozmr/libx264-92-r1542M-AutoVAQ-gcc450-i686-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/fygm3mmrlmz/libx264-92-r1542M-AutoVAQ-gcc450-noasm-fprofiled.7z)


libx264 SVN-r1542 with NAL-HRD enabled:

libx264-r1542, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/k1wkytkjgzo/libx264-92-r1542M-NAL_HRD-gcc450-core2-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/ycxkl2ooxio/libx264-92-r1542M-NAL_HRD-gcc450-amdfam10-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/mzmnmiwo1nn/libx264-92-r1542M-NAL_HRD-gcc450-pentium3-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/v5jmnwcxnz0/libx264-92-r1542M-NAL_HRD-gcc450-i686-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/gvgkndiiymf/libx264-92-r1542M-NAL_HRD-gcc450-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6121 (http://forum.doom9.org/showpost.php?p=1390665&postcount=1486) or later now!

Build notes: GCC 4.5.x has been updated to GCC 4.5.0 (Stable).

[LoRd_MuldeR]

Avidemux 2.5.2 r6129 (2010-04-15)
http://www.avidemux.org/

Revision 6129 (15 Apr 2010)
# Updated x264 to r1542.

6129 - [Win32] update build scripts to build sdk
6128 - [plugin] cosmetic tidy ups
6127 - [Ass] update by erunamo
6126 - [win32] bundle less in zip and update nsis with new exe name
6125 - [Qt] rename main Qt executable on Win32 and Apple
6124 - [cmake] enhance configure summary
6123 - [jack] use bundled secret rabbit code for JACK audio device plugin
6122 - [avcodec] correctly flush encoder
6121 - [ffmpeg] update FFmpeg to r22831 & libswscale to r31028

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1542:

libx264-r1542, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/jtdzztzyzwz/libx264-93-r1542M-gcc450-core2-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/nimyoezen0n/libx264-93-r1542M-gcc450-amdfam10-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/xwqa3tnmidn/libx264-93-r1542M-gcc450-pentium3-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/zfmvtzoxjmd/libx264-93-r1542M-gcc450-i686-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/iynm3rujmwm/libx264-93-r1542M-gcc450-noasm-fprofiled.7z)
libx264-r1542, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/k2zndcj2ui0/libx264-93-r1542M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1542 with AutoVAQ enabled:

libx264-r1542, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/12fli4oo03u/libx264-93-r1542M-AutoVAQ-gcc450-core2-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/kdmdmfgwjze/libx264-93-r1542M-AutoVAQ-gcc450-amdfam10-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/mmj1yjde2ym/libx264-93-r1542M-AutoVAQ-gcc450-pentium3-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/jyul0qooyuh/libx264-93-r1542M-AutoVAQ-gcc450-i686-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/oyymjn0ot3j/libx264-93-r1542M-AutoVAQ-gcc450-noasm-fprofiled.7z)


libx264 SVN-r1542 with NAL-HRD enabled:

libx264-r1542, MinGW GCC 4.5.0, optimized for Core 2 (http://www.mediafire.com/file/0nm5hryygzz/libx264-93-r1542M-NAL_HRD-gcc450-core2-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, optimized for K10 (http://www.mediafire.com/file/ny2m4jmmgnm/libx264-93-r1542M-NAL_HRD-gcc450-amdfam10-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, optimized for Pentium III (http://www.mediafire.com/file/mfjtyjjhm0y/libx264-93-r1542M-NAL_HRD-gcc450-pentium3-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/zzfjvu2d4ln/libx264-93-r1542M-NAL_HRD-gcc450-i686-fprofiled.7z)
libx264-r1542, MinGW GCC 4.5.0, without ASM (slow!) (http://www.mediafire.com/file/imjdwymxzyg/libx264-93-r1542M-NAL_HRD-gcc450-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6129 (http://forum.doom9.org/showpost.php?p=1392061&postcount=1489) or later now!

Build notes: Re-compiled libx264 r1542 as core-93, so these builds will work with Avidemux r6129 now.

[LoRd_MuldeR]

libx264 SVN-r1564:

libx264-r1564, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/oegjid5zitm/libx264-93-r1564M-gcc460-core2-fprofiled.7z)
libx264-r1564, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/ditwzzzmmkn/libx264-93-r1564M-gcc460-amdfam10-fprofiled.7z)
libx264-r1564, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/hgmmjuiinhz/libx264-93-r1564M-gcc460-pentium3-fprofiled.7z)
libx264-r1564, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/3ohzfvj2yw5/libx264-93-r1564M-gcc460-i686-fprofiled.7z)
libx264-r1564, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/mjyjytqqnlj/libx264-93-r1564M-gcc460-noasm-fprofiled.7z)

libx264-r1564, MinGW GCC 4.4.3, legacy build (http://www.mediafire.com/file/2zgjyirnhtn/libx264-93-r1564M-gcc443-i686-fprofiled.7z)
libx264-r1564, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/g45oz5t2ud1/libx264-93-r1564M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1564 with AutoVAQ enabled:

libx264-r1564, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/zxyy5m5zmxt/libx264-93-r1564M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1564, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/aefjmtjni2m/libx264-93-r1564M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1564, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/iw3zryzjj5z/libx264-93-r1564M-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1564, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/zhw3zyuegej/libx264-93-r1564M-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1564, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/zyz3jnunkwy/libx264-93-r1564M-AutoVAQ-gcc460-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6129 (http://forum.doom9.org/showpost.php?p=1392061&postcount=1489) or later now!

[TheImperial2004]

libx264 SVN-r1564:

libx264-r1564, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/oegjid5zitm/libx264-93-r1564M-gcc460-core2-fprofiled.7z)
libx264-r1564, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/ditwzzzmmkn/libx264-93-r1564M-gcc460-amdfam10-fprofiled.7z)
libx264-r1564, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/hgmmjuiinhz/libx264-93-r1564M-gcc460-pentium3-fprofiled.7z)
libx264-r1564, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/3ohzfvj2yw5/libx264-93-r1564M-gcc460-i686-fprofiled.7z)
libx264-r1564, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/mjyjytqqnlj/libx264-93-r1564M-gcc460-noasm-fprofiled.7z)

libx264-r1564, MinGW GCC 4.4.3, legacy build (http://www.mediafire.com/file/2zgjyirnhtn/libx264-93-r1564M-gcc443-i686-fprofiled.7z)
libx264-r1564, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/g45oz5t2ud1/libx264-93-r1564M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1564 with AutoVAQ enabled:

libx264-r1564, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/zxyy5m5zmxt/libx264-93-r1564M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1564, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/aefjmtjni2m/libx264-93-r1564M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1564, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/iw3zryzjj5z/libx264-93-r1564M-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1564, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/zhw3zyuegej/libx264-93-r1564M-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1564, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/zyz3jnunkwy/libx264-93-r1564M-AutoVAQ-gcc460-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6129 (http://forum.doom9.org/showpost.php?p=1392061&postcount=1489) or later now!

Hi Mulder ! Long time no see :)

I see that x264 can produce Blu-ray comptitable stream . Nice !

Are all streams produced will be valid , or should we tweak some options in AviDemux ? And if we should , what are they ?

[LoRd_MuldeR]

Are all streams produced will be valid , or should we tweak some options in AviDemux ?

Nope, x264 needs to be configured specifically to meet the BluRay specs. Unfortunately not all required options are exposed in Avidemux yet.

In particular NAL-HRD is essential for BluRay, but is missing as an option in Avidemux. I posted builds that are patched to have NAL-HRD enabled by default earlier (but not this time).

For more details on how to configure x264 for BluRay, please see the official commit message:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c6de86497cdd7b7f3cce7d8a95d723c7d0c9f505

Also take care that BluRay only supports certain combination of "resolution @ frame-rate", for example 1080x1920 @ 24000/1001fps or 1280x720 @ 60000/1001fps.

(BTW: The link to "Libx264 Latest Builds" in your signature is outdated/broken ^^)

[TheImperial2004]

Thanks for the commit message link ;)

BTW , 60000 fps ?! did you mean 60 fps ?

(BTW: The link to "Libx264 Latest Builds" in your signature is outdated/broken ^^)

Yep ! Thats why I keep coming here for new builds !

[LoRd_MuldeR]

BTW , 60000 fps ?! did you mean 60 fps ?

I said "60000/1001fps" and that's what I meant. 60000/1001 = ~59,94.

[TheImperial2004]

I said "60000/1001fps" and that's what I meant. 60000/1001 = ~59,94.

Thanks for shading some light on that matter ;)

[Underground78]

Hello,

Does somebody know what the different is between mp4 and mp4 (psp) ?

Thanks in advance ! :)

[LoRd_MuldeR]

Hello,

Does somebody know what the different is between mp4 and mp4 (psp) ?

Thanks in advance ! :)

I can't tell you what exactly is the difference. Only that the latter is intended for PSP (PlayStation Portable).

Don't ask me why the PSP needs a special "flavor" of MP4 files :p

[Underground78]

Thanks for your answer ! :) I'm trying to help someone to encode movies for his PSP using x264 CLI but all my tries fail until now. I guess I should have a closer look to this "special mp4 format" which may explain everything ...

[LoRd_MuldeR]

Thanks for your answer ! :) I'm trying to help someone to encode movies for his PSP using x264 CLI but all my tries fail until now. I guess I should have a closer look to this "special mp4 format" which may explain everything ...

Remuxing the MP4 with MP4Box may help. I don't have a PSP, just read that people suggest MP4Box...

[Underground78]

Already tried, doesn't help ... :/ The strange thing is that nobody seems to have problem with PSP and x264 (when you know that you need --level 3 --ref 3 --b-pyramid none ...).

But I think we are getting off topic. :o

[LoRd_MuldeR]

What about VBV? It may also be required to set up the proper VBV maxrate/buffsize values. But don't ask me what the proper ones are for the PSP ;)

[Schrade]

Hello,

Does somebody know what the different is between mp4 and mp4 (psp) ?

Thanks in advance ! :)
I believe that the PSP option puts in the atoms for the "old" style mp4 files that you used to place in ms0:/MP_ROOT/100ANV01. (ms0: being the memory stick drive letter)

Basically, this is the old format that the PSP still supports but is no longer the preferred method. Around the time that Firmware 3.00 or so came around, Sony allowed you to put all the videos in the ms0:/VIDEO folder and you no longer needed the "special" atoms to get the videos to play. They can just be standard plain-jane mp4 container videos.

So I think the only things that the PSP option does is:

1) Adds the MSNV atom (which really is no longer needed...)
2) Doesn't put Avidemux as the title of the movie in the tags.

[LoRd_MuldeR]

libx264 SVN-r1570:

libx264-r1570, MinGW GCC 4.6.0, optimized for Core 2 (removed)
libx264-r1570, MinGW GCC 4.6.0, optimized for K10 (removed)
libx264-r1570, MinGW GCC 4.6.0, optimized for Pentium III (removed)
libx264-r1570, MinGW GCC 4.6.0, generic build (removed)
libx264-r1570, MinGW GCC 4.6.0, without ASM (slow!) (removed)

libx264-r1570, MinGW GCC 4.4.3, legacy build (removed)
libx264-r1570, MinGW GCC 3.4.5, legacy build (removed)


libx264 SVN-r1570 with AutoVAQ enabled:

libx264-r1570, MinGW GCC 4.6.0, optimized for Core 2 (removed)
libx264-r1570, MinGW GCC 4.6.0, optimized for K10 (removed)
libx264-r1570, MinGW GCC 4.6.0, optimized for Pentium III (removed)
libx264-r1570, MinGW GCC 4.6.0, generic build (removed)
libx264-r1570, MinGW GCC 4.6.0, without ASM (slow!) (removed)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6129 (http://forum.doom9.org/showpost.php?p=1392061&postcount=1489) or later now!

[lych_necross]

The above downloads are not working for me. The connection times out.

EDIT: Nevermind, its working now

[LoRd_MuldeR]

libx264 SVN-r1570:

libx264-r1570, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/zwnmeywmyq2/libx264-93-r1570M-gcc460-core2-fprofiled.7z)
libx264-r1570, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/j3yjzyfi1yd/libx264-93-r1570M-gcc460-amdfam10-fprofiled.7z)
libx264-r1570, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/550qnwdhocy/libx264-93-r1570M-gcc460-pentium3-fprofiled.7z)
libx264-r1570, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/zzmwq03mmyd/libx264-93-r1570M-gcc460-i686-fprofiled.7z)
libx264-r1570, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/hyjmknmig2t/libx264-93-r1570M-gcc460-noasm-fprofiled.7z)

libx264-r1570, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/nmliyyizzyj/libx264-93-r1570M-gcc451-core2-fprofiled.7z)
libx264-r1570, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/mngzq55tigm/libx264-93-r1570M-gcc451-amdfam10-fprofiled.7z)
libx264-r1570, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/5ztnwnz4mjo/libx264-93-r1570M-gcc451-pentium3-fprofiled.7z)
libx264-r1570, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/4yletj3qdve/libx264-93-r1570M-gcc451-i686-fprofiled.7z)
libx264-r1570, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/gvkynwmmmwz/libx264-93-r1570M-gcc451-noasm-fprofiled.7z)

libx264-r1570, MinGW GCC 4.4.4, optimized for Core 2 (http://www.mediafire.com/file/ughtzmz103o/libx264-93-r1570M-gcc444-core2-fprofiled.7z)
libx264-r1570, MinGW GCC 4.4.4, optimized for K10 (http://www.mediafire.com/file/wfg2t14yytd/libx264-93-r1570M-gcc444-amdfam10-fprofiled.7z)
libx264-r1570, MinGW GCC 4.4.4, optimized for Pentium III (http://www.mediafire.com/file/rjgmzwez1iy/libx264-93-r1570M-gcc444-pentium3-fprofiled.7z)
libx264-r1570, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/ekgdymzewyz/libx264-93-r1570M-gcc444-i686-fprofiled.7z)
libx264-r1570, MinGW GCC 4.4.4, without ASM (slow!) (http://www.mediafire.com/file/tkyyiddmjya/libx264-93-r1570M-gcc444-noasm-fprofiled.7z)

libx264-r1570, MinGW GCC 4.4.3, legacy build (http://www.mediafire.com/file/z2mx0wlgydy/libx264-93-r1570M-gcc443-i686-fprofiled.7z)
libx264-r1570, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/mm23yxmqukk/libx264-93-r1570M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1570 with AutoVAQ enabled:

libx264-r1570, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/oko3dzjlmzn/libx264-93-r1570M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1570, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/gzim5gjwejo/libx264-93-r1570M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1570, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/zmvryltznyz/libx264-93-r1570M-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1570, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/nymexykyedg/libx264-93-r1570M-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1570, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/wmzyzz2ttrm/libx264-93-r1570M-AutoVAQ-gcc460-noasm-fprofiled.7z)

libx264-r1570, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/omznieygidn/libx264-93-r1570M-AutoVAQ-gcc451-core2-fprofiled.7z)
libx264-r1570, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/m1zin4mukjy/libx264-93-r1570M-AutoVAQ-gcc451-amdfam10-fprofiled.7z)
libx264-r1570, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/nzgenmtdjj4/libx264-93-r1570M-AutoVAQ-gcc451-pentium3-fprofiled.7z)
libx264-r1570, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/nnjmywyl5mm/libx264-93-r1570M-AutoVAQ-gcc451-i686-fprofiled.7z)
libx264-r1570, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/mzy12nlzakn/libx264-93-r1570M-AutoVAQ-gcc451-noasm-fprofiled.7z)

libx264-r1570, MinGW GCC 4.4.4, optimized for Core 2 (http://www.mediafire.com/file/moc2gl3zvhz/libx264-93-r1570M-AutoVAQ-gcc444-core2-fprofiled.7z)
libx264-r1570, MinGW GCC 4.4.4, optimized for K10 (http://www.mediafire.com/file/zgxozjlyzjo/libx264-93-r1570M-AutoVAQ-gcc444-amdfam10-fprofiled.7z)
libx264-r1570, MinGW GCC 4.4.4, optimized for Pentium III (http://www.mediafire.com/file/4yt1uizj2lm/libx264-93-r1570M-AutoVAQ-gcc444-pentium3-fprofiled.7z)
libx264-r1570, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/bnvmkzndyme/libx264-93-r1570M-AutoVAQ-gcc444-i686-fprofiled.7z)
libx264-r1570, MinGW GCC 4.4.4, without ASM (slow!) (http://www.mediafire.com/file/momodnwdvdz/libx264-93-r1570M-AutoVAQ-gcc444-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6129 (http://forum.doom9.org/showpost.php?p=1392061&postcount=1489) or later now!

EDIT: Proper GCC 4.6.0 builds of libx264 r1570 uploaded now. I made a stupid mistake before. Sorry for that...

[LoRd_MuldeR]

libx264 SVN-r1583:

libx264-r1583, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/rxltgmr2zty/libx264-93-r1583M-gcc460-core2-fprofiled.7z)
libx264-r1583, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/2jyjjo5hg2m/libx264-93-r1583M-gcc460-amdfam10-fprofiled.7z)
libx264-r1583, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/zcem2tyjwig/libx264-93-r1583M-gcc460-pentium3-fprofiled.7z)
libx264-r1583, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/jztemjmd0hz/libx264-93-r1583M-gcc460-i686-fprofiled.7z)
libx264-r1583, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/tit5zc10ynz/libx264-93-r1583M-gcc460-noasm-fprofiled.7z)

libx264-r1583, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/zmmzktdj2ez/libx264-93-r1583M-gcc451-core2-fprofiled.7z)
libx264-r1583, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/jmowwjvuyjh/libx264-93-r1583M-gcc451-amdfam10-fprofiled.7z)
libx264-r1583, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/magjkjwyomr/libx264-93-r1583M-gcc451-pentium3-fprofiled.7z)
libx264-r1583, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/xyn2jzztohn/libx264-93-r1583M-gcc451-i686-fprofiled.7z)
libx264-r1583, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/mwwjkfjojnf/libx264-93-r1583M-gcc451-noasm-fprofiled.7z)

libx264-r1583, MinGW GCC 4.4.4, optimized for Core 2 (http://www.mediafire.com/file/mkmjynjyyzd/libx264-93-r1583M-gcc444-core2-fprofiled.7z)
libx264-r1583, MinGW GCC 4.4.4, optimized for K10 (http://www.mediafire.com/file/ydlydzgifjy/libx264-93-r1583M-gcc444-amdfam10-fprofiled.7z)
libx264-r1583, MinGW GCC 4.4.4, optimized for Pentium III (http://www.mediafire.com/file/yz5omdzknzy/libx264-93-r1583M-gcc444-pentium3-fprofiled.7z)
libx264-r1583, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/3nmzmz0rqmw/libx264-93-r1583M-gcc444-i686-fprofiled.7z)
libx264-r1583, MinGW GCC 4.4.4, without ASM (slow!) (http://www.mediafire.com/file/rcf1xzjyznf/libx264-93-r1583M-gcc444-noasm-fprofiled.7z)

libx264-r1583, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/zzumyd2mom2/libx264-93-r1583M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1583 with AutoVAQ enabled:

libx264-r1583, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/mmoymi4g2om/libx264-93-r1583M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1583, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/ztwmuyjykdn/libx264-93-r1583M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1583, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/jzzzdkzgumh/libx264-93-r1583M-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1583, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/zmrm2mrnm4t/libx264-93-r1583M-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1583, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/2mnimggrnzw/libx264-93-r1583M-AutoVAQ-gcc460-noasm-fprofiled.7z)

libx264-r1583, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/yzom0f0y4ka/libx264-93-r1583M-AutoVAQ-gcc451-core2-fprofiled.7z)
libx264-r1583, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/zxwmtvkrozw/libx264-93-r1583M-AutoVAQ-gcc451-amdfam10-fprofiled.7z)
libx264-r1583, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/muyjamwzlao/libx264-93-r1583M-AutoVAQ-gcc451-pentium3-fprofiled.7z)
libx264-r1583, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/yzm5ytdzjii/libx264-93-r1583M-AutoVAQ-gcc451-i686-fprofiled.7z)
libx264-r1583, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/rozme2xuyme/libx264-93-r1583M-AutoVAQ-gcc451-noasm-fprofiled.7z)

libx264-r1583, MinGW GCC 4.4.4, optimized for Core 2 (http://www.mediafire.com/file/jmtzm1nwnny/libx264-93-r1583M-AutoVAQ-gcc444-core2-fprofiled.7z)
libx264-r1583, MinGW GCC 4.4.4, optimized for K10 (http://www.mediafire.com/file/4ujgmyyzmnm/libx264-93-r1583M-AutoVAQ-gcc444-amdfam10-fprofiled.7z)
libx264-r1583, MinGW GCC 4.4.4, optimized for Pentium III (http://www.mediafire.com/file/mdw2en3omim/libx264-93-r1583M-AutoVAQ-gcc444-pentium3-fprofiled.7z)
libx264-r1583, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/tlthq5dh2jm/libx264-93-r1583M-AutoVAQ-gcc444-i686-fprofiled.7z)
libx264-r1583, MinGW GCC 4.4.4, without ASM (slow!) (http://www.mediafire.com/file/nntkidvogm3/libx264-93-r1583M-AutoVAQ-gcc444-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6129 (http://forum.doom9.org/showpost.php?p=1392061&postcount=1489) or later now!

[LoRd_MuldeR]

Avidemux 2.5.3 r6195 (2010-05-16)
http://www.avidemux.org/

Revision 6195 (16 May 2010)
# Updated Freetype to version 2.3.12-1.
# Updated GLib to version 2.24.1-1.
# Updated GTK+ to version 2.20.1-1.
# Updated x264 to r1583.

Revision 6161 [2.5.3 Final] (16 May 2010)
# Updated Avisynth Proxy GUI to version 2.12.

6189 - [ffmpeg] new CMake flag (FF_FLAGS) to pass flags to FFmpeg configure
6188 - [twolame] Patch by DaCat
6180 - [apple] fix logic of last commit
6179 - [apple] change prefix of FFmpeg libs on OS X so they don't conflict with system versions
6178 - [mpeg2enc] Fix double definition of mpeg_warn etc...
6177 - [mkv] Identified mpeg L1/L2 audio track in mkv, fixes #93
6169 - [build] We are now post 2.5.3
6168 - [uyvy] Fixes #94
6146 - [build] Merged/modified 2nd patch from Florent Rougon (not tested much)
6145 - [i18n/qt4] Handle correctly install path, modification of Florent Rougon patch
6144 - [i18n/qt] first part, handle win32 and unix differently
6143 - [i18n] Merge modified 18n/qm patch from Florent Rougon
6133 - [js/dialogFactory] Add toggle and integer to existing menu
6132 - [avcodec] fix reuse existing log file for mpeg-1 & mpeg-2 avcodec video encoder plugins
6131 - [js] check properly for missing audio streams
6130 - [Flv] Better decoding of metadata, fixes #92

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1583:

libx264-r1583, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/3manwyqgjvu/libx264-94-r1583M-gcc460-core2-fprofiled.7z)
libx264-r1583, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/tyktzmjxyw4/libx264-94-r1583M-gcc460-amdfam10-fprofiled.7z)
libx264-r1583, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/wroo2owjbz5/libx264-94-r1583M-gcc460-pentium3-fprofiled.7z)
libx264-r1583, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/qvuyjcdeyn3/libx264-94-r1583M-gcc460-i686-fprofiled.7z)
libx264-r1583, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/eozt2y4yozm/libx264-94-r1583M-gcc460-noasm-fprofiled.7z)

libx264-r1583, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/zzzjdzydq2d/libx264-94-r1583M-gcc451-core2-fprofiled.7z)
libx264-r1583, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/dtmmkjymmwy/libx264-94-r1583M-gcc451-amdfam10-fprofiled.7z)
libx264-r1583, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/nvyz5tmj5gm/libx264-94-r1583M-gcc451-pentium3-fprofiled.7z)
libx264-r1583, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/yem2hzzjwqy/libx264-94-r1583M-gcc451-i686-fprofiled.7z)
libx264-r1583, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/d2edimmzynz/libx264-94-r1583M-gcc451-noasm-fprofiled.7z)

libx264-r1583, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/zywztxdqmn0/libx264-94-r1583M-gcc444-i686-fprofiled.7z)
libx264-r1583, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/i4bikrzzvim/libx264-94-r1583M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1583 with AutoVAQ enabled:

libx264-r1583, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/qminnzzqmwi/libx264-94-r1583M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1583, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/q5ymyvd4mlm/libx264-94-r1583M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1583, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/jdytzdmuvan/libx264-94-r1583M-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1583, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/3d4zfczjglo/libx264-94-r1583M-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1583, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/my3yf32trmw/libx264-94-r1583M-AutoVAQ-gcc460-noasm-fprofiled.7z)

libx264-r1583, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/mjmmdql4uni/libx264-94-r1583M-AutoVAQ-gcc451-core2-fprofiled.7z)
libx264-r1583, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/2nj0ymudmtt/libx264-94-r1583M-AutoVAQ-gcc451-amdfam10-fprofiled.7z)
libx264-r1583, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/klzjody03zy/libx264-94-r1583M-AutoVAQ-gcc451-pentium3-fprofiled.7z)
libx264-r1583, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/m43tzzzynmj/libx264-94-r1583M-AutoVAQ-gcc451-i686-fprofiled.7z)
libx264-r1583, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/5tjrnvegjqf/libx264-94-r1583M-AutoVAQ-gcc451-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6195 (http://forum.doom9.org/showpost.php?p=1400390&postcount=1508) or later now!

Re-compiled libx264 r1583 as core-94, because Avidemux 2.5.3 now supports core-94 and thus doesn't need the "hack" anymore.

[TheImperial2004]

Re-compiled libx264 r1583 as core-94, because Avidemux 2.5.3 now supports core-94 and thus doesn't need the "hack" anymore.

Nope , it still uses core-93 ??!

[LoRd_MuldeR]

Nope , it still uses core-93 ??!

More precisely, Avidmeux 2.5.3 r6195 uses libx264 core-94, while the Avidemux 2.5.3 "Milestone" release (aka r6161) still used core-93 ;)

It may be a bit confusing, but the Avidemux developers increase the version number (e.g. "2.5.2" -> "2.5.3") for the Milestone releases and then continue development with that version number.

So after "Avidemux 2.5.2 r6129" came the "Avidemux 2.5.3" milestone release (r6161). And after that one came the "Avidemux 2.5.3 r6195" build...

[TheImperial2004]

More precisely, Avidmeux 2.5.3 r6195 uses libx264 core-94, while the Avidemux 2.5.3 "Milestone" release (aka r6161) still used core-93

It may be a bit confusing, but the Avidemux developers increase the version number (e.g. "2.5.2" -> "2.5.3") for the Milestone releases and then continue development with that version number.

So after "Avidemux 2.5.2 r6129" came the "Avidemux 2.5.3" milestone release (r6161). And after that one came the "Avidemux 2.5.3 r6195" build...

Dammit , I must change my glasses ASAP ;)

[LoRd_MuldeR]

libx264 SVN-r1592:

libx264-r1592, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/ywm0zunetyj/libx264-94-r1592M-gcc460-core2-fprofiled.7z)
libx264-r1592, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/uzmgmnn2ctm/libx264-94-r1592M-gcc460-amdfam10-fprofiled.7z)
libx264-r1592, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/wm2mamdk1gj/libx264-94-r1592M-gcc460-pentium3-fprofiled.7z)
libx264-r1592, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/0zm1mznnzmy/libx264-94-r1592M-gcc460-i686-fprofiled.7z)
libx264-r1592, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/om4dnztwzzy/libx264-94-r1592M-gcc460-noasm-fprofiled.7z)

libx264-r1592, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/kmotyzhzmjn/libx264-94-r1592M-gcc451-core2-fprofiled.7z)
libx264-r1592, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/m5hemjtyykz/libx264-94-r1592M-gcc451-amdfam10-fprofiled.7z)
libx264-r1592, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/n1nnnifm5tm/libx264-94-r1592M-gcc451-pentium3-fprofiled.7z)
libx264-r1592, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/45thycymgey/libx264-94-r1592M-gcc451-i686-fprofiled.7z)
libx264-r1592, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/2wdmvmzdy3w/libx264-94-r1592M-gcc451-noasm-fprofiled.7z)

libx264-r1592, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/zdzneeyymzf/libx264-94-r1592M-gcc444-i686-fprofiled.7z)
libx264-r1592, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/uygohokj0gr/libx264-94-r1592M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1592 with AutoVAQ enabled:

libx264-r1592, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/j13zzvfzzjo/libx264-94-r1592M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1592, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/e4bwhbrtzt3/libx264-94-r1592M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1592, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/mmnrjn3ya31/libx264-94-r1592M-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1592, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/g4z43cy3im1/libx264-94-r1592M-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1592, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/mzzzmmdzzly/libx264-94-r1592M-AutoVAQ-gcc460-noasm-fprofiled.7z)

libx264-r1592, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/r2ic520olo0/libx264-94-r1592M-AutoVAQ-gcc451-core2-fprofiled.7z)
libx264-r1592, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/3ontnyyyvim/libx264-94-r1592M-AutoVAQ-gcc451-amdfam10-fprofiled.7z)
libx264-r1592, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/ezjg1yygmrh/libx264-94-r1592M-AutoVAQ-gcc451-pentium3-fprofiled.7z)
libx264-r1592, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/nywjvmmzitz/libx264-94-r1592M-AutoVAQ-gcc451-i686-fprofiled.7z)
libx264-r1592, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/oyid5th13hn/libx264-94-r1592M-AutoVAQ-gcc451-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6195 (http://forum.doom9.org/showpost.php?p=1400390&postcount=1508) or later now!

[LoRd_MuldeR]

libx264 SVN-r1602:

libx264-r1602, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/udw5v3xyoy0/libx264-94-r1602M-gcc460-core2-fprofiled.7z)
libx264-r1602, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/ktmnkdkjmt2/libx264-94-r1602M-gcc460-amdfam10-fprofiled.7z)
libx264-r1602, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/yz2ynjfjnym/libx264-94-r1602M-gcc460-pentium3-fprofiled.7z)
libx264-r1602, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/1gmlmnrnzwm/libx264-94-r1602M-gcc460-i686-fprofiled.7z)
libx264-r1602, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/jidjt1jju2i/libx264-94-r1602M-gcc460-noasm-fprofiled.7z)

libx264-r1602, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/x1bgnzmzjnw/libx264-94-r1602M-gcc451-core2-fprofiled.7z)
libx264-r1602, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/5z2mwjubyjl/libx264-94-r1602M-gcc451-amdfam10-fprofiled.7z)
libx264-r1602, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/njwtmxnnxzf/libx264-94-r1602M-gcc451-pentium3-fprofiled.7z)
libx264-r1602, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/mn2cqmjno3k/libx264-94-r1602M-gcc451-i686-fprofiled.7z)
libx264-r1602, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/wy5zmdnmzli/libx264-94-r1602M-gcc451-noasm-fprofiled.7z)

libx264-r1602, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/lnh4i5m2dyu/libx264-94-r1602M-gcc444-i686-fprofiled.7z)
libx264-r1602, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/wngtxzmjo2o/libx264-94-r1602M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1602 with AutoVAQ enabled:

libx264-r1602, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/iyzxqn55yne/libx264-94-r1602M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1602, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/z55xnqdmn22/libx264-94-r1602M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1602, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/yzmfzmi41md/libx264-94-r1602M-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1602, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/ljgjvodgntm/libx264-94-r1602M-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1602, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/wyt4mzjwily/libx264-94-r1602M-AutoVAQ-gcc460-noasm-fprofiled.7z)

libx264-r1602, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/dyydnzzzknz/libx264-94-r1602M-AutoVAQ-gcc451-core2-fprofiled.7z)
libx264-r1602, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/d2jzztetwyk/libx264-94-r1602M-AutoVAQ-gcc451-amdfam10-fprofiled.7z)
libx264-r1602, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/njgzt1mnfmj/libx264-94-r1602M-AutoVAQ-gcc451-pentium3-fprofiled.7z)
libx264-r1602, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/mzy1mudykfh/libx264-94-r1602M-AutoVAQ-gcc451-i686-fprofiled.7z)
libx264-r1602, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/num0tyhntow/libx264-94-r1602M-AutoVAQ-gcc451-noasm-fprofiled.7z)


libx264 SVN-r1602 library pack:

libx264 SVN-r1602 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-94-r1602M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6195 (http://forum.doom9.org/showpost.php?p=1400390&postcount=1508) or later now!

[LoRd_MuldeR]

libx264 SVN-r1613:

libx264-r1613, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/w2q5twmy0mv/libx264-94-r1613M-gcc460-core2-fprofiled.7z)
libx264-r1613, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/zddqyum1yyk/libx264-94-r1613M-gcc460-amdfam10-fprofiled.7z)
libx264-r1613, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/xoohzltnvym/libx264-94-r1613M-gcc460-pentium3-fprofiled.7z)
libx264-r1613, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/jwmnzmjnjmm/libx264-94-r1613M-gcc460-i686-fprofiled.7z)
libx264-r1613, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/50ztzwmk0il/libx264-94-r1613M-gcc460-noasm-fprofiled.7z)

libx264-r1613, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/vdhry0jjgde/libx264-94-r1613M-gcc451-core2-fprofiled.7z)
libx264-r1613, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/mnfdzzmod5i/libx264-94-r1613M-gcc451-amdfam10-fprofiled.7z)
libx264-r1613, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/wm4ztmxndlz/libx264-94-r1613M-gcc451-pentium3-fprofiled.7z)
libx264-r1613, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/kkjtto42yrj/libx264-94-r1613M-gcc451-i686-fprofiled.7z)
libx264-r1613, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/uwzoing2rxn/libx264-94-r1613M-gcc451-noasm-fprofiled.7z)

libx264-r1613, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/dyhzmjy23yw/libx264-94-r1613M-gcc444-i686-fprofiled.7z)
libx264-r1613, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/dmjymttiy2j/libx264-94-r1613M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1613 with AutoVAQ enabled:

libx264-r1613, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/5lyzyhtnznj/libx264-94-r1613M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1613, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/znztilztloi/libx264-94-r1613M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1613, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/ycmhztyzhmy/libx264-94-r1613M-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1613, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/zzzzgvolomf/libx264-94-r1613M-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1613, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/d0nzjjvw50i/libx264-94-r1613M-AutoVAQ-gcc460-noasm-fprofiled.7z)

libx264-r1613, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/vkggzhgigmt/libx264-94-r1613M-AutoVAQ-gcc451-core2-fprofiled.7z)
libx264-r1613, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/dljlwz4bhmn/libx264-94-r1613M-AutoVAQ-gcc451-amdfam10-fprofiled.7z)
libx264-r1613, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/oqizwjzyjz3/libx264-94-r1613M-AutoVAQ-gcc451-pentium3-fprofiled.7z)
libx264-r1613, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/bqjm1zxwyfm/libx264-94-r1613M-AutoVAQ-gcc451-i686-fprofiled.7z)
libx264-r1613, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/yxedgeogq04/libx264-94-r1613M-AutoVAQ-gcc451-noasm-fprofiled.7z)


libx264 SVN-r1613 library pack:

libx264 SVN-r1613 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-94-r1613M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6195 (http://forum.doom9.org/showpost.php?p=1400390&postcount=1508) or later now!

[LoRd_MuldeR]

Avidemux 2.5.3 r6261 (2010-05-27)
http://www.avidemux.org/

Revision 6261 (27 May 2010)
# Updated x264 to r1613.

6261 - [win32] bundle i18n files in sdk
6229 - [misc] cosmetics
6228 - [i18n] update pot/ts files
6227 - [i18n] include plugins in generation of translation sources
6226 - [i18n] reinstate i18n support
6218 - [264 indexder] Prevent random value in fps , ar,....
6217 - [auto/js] Remove extra A
6216 - [js] Fix auto regarding audio copy, thanks Dmitry C. for pointing it
6213 - [x264] add support for slice-based threading
6212 - [x264] increase minimum supported core to version 85
6211 - [Win32] bump installer version
6197 - wine part of avsfilter and precompiled binary
6196 - Initial revision of avsfilter in plugins sources
6189 - [ffmpeg] new CMake flag (FF_FLAGS) to pass flags to FFmpeg configure

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1613:

libx264-r1613, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/mwjymf4mnd4/libx264-96-r1613M-gcc460-core2-fprofiled.7z)
libx264-r1613, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/kgzhdzmjoiy/libx264-96-r1613M-gcc460-amdfam10-fprofiled.7z)
libx264-r1613, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/dymwnchzwnj/libx264-96-r1613M-gcc460-pentium3-fprofiled.7z)
libx264-r1613, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/z42mjzmnqzw/libx264-96-r1613M-gcc460-i686-fprofiled.7z)
libx264-r1613, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/yiym4wnw4d5/libx264-96-r1613M-gcc460-noasm-fprofiled.7z)

libx264-r1613, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/uto5iyljoyy/libx264-96-r1613M-gcc451-core2-fprofiled.7z)
libx264-r1613, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/quanzwyzdxt/libx264-96-r1613M-gcc451-amdfam10-fprofiled.7z)
libx264-r1613, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/lgwmdgq4yl0/libx264-96-r1613M-gcc451-pentium3-fprofiled.7z)
libx264-r1613, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/5tn0itgmntm/libx264-96-r1613M-gcc451-i686-fprofiled.7z)
libx264-r1613, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/eyzd2l0ghjk/libx264-96-r1613M-gcc451-noasm-fprofiled.7z)

libx264-r1613, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/2ionlxikdj3/libx264-96-r1613M-gcc444-i686-fprofiled.7z)
libx264-r1613, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/mrzn3wynqny/libx264-96-r1613M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1613 with AutoVAQ enabled:

libx264-r1613, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/jzzy54ny2yz/libx264-96-r1613M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1613, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/qijw2ziifz4/libx264-96-r1613M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1613, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/iwfcjhjoc2y/libx264-96-r1613M-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1613, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/qnitzmt1tk2/libx264-96-r1613M-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1613, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/xuwqzummk4z/libx264-96-r1613M-AutoVAQ-gcc460-noasm-fprofiled.7z)

libx264-r1613, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/gyynmoe2q1m/libx264-96-r1613M-AutoVAQ-gcc451-core2-fprofiled.7z)
libx264-r1613, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/yeyoimmmygj/libx264-96-r1613M-AutoVAQ-gcc451-amdfam10-fprofiled.7z)
libx264-r1613, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/mgw2gdni1tm/libx264-96-r1613M-AutoVAQ-gcc451-pentium3-fprofiled.7z)
libx264-r1613, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/en3grgonzoc/libx264-96-r1613M-AutoVAQ-gcc451-i686-fprofiled.7z)
libx264-r1613, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/oye5n2mhtdy/libx264-96-r1613M-AutoVAQ-gcc451-noasm-fprofiled.7z)


libx264 SVN-r1613 library pack:

libx264 SVN-r1613 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-96-r1613M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6261 (http://forum.doom9.org/showpost.php?p=1403273&postcount=1516) or later now!

Re-compiled libx264 r1613 as core-96, because Avidemux r6261 now supports core-96 and thus doesn't need the "hack" anymore.

[dbmaxpayne]

Hi, I'm just starting to explore Avidemux. Great Tool btw.

But why is subme 10 and psy-trellis missing in the x264 configuration dialog?
Because I'm always using --preset placebo --tune film I would like to rebuild these settings in Avidemux.

Mark

[LoRd_MuldeR]

Hi, I'm just starting to explore Avidemux. Great Tool btw.

But why is subme 10 and psy-trellis missing in the x264 configuration dialog?
Because I'm always using --preset placebo --tune film I would like to rebuild these settings in Avidemux.

Mark

They are missing, because nobody has bothered adding them until now. Maybe if enough people complain, they will be added one day...

Anyway, if you use my builds of libx264 (see post above), you can use them anyway. I changed the default Psy-Trellis from 0.0 to 0.15, just like "--tune film" does.

Furthermore I implemented a workaround that will trigger "--subme 10", if you use "--trellis 2" + "--me umh/esa/tesa" + "--subme 9" ;)

(I recommend to look at the Avidemux log at "%APPDATA\avidemux\admlog.txt" to see which x264 settings are actually used - works with my builds only)

[dbmaxpayne]

@LoRd_MuldeR:
thx for the reply, I'm already using your builds :-) Will check the settings in the log now.

Another question: I just to opened a DV avi and tried to add a denoiser. Unfortunately denoise3d and hqdn3d don't seem to do anything.
When I converted the last DV avi I had to use the following AVS-Script to get convolution3D to work:

ConvertToYUY2()
Convolution3D (0, 32, 128, 16, 64, 10, 0)
ConvertToYV12()

Whats the problem here? Is something like this needed in Avidemux too?

Mark

[LoRd_MuldeR]

Another question: I just to opened a DV avi and tried to add a denoiser. Unfortunately denoise3d and hqdn3d don't seem to do anything.

How do you come to the conclusion that they "don't do anything" ???

Are you sure you looked at the filtered output? In the main window Avidemux shows the unprocessed input by default ;)

So you need to switch to the "output" view first in order to judge the result of a filter!

(Furthermore applying filters isn't possible in "Copy" or "Requant" mode. You must re-encode the video, if you intend to apply filters)

[dbmaxpayne]

How do you come to the conclusion that they "don't do anything" ???
Because I clicked the preview-button and there was nothing filtered :-)
Only "Median" seems to do anything.. strange

Like I said I had to convert the colorspace to get convolution3d to work in my AVS scripts.
Is there a way to convert to to different color spaces in Avidemux?

I just checked the admlog.txt and it seems that the encoder is completely ignoring the most of my settings. For example subme is simply set to 2 and me is set to dia, but I set it to tesa.
Why is this? Is this some kind of fast-firstpass thing? If so, can I deativate it?

Mark

[LoRd_MuldeR]

Because I clicked the preview-button and there was nothing filtered :-)
Only "Median" seems to do anything.. strange

Well, denoise filters work subtle. Maybe you didn't look hard enough. Median is an extremely strong smoothing/flattening filter.

HQDN3D definitely does "something" ;)

Like I said I had to convert the colorspace to get convolution3d to work in my AVS scripts.
Is there a way to convert to to different color spaces in Avidemux?

There are various "color" filters available from the Video Filter Manager. If none of them does what you need, you can still use Avisynth input...

I just checked the admlog.txt and it seems that the encoder is completely ignoring the most of my settings. For example subme is simply set to 2 and me is set to dia, but I set it to tesa.

If you looked at the settings used for the first pass of a Two-Pass encode, then what you saw is 100% as expected.

Why is this? Is this some kind of fast-firstpass thing? If so, can I deativate it?

Exactly. And you neither can nor want to "deactivate" it. The x264 CLI encoder does the same - for a good reason ;)

Remember: We throw away the output from the first pass anyway. All we re-use for the second pass (i.e. the final output) is the "stats" file created during the first pass.

Thus lowering settings for the first pass that don't effect the information in the "stats" file will NOT degrade the final result. But it saves a lot of time!

[dbmaxpayne]

Well, denoise filters work subtle. Maybe you didn't look hard enough. Median is an extremely strong smoothing/flattening filter.
Hmm I'm quite sure that there isn't done anything. Its an extremely noisy source so I should see if its processed or not.
However, I will try Avisynth input.




Exactly. And you neither can nor want to "deactivate" it. The x264 CLI encoder does the same - for a good reason ;)

Remember: We throw away the output from the first pass anyway. All we re-use for the second (final) pass is the "stats" file.

Lowering settings that don't effect the information in the "stats" file will NOT degrade the final result. But it saves a lot of time!

Ok, but if nothing is changed within the stats file when using fast-firstpass, why does x264-cli use --slow-firstpass in placebo mode? Wouldn't that be totally useless?

EDIT: I just encoded a short test clip and it actually MAKES a difference in stats/mbtree file when encoding with --slow-firstpass and without it.

[LoRd_MuldeR]

Ok, but if nothing is changed within the stats file when using fast-firstpass, why does x264-cli use --slow-firstpass in placebo mode? Wouldn't that be totally useless?

The "placebo" preset, as the name implies, does useless things. It uses insanely slow settings, even if the benefit is zero or near-zero.

You should understand the "placebo" preset as something that tells you which settings NOT to use for any real work ;)

EDIT: I just encoded a short test clip and it actually MAKES a difference in stats/mbtree file when encoding with --slow-firstpass and without it.

How does it make a difference? :confused:

Did you actually make two separate 2-Pass encodes (one made with "--slow-firstpass", one made without) from the same source and compare them visually ???

(Please don't tell me you diff'ed the stats file and concluded anything from that ^^)

[dbmaxpayne]

(Please don't tell me you diff'ed the stats file and concluded anything from that ^^)

Of course I did it like that :-D :-D Because you said it would not affect the "information in the stats file" I thought I could do it like that^^

Just did a second pass with --ssim

stats/mbtree/bitrate/ssim
standard: 96kb/1327kb/1517.26/0.9904520
--slow-firstpass: 126kb/1351kb/1509.02/0.9904939

So my conclusion: It actually DOES make a difference, even if it may be nigligible :-)
But since encoding time is not a problem for me, I will still use --preset placebo for encoding.
But you said there is no way for me to use --slow-firstpass in avidemux?

[LoRd_MuldeR]

Of course I did it like that :-D :-D Because you said it would not affect the "information in the stats file" I thought I could do it like that^^

If you compare the "raw" bits stored in the stats file, then there probably will be a difference. But just because two stats files aren't bit-identical, you can not make any conclusions about the actual effect on the final output from that! Most likely the difference is just random noise and won't have any (noteworthy) impact on the final result.

Just did a second pass with --ssim

stats/mbtree/bitrate/ssim
standard: 96kb/1327kb/1517.26/0.9904520
--slow-firstpass: 126kb/1351kb/1509.02/0.9904939

So my conclusion: It actually DOES make a difference, even if it may be nigligible :-)

The difference is negligible ;)

SSIM is far away from being a reliable quality indicator. It very roughly predicts the subjective quality, but you cannot rely on that! Also with Psy-optimizations enabled (and I assume you had them enabled), the SSIM values are even less useful. That's because Psy-optimizations hurt SSIM, although a human being can easily see that they improve the visual quality.

So sometimes a worse SSIM means better quality! With such an inaccurate quality metric (and no existing quality metric is accurate), a tiny difference of 0.00004 certainly does not imply a visual difference!

If the difference was like ~0.1 then I would take care. But your results are far away from that.

(Also note that the minor difference in file size is expected. x264 intentionally doesn't hit the target file size 100% accurate, because enforcing this would hurt quality)

But since encoding time is not a problem for me, I will still use --preset placebo for encoding.

Well, it's your decision to waste your time for zero benefit then. I cannot stop you from shooting yourself into the foot :p

But you said there is no way for me to use --slow-firstpass in avidemux?

Use an unpatched build of libx264. But then Psy-Trellis will be gone too, of course.

Or even better: Complain about this at the Avidemux forum, until the Avidemux developers finally add a proper "fast-firstpass" option, so I don't need to patch the builds any more.

(I have suggested this about a dozen times, but so far nobody seems to care...)

[dbmaxpayne]

Thanks for your explanations :-)

I've requested the feature here:
http://avidemux.org/admForum/viewtopic.php?pid=44104#p44104

btw: Just saw that you're from germany. Where are you from? :-)

[LoRd_MuldeR]

Avidemux 2.5.3 r6288 (2010-06-01)
http://www.avidemux.org/

6288 - [win32] add batch file to win32 sdk for building Qt translations
6287 - [win32] build script tweaks
6286 - [i18n] German translation update for Qt by Lance
6285 - [x264] support for fast first pass
6278 - [x264] add support for periodic intra refresh
6277 - [win32] add German translation for Qt to Win32 installer
6276 - [i18n] don't filter out duplicates from Qt UI strings since they have their own translation context
6275 - [i18n] update ts files using Qt 4.5.3 (Qt 4.6.x is currently broken)
6274 - [i18n] German translation update for Qt by Lance
6273 - [i18n] mark XSLT file as a CMake dependency so it triggers a recompile of TS files when it changes
6261 - [win32] bundle i18n files in sdk

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1627:

libx264-r1627, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/iygzeiant1y/libx264-96-r1627M-gcc460-core2-fprofiled.7z)
libx264-r1627, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/uyjkwytqgnq/libx264-96-r1627M-gcc460-amdfam10-fprofiled.7z)
libx264-r1627, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/0wjjjmtnyen/libx264-96-r1627M-gcc460-pentium3-fprofiled.7z)
libx264-r1627, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/mmmlzw2znyy/libx264-96-r1627M-gcc460-i686-fprofiled.7z)
libx264-r1627, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/0wqjmhmjyuu/libx264-96-r1627M-gcc460-noasm-fprofiled.7z)

libx264-r1627, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/hmwmudt2zyo/libx264-96-r1627M-gcc451-core2-fprofiled.7z)
libx264-r1627, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/mvedqnjn4ya/libx264-96-r1627M-gcc451-amdfam10-fprofiled.7z)
libx264-r1627, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/jcdgqnk4yjm/libx264-96-r1627M-gcc451-pentium3-fprofiled.7z)
libx264-r1627, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/geimiaekcfz/libx264-96-r1627M-gcc451-i686-fprofiled.7z)
libx264-r1627, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/wyyqlntdw2w/libx264-96-r1627M-gcc451-noasm-fprofiled.7z)

libx264-r1627, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/xmnyjgmznlr/libx264-96-r1627M-gcc444-i686-fprofiled.7z)
libx264-r1627, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/nz1mt2nmijw/libx264-96-r1627M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1627 with AutoVAQ enabled:

libx264-r1627, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/xzamlgighzg/libx264-96-r1627M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1627, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/mojkl2tzn5u/libx264-96-r1627M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1627, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/mzznqvc0jmm/libx264-96-r1627M-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1627, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/mdr23tzyzrn/libx264-96-r1627M-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1627, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/llqjqzgz1fw/libx264-96-r1627M-AutoVAQ-gcc460-noasm-fprofiled.7z)

libx264-r1627, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/q0tnhyjheym/libx264-96-r1627M-AutoVAQ-gcc451-core2-fprofiled.7z)
libx264-r1627, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/mj20zwytzwn/libx264-96-r1627M-AutoVAQ-gcc451-amdfam10-fprofiled.7z)
libx264-r1627, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/1mmkdznwkyw/libx264-96-r1627M-AutoVAQ-gcc451-pentium3-fprofiled.7z)
libx264-r1627, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/tnxiohttxzz/libx264-96-r1627M-AutoVAQ-gcc451-i686-fprofiled.7z)
libx264-r1627, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/trjzmt4ttzl/libx264-96-r1627M-AutoVAQ-gcc451-noasm-fprofiled.7z)


libx264 SVN-r1627 library pack:

libx264 SVN-r1627 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-96-r1627M-win32.7z)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6288 (http://forum.doom9.org/showpost.php?p=1404580&postcount=1529) or later now!

Note: No more "fast first-pass" patch needed, because Avidemux exposes this an option now, finally.

[LoRd_MuldeR]

libx264 SVN-r1629:

libx264-r1629, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/lnxxjrnzyyz/libx264-96-r1629M-gcc460-core2-fprofiled.7z)
libx264-r1629, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/hz3y2j2hqkn/libx264-96-r1629M-gcc460-amdfam10-fprofiled.7z)
libx264-r1629, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/dkcn0kyjn3o/libx264-96-r1629M-gcc460-pentium3-fprofiled.7z)
libx264-r1629, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/jjzlmajmoda/libx264-96-r1629M-gcc460-i686-fprofiled.7z)
libx264-r1629, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/2wyimztjny2/libx264-96-r1629M-gcc460-noasm-fprofiled.7z)

libx264-r1629, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/dtjqmzodjyv/libx264-96-r1629M-gcc451-core2-fprofiled.7z)
libx264-r1629, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/z05whizbnjz/libx264-96-r1629M-gcc451-amdfam10-fprofiled.7z)
libx264-r1629, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/2zotvmc3zcn/libx264-96-r1629M-gcc451-pentium3-fprofiled.7z)
libx264-r1629, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/0rjmuhftykg/libx264-96-r1629M-gcc451-i686-fprofiled.7z)
libx264-r1629, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/yytviiu1zyj/libx264-96-r1629M-gcc451-noasm-fprofiled.7z)

libx264-r1629, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/d1jltyq2j2w/libx264-96-r1629M-gcc444-i686-fprofiled.7z)
libx264-r1629, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/ommw4kmhdc1/libx264-96-r1629M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1629 with AutoVAQ enabled:

libx264-r1629, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/inommgm44eg/libx264-96-r1629M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1629, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/ttxt4mmlugj/libx264-96-r1629M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1629, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/z3zzomzcbtg/libx264-96-r1629M-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1629, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/0n1m0ylmmzm/libx264-96-r1629M-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1629, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/jdiy4zwzhzd/libx264-96-r1629M-AutoVAQ-gcc460-noasm-fprofiled.7z)

libx264-r1629, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/unmdgtt5mnx/libx264-96-r1629M-AutoVAQ-gcc451-core2-fprofiled.7z)
libx264-r1629, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/wmyzhw0zzmq/libx264-96-r1629M-AutoVAQ-gcc451-amdfam10-fprofiled.7z)
libx264-r1629, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/jdmoxyk2w24/libx264-96-r1629M-AutoVAQ-gcc451-pentium3-fprofiled.7z)
libx264-r1629, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/h5lz3znfimh/libx264-96-r1629M-AutoVAQ-gcc451-i686-fprofiled.7z)
libx264-r1629, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/21qddlamw0w/libx264-96-r1629M-AutoVAQ-gcc451-noasm-fprofiled.7z)


libx264 SVN-r1629 library pack:

libx264 SVN-r1629 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-96-r1629M-win32.7z)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6288 (http://forum.doom9.org/showpost.php?p=1404580&postcount=1529) or later now!

Note: libx264 r1629 fixes a regression introduced in r1627. Update is highly recommended!

[LoRd_MuldeR]

Avidemux 2.5.3 r6303 (2010-06-04)
http://www.avidemux.org/

6303 - [prefs] save Recent Projects properly
6302 - [Qt] Add check to avoid invalid access
6301 - [auto] Fix Pal/NTSC swap in auto DVD/SVCD/VCD, thanks to Andreas W
6300 - [i18n] German translation update for Qt by Lance
6299 - [i18n] enable translations for various Qt dialogs
6298 - [QT4] Add contextual menu to filters
6293 - [i18n] fix Qt dialogFactory controls for translation
6292 - [i18n] Italian translation update for GTK+ & Qt by zoppo
6291 - [i18n] traverse through all location tags to safely ignore translation contexts containing Qt UI strings
6288 - [win32] add batch file to win32 sdk for building Qt translations

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

Avidemux 2.5.3 r6340 (2010-06-07)
http://www.avidemux.org/

6340 - [win32] package additional header file in win32 sdk
6339 - [ffmpeg] update FFmpeg to r23514 & libswscale to r31344
6338 - [i18n] translate strings in auto wizards
6335 - [i18n] include auto scripts in translation file generation
6332 - [i18n] make translation context of Qt main filter dialog more appropriate
6331 - [js] make QT_TR_NOOP function available to javascript
6330 - [i18n] fix double quotes in blend remover plugin
6329 - [i18n] unix compilation fix
6325 - [i18n] exclude UI strings from duplicate checking and skip Qt aware source files from filtering
6324 - [i18n] disable Qt i18n functions for asharp and chroma shift plugins since they're UI neutral
6323 - [i18n] let Qt plugins take care of themselves for i18n
6322 - [i18n] let Qt dialogs take care of themselves for i18n
6321 - [i18n] make time function translatable
6320 - [flv] Read mixed array
6303 - [prefs] save Recent Projects properly

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1643:

libx264-r1643, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/wqdu1jvmkxy/libx264-96-r1643M-gcc460-core2-fprofiled.7z)
libx264-r1643, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/ojztmnjm1om/libx264-96-r1643M-gcc460-amdfam10-fprofiled.7z)
libx264-r1643, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/uld0mekimgw/libx264-96-r1643M-gcc460-pentium3-fprofiled.7z)
libx264-r1643, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/wilty4nyydy/libx264-96-r1643M-gcc460-i686-fprofiled.7z)
libx264-r1643, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/u20lmz2qnjm/libx264-96-r1643M-gcc460-noasm-fprofiled.7z)

libx264-r1643, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/mmhmy2j5mtj/libx264-96-r1643M-gcc451-i686-fprofiled.7z)
libx264-r1643, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/j2y50imkmtd/libx264-96-r1643M-gcc444-i686-fprofiled.7z)
libx264-r1643, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/mhz1dy3umky/libx264-96-r1643M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1643 with AutoVAQ enabled:

libx264-r1643, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/j4zywjmgzcq/libx264-96-r1643M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1643, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/hnzh1tmikhe/libx264-96-r1643M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1643, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/clxnmzjdzyn/libx264-96-r1643M-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1643, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/rzmrdmnjrjm/libx264-96-r1643M-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1643, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/jmdemm0kkek/libx264-96-r1643M-AutoVAQ-gcc460-noasm-fprofiled.7z)


libx264 SVN-r1643 library pack:

libx264 SVN-r1643 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-96-r1643M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6340 (http://forum.doom9.org/showpost.php?p=1406704&postcount=1533) or later now!

[LoRd_MuldeR]

Avidemux 2.5.3 r6370 (2010-06-13)
http://www.avidemux.org/

Revision 6370 (13 Jun 2010)
# Added libvpx, git version (commit: 5ef25a9728507d259c6ccd05064ce1208e7abd9f).
# Updated x264 to r1624.

6370 - [qt] increase minimum Qt version to 4.5
6369 - [Codec] quick n dirty vpx support (from 2.6)
6368 - [MKV] Recognize VP8 in mkv (from 2.6)
6366 - [JS] Avoid double fclose()
6365 - [Auto] Working PSP
6362 - [x264] Fix preset for ipod1
6356 - [qt] prompt to abort encoding if encoding window is closed (fixes #73)
6355 - [js] pass file handle instead of file name to Spidermonkey so Avidemux file funcs are used (fixes #86)
6354 - [dib] flip DIB video when required (fixes #67)
6353 - [auto] drop dead auto wizards
6352 - [win32] tweak build scripts
6351 - [i18n] make Custom labels independently translatable for Qt
6350 - [i18n] German translation update for Qt by Lance
6349 - [i18n] Italian translation update for GTK+ & Qt by zoppo
6348 - [i18n] use dummy strings to translate auto wizard menu - this should probably be automatically generated but it will do for now
6343 - [i18n] load avidemux translation before qt translation so avidemux translation takes precedence
6342 - [i18n] remove static translation of yes/no for properties window - happens too early
6340 - [win32] package additional header file in win32 sdk

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[Yobbo]

Hmm I'm quite sure that there isn't done anything. Its an extremely noisy source so I should see if its processed or not.
However, I will try Avisynth input.

It would be nice to have a way to toggle the preview for filters on/off, so we can see clearly the filter results.

I like Avidemux very much tho', it's quite a lovely thing!

[LoRd_MuldeR]

It would be nice to have a way to toggle the preview for filters on/off, so we can see clearly the filter results.

I like Avidemux very much tho', it's quite a lovely thing!

What prevents you from switching between the "Input" (unfiltered original) and the "Output" (filtered video) view at any time you like?

[LoRd_MuldeR]

libx264 SVN-r1643:

libx264-r1643, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/n3zmhz2maoy/libx264-97-r1643M-gcc460-core2-fprofiled.7z)
libx264-r1643, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/jytizh52nvn/libx264-97-r1643M-gcc460-amdfam10-fprofiled.7z)
libx264-r1643, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/uhjqldnfmbq/libx264-97-r1643M-gcc460-pentium3-fprofiled.7z)
libx264-r1643, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/otemcjizymy/libx264-97-r1643M-gcc460-i686-fprofiled.7z)
libx264-r1643, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/jvyzhmvkmzq/libx264-97-r1643M-gcc460-noasm-fprofiled.7z)

libx264-r1643, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/nzeeejjvezm/libx264-97-r1643M-gcc451-core2-fprofiled.7z)
libx264-r1643, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/jtokyymxznn/libx264-97-r1643M-gcc451-amdfam10-fprofiled.7z)
libx264-r1643, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/zzuzzeqmj4b/libx264-97-r1643M-gcc451-pentium3-fprofiled.7z)
libx264-r1643, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/2gzfqkktq1h/libx264-97-r1643M-gcc451-i686-fprofiled.7z)
libx264-r1643, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/af2t5ke4qdh/libx264-97-r1643M-gcc451-noasm-fprofiled.7z)

libx264-r1643, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/ydjrzmtymxj/libx264-97-r1643M-gcc450-i686-fprofiled.7z)
libx264-r1643, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/mjmymojkywe/libx264-97-r1643M-gcc444-i686-fprofiled.7z)
libx264-r1643, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/1ewoygwdyzz/libx264-97-r1643M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1643 with AutoVAQ enabled:

libx264-r1643, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/gjzmdyjnte5/libx264-97-r1643M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1643, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/nzyg23ngjug/libx264-97-r1643M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1643, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/hwjndxxmwnt/libx264-97-r1643M-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1643, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/mdmmzindgqm/libx264-97-r1643M-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1643, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/mjoyjyyzdj5/libx264-97-r1643M-AutoVAQ-gcc460-noasm-fprofiled.7z)

libx264-r1643, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/mwtyyiimngl/libx264-97-r1643M-AutoVAQ-gcc451-core2-fprofiled.7z)
libx264-r1643, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/fcbzttqnmil/libx264-97-r1643M-AutoVAQ-gcc451-amdfam10-fprofiled.7z)
libx264-r1643, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/zzcmmgmtdwg/libx264-97-r1643M-AutoVAQ-gcc451-pentium3-fprofiled.7z)
libx264-r1643, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/ndjvv3ztxzj/libx264-97-r1643M-AutoVAQ-gcc451-i686-fprofiled.7z)
libx264-r1643, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/yjidgyzohio/libx264-97-r1643M-AutoVAQ-gcc451-noasm-fprofiled.7z)


libx264 SVN-r1643 library pack:

libx264 SVN-r1643 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-97-r1643M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6370 (http://forum.doom9.org/showpost.php?p=1408254&postcount=1535) or later now!

Re-compiled libx264 as core-97 for compatibility with Avidemux r6370 and later. Also using "force_align_arg_pointer" again.

[Yobbo]

What prevents you from switching between the "Input" (unfiltered original) and the "Output" (filtered video) view at any time you like?

Well you have to exit the filters window. Would be cool to have a toggle actually in the filter's preview window.

[LoRd_MuldeR]

Well you have to exit the filters window. Would be cool to have a toggle actually in the filter's preview window.

That's why the "preview" windows of some (most?) filters are split into two halves. Left half shows original, right half shows filtered.

As an example for this, the "ASharp" filter comes to my mind...

[LoRd_MuldeR]

libx264 SVN-r1649:

libx264-r1649, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/jicdwhzmlyj/libx264-97-r1649M-gcc460-core2-fprofiled.7z)
libx264-r1649, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/tmngzoz2tow/libx264-97-r1649M-gcc460-amdfam10-fprofiled.7z)
libx264-r1649, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/yj5wbjhitwz/libx264-97-r1649M-gcc460-pentium3-fprofiled.7z)
libx264-r1649, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/eyg51wxjwij/libx264-97-r1649M-gcc460-noasm-fprofiled.7z)

libx264-r1649, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/zhxufwzwmz3/libx264-97-r1649M-gcc451-i686-fprofiled.7z)
libx264-r1649, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/czdrdrgzezz/libx264-97-r1649M-gcc450-i686-fprofiled.7z)
libx264-r1649, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/jmy2czfmxwg/libx264-97-r1649M-gcc444-i686-fprofiled.7z)
libx264-r1649, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/4iotjmqj4jm/libx264-97-r1649M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1649 with AutoVAQ enabled:

libx264-r1649, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/egmzgkkmoyu/libx264-97-r1649M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1649, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/g4myfydmxmd/libx264-97-r1649M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1649, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/i2wl13wymg4/libx264-97-r1649M-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1649, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/wikjznzokzm/libx264-97-r1649M-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1649, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/nxte2zmgmyz/libx264-97-r1649M-AutoVAQ-gcc460-noasm-fprofiled.7z)


libx264 SVN-r1649 library pack:

libx264 SVN-r1649 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-97-r1649M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6370 (http://forum.doom9.org/showpost.php?p=1408254&postcount=1535) or later now!

Note: libx264 r1649 fixes regressions introduced in r1501 and r1535. Update is highly recommended!

[LoRd_MuldeR]

libx264 SVN-r1659:

libx264-r1659, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/gmvjiydnjzt/libx264-97-r1659M-gcc460-core2-fprofiled.7z)
libx264-r1659, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/4qkzwh0tjnm/libx264-97-r1659M-gcc460-amdfam10-fprofiled.7z)
libx264-r1659, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/cmrmwnavjom/libx264-97-r1659M-gcc460-pentium3-fprofiled.7z)
libx264-r1659, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/dcnenzjoyzy/libx264-97-r1659M-gcc460-noasm-fprofiled.7z)

libx264-r1659, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/qwjmvx0liry/libx264-97-r1659M-gcc451-i686-fprofiled.7z)
libx264-r1659, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/nyymhnmzmjy/libx264-97-r1659M-gcc450-i686-fprofiled.7z)
libx264-r1659, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/yemzyjl22ew/libx264-97-r1659M-gcc444-i686-fprofiled.7z)

libx264-r1659, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/zdzyl4ymzdy/libx264-97-r1659M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1659 with AutoVAQ enabled:

libx264-r1659, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/z2mknihdmgm/libx264-97-r1659M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1659, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/xhjm5jffmm4/libx264-97-r1659M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1659, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/tot2ymmifjz/libx264-97-r1659M-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1659, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/wnoqng311nu/libx264-97-r1659M-AutoVAQ-gcc460-noasm-fprofiled.7z)


libx264 SVN-r1659 with OpenGOP enabled:

libx264-r1659, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/jyytnyyiidm/libx264-97-r1659M-OpenGOP-gcc460-core2-fprofiled.7z)
libx264-r1659, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/q5iktzzyrol/libx264-97-r1659M-OpenGOP-gcc460-amdfam10-fprofiled.7z)
libx264-r1659, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/jw4zdyzkn4l/libx264-97-r1659M-OpenGOP-gcc460-pentium3-fprofiled.7z)
libx264-r1659, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/ztehmiym45o/libx264-97-r1659M-OpenGOP-gcc460-noasm-fprofiled.7z)


libx264 SVN-r1659 library pack:

libx264 SVN-r1659 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-97-r1659M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6370 (http://forum.doom9.org/showpost.php?p=1408254&postcount=1535) or later now!

[Yobbo]

How does Avidemux deal with interlaced DV footage? If I want to apply some denoisers etc, do I bob first and then reinterlace after? Which bob? Reinterlace how? Thanks.

[LoRd_MuldeR]

How does Avidemux deal with interlaced DV footage? If I want to apply some denoisers etc, do I bob first and then reinterlace after? Which bob? Reinterlace how? Thanks.

This question isn't specific to Avidemux and there is no way to give an answer for the general case.

If the denoiser expects progressive footage, you'll have to deinterlace/bob first, then apply the denoiser and fianlly re-weave the denoised video.
The last step is optionally, of course. If you were to deinterlace anyway, you don't need to weave after denoising.

Anyway, if you use a denoiser that can handle interlaced video, you don't have to deinterlace/bob at all. Simply denoise the interlaced video.
For example FFT3DFilter(interlaced=true) can do this. It's available in Avidemux through Avisynth/AVSProxy...

[LoRd_MuldeR]

Avidemux 2.5.3 r6422 (2010-07-06)
http://www.avidemux.org/

Revision 6442 (06 Jul 2010)
# Compiled with GCC 4.4.5 pre-release (r161668).
# Updated libvpx to version 0.9.1.
# Updated x264 to r1666.

6442 - [ffmpeg] update FFmpeg to r24078 & libswscale to r31642
6441 - [win32] tweak build scripts for CMake 2.8
6440 - [qt] honour default video encoder on startup
6439 - [plugmgr] clear default when plugin is disabled
6434 - [auto] Put back PSP & ipod
6424 - [Ffmpeg] Allow low delay for vc1
6423 - [vc1] Add one extra byte to vc1 extradata
6422 - [VC1] Almost correct VC1 setup
6421 - [TS] VC1 Backport : Part 1 write index
6393 - Debug messages still is needed. Remove old ifdefs for correct restore configuration from prefs.
6392 - [qt] incomplete plugin manager for Qt
6372 - [vidEnc] plug memory leak when saving video encoder options
6371 - [i18n] update i18n files
6370 - [qt] increase minimum Qt version to 4.5

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[Yobbo]

This question isn't specific to Avidemux and there is no way to give an answer for the general case.

If the denoiser expects progressive footage, you'll have to deinterlace/bob first, then apply the denoiser and fianlly re-weave the denoised video.
The last step is optionally, of course. If you were to deinterlace anyway, you don't need to weave after denoising.

Anyway, if you use a denoiser that can handle interlaced video, you don't have to deinterlace/bob at all. Simply denoise the interlaced video.
For example FFT3DFilter(interlaced=true) can do this. It's available in Avidemux through Avisynth/AVSProxy...

I was referring to interlaced DV video that I want to keep interlaced and convert to mpeg2 DVD. If I want to use a built-in spatial-temporal denoiser (not external/avisynth/whatever), what built-in "bob/deinterlace" and built-in "weave" will do the job the best?

[LoRd_MuldeR]

I was referring to interlaced DV video that I want to keep interlaced and convert to mpeg2 DVD. If I want to use a built-in spatial-temporal denoiser (not external/avisynth/whatever), what built-in "bob/deinterlace" and built-in "weave" will do the job the best?

This cannot be answered, because best is what works best for you!

If I just wanted to denoise some interlaced source and keep it interlaced, I probably wouldn't deinterlace. I'd use something like:
Stack Fields -> Your preferred progressive-only denoiser here -> Unstack Fields

[LoRd_MuldeR]

libx264 SVN-r1666:

libx264-r1666, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/mzmq0a5yznn/libx264-102-r1666M-gcc460-core2-fprofiled.7z)
libx264-r1666, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/xr4jz4my22n/libx264-102-r1666M-gcc460-amdfam10-fprofiled.7z)
libx264-r1666, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/mtvme1gtmmt/libx264-102-r1666M-gcc460-pentium3-fprofiled.7z)
libx264-r1666, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/jzi2av2dt2o/libx264-102-r1666M-gcc460-noasm-fprofiled.7z)

libx264-r1666, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/lwymmjit1ik/libx264-102-r1666M-gcc451-i686-fprofiled.7z)
libx264-r1666, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/mmjzmmznjmk/libx264-102-r1666M-gcc450-i686-fprofiled.7z)
libx264-r1666, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/mbqtrncgcyw/libx264-102-r1666M-gcc444-i686-fprofiled.7z)

libx264-r1666, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/z5iu5jxm5t0/libx264-102-r1666M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1666 with AutoVAQ enabled:

libx264-r1666, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/54nzhioyomn/libx264-102-r1666M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1666, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/mmend1jdkdo/libx264-102-r1666M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1666, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/zzydzjoynzn/libx264-102-r1666M-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1666, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/ynzu3znnbh0/libx264-102-r1666M-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1666, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/m0bm2hybwom/libx264-102-r1666M-AutoVAQ-gcc460-noasm-fprofiled.7z)


libx264 SVN-r1666 with OpenGOP enabled:

libx264-r1666, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/znid0ewjo3w/libx264-102-r1666M-OpenGOP-gcc460-core2-fprofiled.7z)
libx264-r1666, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/mgjglimh25z/libx264-102-r1666M-OpenGOP-gcc460-amdfam10-fprofiled.7z)
libx264-r1666, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/fq0nwdcmind/libx264-102-r1666M-OpenGOP-gcc460-pentium3-fprofiled.7z)
libx264-r1666, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/10m1u5zydtt/libx264-102-r1666M-OpenGOP-gcc460-i686-fprofiled.7z)
libx264-r1666, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/mozwfgew42i/libx264-102-r1666M-OpenGOP-gcc460-noasm-fprofiled.7z)


libx264 SVN-r1666 library pack:

libx264 SVN-r1666 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-102-r1666M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6422 (http://forum.doom9.org/showpost.php?p=1415485&postcount=1545) or later now!

[LoRd_MuldeR]

libx264 SVN-r1671:

libx264-r1671, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/wznitfizn5lnjez/libx264-102-r1671M-gcc460-core2-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/ecynhr2mnmwttky/libx264-102-r1671M-gcc460-amdfam10-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/qdmd1nzzzzgjzth/libx264-102-r1671M-gcc460-pentium3-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/qhokhwqozhr5njq/libx264-102-r1671M-gcc460-noasm-fprofiled.7z)

libx264-r1671, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/nztjz5rgt0aztgw/libx264-102-r1671M-gcc451-i686-fprofiled.7z)
libx264-r1671, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/tyywymtdytrzjrt/libx264-102-r1671M-gcc450-i686-fprofiled.7z)
libx264-r1671, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/dvmnmdttm2mm4vb/libx264-102-r1671M-gcc444-i686-fprofiled.7z)

libx264-r1671, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/31wdile2ozylnzy/libx264-102-r1671M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1671 with AutoVAQ enabled:

libx264-r1671, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/iywdzdylilnh0w2/libx264-102-r1671M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/mjootjemhjqjwjz/libx264-102-r1671M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/mgztnxmonlidoyy/libx264-102-r1671M-AutoVAQ-gcc460-noasm-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/ijnyyowmzho233a/libx264-102-r1671M-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/mgztnxmonlidoyy/libx264-102-r1671M-AutoVAQ-gcc460-noasm-fprofiled.7z)


libx264 SVN-r1671 with OpenGOP enabled:

libx264-r1671, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/immdzzmwxfmci1w/libx264-102-r1671M-OpenGOP-gcc460-core2-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/mzzo4rmmqzjk5hj/libx264-102-r1671M-OpenGOP-gcc460-amdfam10-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/miinh4zygmmtyqn/libx264-102-r1671M-OpenGOP-gcc460-pentium3-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/3enwwmznvngtqkm/libx264-102-r1671M-OpenGOP-gcc460-i686-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/2tngntafyyjiemf/libx264-102-r1671M-OpenGOP-gcc460-noasm-fprofiled.7z)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6422 (http://forum.doom9.org/showpost.php?p=1415485&postcount=1545) or later now!

[LoRd_MuldeR]

libx264 SVN-r1671:

libx264-r1671, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/wfzpwm7yka1zhgz/libx264-102-r1671M-update1-gcc460-core2-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/5gxku9wr9118i94/libx264-102-r1671M-update1-gcc460-amdfam10-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/6r8243gq4t81gg8/libx264-102-r1671M-update1-gcc460-pentium3-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/awl5lb71rdly5m1/libx264-102-r1671M-update1-gcc460-noasm-fprofiled.7z)

libx264-r1671, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/l470qyc4aozaws2/libx264-102-r1671M-update1-gcc451-i686-fprofiled.7z)
libx264-r1671, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/5n378fuwwfs4e76/libx264-102-r1671M-update1-gcc450-i686-fprofiled.7z)
libx264-r1671, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/od3zqd7t5znui9o/libx264-102-r1671M-update1-gcc444-i686-fprofiled.7z)

libx264-r1671, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/7wzd3ivtbcwd1d2/libx264-102-r1671M-update1-gcc345-i686-fprofiled.7z)


libx264 SVN-r1671 with AutoVAQ enabled:

libx264-r1671, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/j39mtbl4jh339q9/libx264-102-r1671M-update1-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/65ezzxi1e9e42z8/libx264-102-r1671M-update1-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/6h6s2mbi613k2ak/libx264-102-r1671M-update1-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/fftw88nvdt7uitq/libx264-102-r1671M-update1-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/whm2coq0dgpv4jj/libx264-102-r1671M-update1-AutoVAQ-gcc460-noasm-fprofiled.7z)


libx264 SVN-r1671 with OpenGOP enabled:

libx264-r1671, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/t8yjcball79f40c/libx264-102-r1671M-update1-OpenGOP-gcc460-core2-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/tac0f16tbvdttr2/libx264-102-r1671M-update1-OpenGOP-gcc460-amdfam10-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/ugzwuo3t7zlcnyy/libx264-102-r1671M-update1-OpenGOP-gcc460-pentium3-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/sk63y1ndhgwi824/libx264-102-r1671M-update1-OpenGOP-gcc460-i686-fprofiled.7z)
libx264-r1671, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/3q0i0voacb6y7m5/libx264-102-r1671M-update1-OpenGOP-gcc460-noasm-fprofiled.7z)


libx264 SVN-r1671 library pack:

libx264 SVN-r1671 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-102-r1671M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6422 (http://forum.doom9.org/showpost.php?p=1415485&postcount=1545) or later now!

Re-compiled r1671 with regression fixes backported from r1675/r1676. Update recommended! (Currently no r1677 builds)

[LoRd_MuldeR]

libx264 SVN-r1680:

libx264-r1680, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/myc6l2iz7b0wof1/libx264-102-r1680M-gcc460-core2-fprofiled.7z)
libx264-r1680, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/lxlfx0yar0u9jme/libx264-102-r1680M-gcc460-amdfam10-fprofiled.7z)
libx264-r1680, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/f9xvwh888fzbc75/libx264-102-r1680M-gcc460-pentium3-fprofiled.7z)
libx264-r1680, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/dee62phqmzbfgqr/libx264-102-r1680M-gcc460-noasm-fprofiled.7z)

libx264-r1680, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/4rw5mmi2jh4lc8i/libx264-102-r1680M-gcc451-i686-fprofiled.7z)
libx264-r1680, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/iaamgr2559vjkes/libx264-102-r1680M-gcc450-i686-fprofiled.7z)
libx264-r1680, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/km0e71982w14a48/libx264-102-r1680M-gcc444-i686-fprofiled.7z)

libx264-r1680, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/4im6kdktet4lil1/libx264-102-r1680M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1680 with AutoVAQ enabled:

libx264-r1680, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/4kcazkornn02n4c/libx264-102-r1680M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1680, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/t5g6d7okhb31mmj/libx264-102-r1680M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1680, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/bzfntj683rk2jxa/libx264-102-r1680M-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1680, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/nhrrjw3yv1l61vd/libx264-102-r1680M-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1680, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/5viq5zvv3erraf5/libx264-102-r1680M-AutoVAQ-gcc460-noasm-fprofiled.7z)


libx264 SVN-r1680 with OpenGOP enabled:

libx264-r1680, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/k97q7k9mm3q4sdw/libx264-102-r1680M-OpenGOP-gcc460-core2-fprofiled.7z)
libx264-r1680, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/25lu4hy8p7ndrxd/libx264-102-r1680M-OpenGOP-gcc460-amdfam10-fprofiled.7z)
libx264-r1680, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/kbg87mgyyjdi36a/libx264-102-r1680M-OpenGOP-gcc460-pentium3-fprofiled.7z)
libx264-r1680, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/sgs2ub2e2p0tt34/libx264-102-r1680M-OpenGOP-gcc460-i686-fprofiled.7z)
libx264-r1680, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/r4g0ie02dcg452g/libx264-102-r1680M-OpenGOP-gcc460-noasm-fprofiled.7z)


libx264 SVN-r1680 library pack:

libx264 SVN-r1680 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-102-r1680M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6422 (http://forum.doom9.org/showpost.php?p=1415485&postcount=1545) or later now!

Be aware: This revision has a bug that will cause a crash in 2-Pass encoding! That was fixed in the latest version.

[LoRd_MuldeR]

libx264 SVN-r1681:

libx264-r1681, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/rtcybvz3twtuzcz/libx264-102-r1681M-gcc460-core2-fprofiled.7z)
libx264-r1681, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/f31u31f5czoncsd/libx264-102-r1681M-gcc460-amdfam10-fprofiled.7z)
libx264-r1681, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/honq86si83yo289/libx264-102-r1681M-gcc460-pentium3-fprofiled.7z)
libx264-r1681, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/r2jh6ctyf55jmzk/libx264-102-r1681M-gcc460-noasm-fprofiled.7z)

libx264-r1681, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/o0av07ri3t5j4l5/libx264-102-r1681M-gcc451-i686-fprofiled.7z)
libx264-r1681, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/5wh8iigb4r56el9/libx264-102-r1681M-gcc450-i686-fprofiled.7z)
libx264-r1681, MinGW GCC 4.4.4, generic build (http://www.mediafire.com/file/9badfaposl4s398/libx264-102-r1681M-gcc444-i686-fprofiled.7z)

libx264-r1681, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/cn6avp8wzkvxid4/libx264-102-r1681M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1681 with AutoVAQ enabled:

libx264-r1681, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/4tqszcgg3qjijhc/libx264-102-r1681M-AutoVAQ-gcc460-core2-fprofiled.7z)
libx264-r1681, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/sjh5f90ta51toil/libx264-102-r1681M-AutoVAQ-gcc460-amdfam10-fprofiled.7z)
libx264-r1681, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/sc0e3iwgd0cfrw3/libx264-102-r1681M-AutoVAQ-gcc460-pentium3-fprofiled.7z)
libx264-r1681, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/3b6s334qkbxby9c/libx264-102-r1681M-AutoVAQ-gcc460-i686-fprofiled.7z)
libx264-r1681, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/08uo7k6few3b7wa/libx264-102-r1681M-AutoVAQ-gcc460-noasm-fprofiled.7z)


libx264 SVN-r1681 with OpenGOP enabled:

libx264-r1681, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/jqd5z09o30f7kul/libx264-102-r1681M-OpenGOP-gcc460-core2-fprofiled.7z)
libx264-r1681, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/sdupabgk7kab920/libx264-102-r1681M-OpenGOP-gcc460-amdfam10-fprofiled.7z)
libx264-r1681, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/dk7iq98eulkkbe8/libx264-102-r1681M-OpenGOP-gcc460-pentium3-fprofiled.7z)
libx264-r1681, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/28sjh5v0tuye6mw/libx264-102-r1681M-OpenGOP-gcc460-i686-fprofiled.7z)
libx264-r1681, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/z2a9xx4wr2s9894/libx264-102-r1681M-OpenGOP-gcc460-noasm-fprofiled.7z)


libx264 SVN-r1681 library pack:

libx264 SVN-r1681 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-102-r1681M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6422 (http://forum.doom9.org/showpost.php?p=1415485&postcount=1545) or later now!

This revision fixes a bug that caused a crash in 2-Pass encoding (at the beginning of second pass). Update is highly recommended!

[brencreetle]

Im on snapshot but I dont think that it is the problem...
Ive installed avidemux and it simply doesnt start, I tried to launch it in terminal but it says that the command avidemux doesnt exist
Who can help me?
Thanks

[LoRd_MuldeR]

Im on snapshot but I dont think that it is the problem...
Ive installed avidemux and it simply doesnt start, I tried to launch it in terminal but it says that the command avidemux doesnt exist
Who can help me?
Thanks

How are we supposed to help you with that information? :rolleyes:

First of all: What operating system are you on? Are you on Windows, on Linux, on MacOS or what?

And what steps exactly did you perform to "install" Avidemux on your system ???

[LoRd_MuldeR]

libx264 SVN-r1688:

libx264-r1688, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/vbv0vwqbqob81rv/libx264-102-r1688M-gcc451-core2-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/iptkut8w95s5ciy/libx264-102-r1688M-gcc451-amdfam10-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/8i13q4lnib44nzl/libx264-102-r1688M-gcc451-pentium3-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/hgp357v0945hn4w/libx264-102-r1688M-gcc451-i686-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/mbhnnm86bympm9c/libx264-102-r1688M-gcc451-noasm-fprofiled.7z)

libx264-r1688, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/j0zj3lbjvm8iwpi/libx264-102-r1688M-gcc450-i686-fprofiled.7z)
libx264-r1688, MinGW GCC 4.4.5, generic build (http://www.mediafire.com/file/wirnnrnlnxn9lbw/libx264-102-r1688M-gcc445-i686-fprofiled.7z)
libx264-r1688, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/q76o8t2rn1qhjqk/libx264-102-r1688M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1688 with AutoVAQ enabled:

libx264-r1688, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/c2vbp862adx9zy7/libx264-102-r1688M-AutoVAQ-gcc451-core2-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/ep4m8rqx0a7t5xp/libx264-102-r1688M-AutoVAQ-gcc451-amdfam10-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/gxw5gkyp57fv79k/libx264-102-r1688M-AutoVAQ-gcc451-pentium3-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/e5zvp0tg7coi5hm/libx264-102-r1688M-AutoVAQ-gcc451-i686-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/1ln1t5oszlel1xz/libx264-102-r1688M-AutoVAQ-gcc451-noasm-fprofiled.7z)


libx264 SVN-r1688 with OpenGOP enabled:

libx264-r1688, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/cobmrglgpmr7o4d/libx264-102-r1688M-OpenGOP-gcc451-core2-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/yrrekucy931r9xp/libx264-102-r1688M-OpenGOP-gcc451-amdfam10-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/hbe661a71rgvay1/libx264-102-r1688M-OpenGOP-gcc451-pentium3-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/0yu0ekc3gmhvacp/libx264-102-r1688M-OpenGOP-gcc451-i686-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/8wir7a5cesn6ez8/libx264-102-r1688M-OpenGOP-gcc451-noasm-fprofiled.7z)


libx264 SVN-r1688 library pack:

libx264 SVN-r1688 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-102-r1688M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6422 (http://forum.doom9.org/showpost.php?p=1415485&postcount=1545) or later now!

[LoRd_MuldeR]

Avidemux 2.5.3 r6502 (2010-08-03)
http://www.avidemux.org/

Revision 6502 (03 Aug 2010)
# Updated x264 to r1688.

6502 - [ffmpeg] link and install avcore
6500 - [vidEnc] missed file
6499 - [ffmpeg] update FFmpeg to r24666 & libswscale to r31906
6498 - [vidEnc] move menu entries from compression params
6497 - [Pulse] automagic deps removal for pulse simple, patch by floppymaster
6496 - [cli] Lord mulder flush patch
6467 - [Asf] Read extradata refs #100
6449 - [DV] Add DV compatible fourcc, ref #99
6442 - [ffmpeg] update FFmpeg to r24078 & libswscale to r31642

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1688:

libx264-r1688, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/y18t8pe5huhgc45/libx264-104-r1688M-gcc451-core2-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/owth0gsjjj0yrii/libx264-104-r1688M-gcc451-amdfam10-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/4qut5ddm38cl5jr/libx264-104-r1688M-gcc451-pentium3-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/1ok4ig454r72a9a/libx264-104-r1688M-gcc451-i686-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/suzuei4h4lo113q/libx264-104-r1688M-gcc451-noasm-fprofiled.7z)

libx264-r1688, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/w3dn6xovemvou1x/libx264-104-r1688M-gcc450-i686-fprofiled.7z)
libx264-r1688, MinGW GCC 4.4.5, generic build (http://www.mediafire.com/file/os4aa4rtlfr9d59/libx264-104-r1688M-gcc445-i686-fprofiled.7z)
libx264-r1688, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/mh33w1xxzyvx23g/libx264-104-r1688M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1688 with AutoVAQ enabled:

libx264-r1688, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/k85zp77t2zp33rs/libx264-104-r1688M-AutoVAQ-gcc451-core2-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/0ch730503x9ip4g/libx264-104-r1688M-AutoVAQ-gcc451-amdfam10-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/p1g51hqw86lrqwz/libx264-104-r1688M-AutoVAQ-gcc451-pentium3-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/becx8t6sifc86i0/libx264-104-r1688M-AutoVAQ-gcc451-i686-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/s5n0xfawlufyvra/libx264-104-r1688M-AutoVAQ-gcc451-noasm-fprofiled.7z)


libx264 SVN-r1688 with OpenGOP enabled:

libx264-r1688, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/aox1fqqog9en47d/libx264-104-r1688M-OpenGOP-gcc451-core2-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/atxn97n9gi5jywq/libx264-104-r1688M-OpenGOP-gcc451-amdfam10-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/89vy242ov201mbz/libx264-104-r1688M-OpenGOP-gcc451-pentium3-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/2e4hjao280dk0dx/libx264-104-r1688M-OpenGOP-gcc451-i686-fprofiled.7z)
libx264-r1688, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/phsc7x282mmq245/libx264-104-r1688M-OpenGOP-gcc451-noasm-fprofiled.7z)


libx264 SVN-r1688 library pack:

libx264 SVN-r1688 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-104-r1688M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6502 (http://forum.doom9.org/showpost.php?p=1423078&postcount=1556) or later now!

Re-compiled libx264-r1688 as core-104, because Avidemux r6502 supports x264 core-104 now. Update is recommended!

[LoRd_MuldeR]

libx264 SVN-r1698:

libx264-r1698, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/fj21mxtw202803x/libx264-104-r1698M-gcc451-core2-fprofiled.7z)
libx264-r1698, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/cseuwqpjvqpybfu/libx264-104-r1698M-gcc451-amdfam10-fprofiled.7z)
libx264-r1698, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/oa4d5xov1mjrck2/libx264-104-r1698M-gcc451-pentium3-fprofiled.7z)
libx264-r1698, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/wrdbvwkov7b6nqs/libx264-104-r1698M-gcc451-i686-fprofiled.7z)
libx264-r1698, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/lkbs1e2l7geeo6b/libx264-104-r1698M-gcc451-noasm-fprofiled.7z)

libx264-r1698, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/2qt2y2242w8s631/libx264-104-r1698M-gcc460-i686-fprofiled.7z)
libx264-r1698, MinGW GCC 4.5.2, generic build (http://www.mediafire.com/file/cvvbzvcwowh1lxr/libx264-104-r1698M-gcc452-i686-fprofiled.7z)
libx264-r1698, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/zeq9jxjuunio8t6/libx264-104-r1698M-gcc450-i686-fprofiled.7z)
libx264-r1698, MinGW GCC 4.4.5, generic build (http://www.mediafire.com/file/0s5zmv434n7gjwa/libx264-104-r1698M-gcc445-i686-fprofiled.7z)

libx264-r1698, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/0azh8m2xdwgadqm/libx264-104-r1698M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1698 with AutoVAQ enabled:

libx264-r1698, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/bqkc84d57k2f7aq/libx264-104-r1698M-AutoVAQ-gcc451-core2-fprofiled.7z)
libx264-r1698, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/brmdc5mcrkbxla7/libx264-104-r1698M-AutoVAQ-gcc451-amdfam10-fprofiled.7z)
libx264-r1698, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/c7a5y8x1xavb8q8/libx264-104-r1698M-AutoVAQ-gcc451-pentium3-fprofiled.7z)
libx264-r1698, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/337zfbzdf6kb86r/libx264-104-r1698M-AutoVAQ-gcc451-i686-fprofiled.7z)
libx264-r1698, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/bkqc3q6i1quco46/libx264-104-r1698M-AutoVAQ-gcc451-noasm-fprofiled.7z)


libx264 SVN-r1698 with OpenGOP enabled:

libx264-r1698, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/1pcdb0wdm82nrgt/libx264-104-r1698M-OpenGOP-gcc451-core2-fprofiled.7z)
libx264-r1698, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/i6uqsrlpidxlb4x/libx264-104-r1698M-OpenGOP-gcc451-amdfam10-fprofiled.7z)
libx264-r1698, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/ac0a3xpc0vw9fs4/libx264-104-r1698M-OpenGOP-gcc451-pentium3-fprofiled.7z)
libx264-r1698, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/e35mm7azqxdm4qa/libx264-104-r1698M-OpenGOP-gcc451-i686-fprofiled.7z)
libx264-r1698, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/v4mkfpe056fzv5c/libx264-104-r1698M-OpenGOP-gcc451-noasm-fprofiled.7z)


libx264 SVN-r1698 library pack:

libx264 SVN-r1698 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-104-r1698M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6502 (http://forum.doom9.org/showpost.php?p=1423078&postcount=1556) or later now!

[TheImperial2004]

Hi Lord_Mulder , glad to see you still living :)

Anyway ... I recoreded some videos off my screen (1920x1200p) at 60FPS -gaming for the most part- and I wanted to re-encode them for web .
Of course I wanted to resize them to 1280x800 to keep the AR as 16:10 and I used the Lanczos filter as I read it generates the best quality . But the result was not too great . I always believed that Upscaling can hurt quality not Downscaling !

So what do you suggest ?

[LoRd_MuldeR]

Hi Lord_Mulder , glad to see you still living :)

Anyway ... I recoreded some videos off my screen (1920x1200p) at 60FPS -gaming for the most part- and I wanted to re-encode them for web .
Of course I wanted to resize them to 1280x800 to keep the AR as 16:10 and I used the Lanczos filter as I read it generates the best quality . But the result was not too great . I always believed that Upscaling can hurt quality not Downscaling !

So what do you suggest ?

What do you mean with "the result was not too great" ???

Your description is much too vague to give any useful advise! Also make clear please: Is the "problem" immediately after the resize or after you encoded the resized video?

Furthermore Lanczos isn't the "best" resizer, as there is no "best" of anything per forum rule #12 ;)

Maybe one can say the Lanczos resizer produces more "sharp" result than other resizers like BiLinear or BiCubic, but that's not always a "good" thing.

And of course "downscaling" can hurt quality, as you are throwing away information! Still it may make sense to downscale when you are going to compress at very low bitrate.

"Upscaling" generally doesn't hurt quality, but also cannot magically add detail that doesn't exist in the source, e.g. you cannot make a SD source have "HD quality".

[TheImperial2004]

What do you mean with "the result was not too great" ???

Your description is much too vague to give any useful advise! Also make clear please: Is the "problem" immediately after the resize or after you encoded the resized video?

Furthermore Lanczos isn't the "best" resizer, as there is no "best" of anything per forum rule #12

Maybe one can say the Lanczos resizer produces more "sharp" result than other resizers like BiLinear or BiCubic, but that's not always a "good" thing.

And of course "downscaling" can hurt quality, as you are throwing away information! Still it may make sense to downscale when you are going to compress at very low bitrate.

"Upscaling" generally doesn't hurt quality, but also cannot magically add detail that doesn't exist in the source, e.g. you cannot make a SD source have "HD quality".

AviDemux only has 3 resizing filters , I did research and found that Lanzcos is the best for quality (betweent those 3) . Of course my question was "after" I encoded a video using AVC insane-quality-preset I made + Resizing filter only, the quality isn't "that" sharp and it's blurry .
I saw some videos on Youtube and the site resized them to 480p , yet they are crystal clear :/

[LoRd_MuldeR]

AviDemux only has 3 resizing filters , I did research and found that Lanzcos is the best for quality (betweent those 3).

You didn't get the point. Lanczos is the "best" method (among those available in Avidemux) only if you are looking for a "sharp" resizer.

If you are looking for a "smooth" resize, then probably "BiLinear" is the "best" one ;)

Using a "sharp" resizer probably isn't a good idea, if you are encoding at extremely low bitrates. That's actually what applies to Youtube...


Of course my question was "after" I encoded a video using AVC insane-quality-preset I made + Resizing filter only, the quality isn't "that" sharp and it's blurry.

Of course? It wasn't clear from you post at all. And it also means that your "problem" isn't necessarily caused by the resize filter (alone).

I don't know what your "AVC insane-quality-preset" is, but if you are encoding AVC/H.264 in Avidemux, I would recommend to lower the deblocking setting to -1:-1 or even -2:-2.

Note however that this is a "sharpness -vs- blockyness" trade-off: With negative deblocking values you'll get improved sharpness at the cost of stronger blocking...

Of course "Psy RDO" and "AQ" should be kept enabled. And some "Psy-Trellis" (available in Avidemux only trough my patched libx264 builds) might help to preserve details as well.

Last but not least, the more bitrate you spend the better the result you'll get. I'd recommend something like CRF=18 for high quality encodes.


But no matter what, Youtube will re-encode your video anyway - at extremely low bitrate. You can only upload a HQ source and hope they won't screw it up too bad :rolleyes:

So are we talking about your own encode, created with Avidemux, the one you uploaded to Youtube --or-- are we talking about the "final" video that appears on Youtube ???


I saw some videos on Youtube and the site resized them to 480p , yet they are crystal clear :/

I think Youtube uses a different encoder for 480p than it does for 720p and 1080p. AFAIK they encode 480p (and below) with VP6, for 720p (and above) they use H.264.

[TheImperial2004]

You didn't get the point. Lanczos is the "best" method (among those available in Avidemux) only if you are looking for a "sharp" resizer.
Yes I want those encodes to be as sharp as possible (transparent to the sources which is fairly sharp) :)
I don't know what your "AVC insane-quality-preset" is, but if you are encoding AVC/H.264 in Avidemux, I would recommend to lower the deblocking setting to -1:-1 or even -2:-2.

My preset is CRF 18 , UMH , Subme =9 , Search range = 24 , All Macroblocks checked , inloop = -1 -1 . This same preset I always use to encode my HD files at high quality . This problem is produced when I downscale my RAW source only .

But no matter what, Youtube will re-encode your video anyway - at extremely low bitrate. You can only upload a HQ source and hope they won't screw it up too bad

No , I wasn't planning to upload my videos to youtube . I'll upload them to my server and embedd a player like JW Player to play them . But I was refering to their resizer as a good one ;)

So are we talking about your own encode, created with Avidemux

Yes , exactly .

AFAIK they encode 480p (and below) with VP6

Is it a good encoder for 720p too ? How about VP8 I keep reading about lately ?

I'll do my research , but I always like to hear your experiments :)

[Dark Shikari]

I think Youtube uses a different encoder for 480p than it does for 720p and 1080p. AFAIK they encode 480p (and below) with VP6, for 720p (and above) they use H.264.They use x264 for 480p ones too.

Do note that there's a lot of weirdness in profiles though -- encoding with B-frames for no apparent reason (but with CABAC), etc, etc.

[TheImperial2004]

It seems Inloop = -4 -4 + Lanzcos did the trick !

Now my encode is as sharp as a knive :)

Psst : I used MSharpen filter too ;)

They use x264 for 480p ones too.

x264 is a pure winner on all resolutions (at least for a home user like me) :)

[LoRd_MuldeR]

Yes I want those encodes to be as sharp as possible (transparent to the sources which is fairly sharp) :)

Still, while "sharp" might look good right after the resize, it might look not so nice after the re-encode.

That's because "sharp" video is harder to compress than "smooth" video, which means that "sharp" video might actually look worse after the encode.

Of course that's only a problem at low bitrates...


My preset is CRF 18 , UMH , Subme =9 , Search range = 24 , All Macroblocks checked , inloop = -1 -1 . This same preset I always use to encode my HD files at high quality . This problem is produced when I downscale my RAW source only .

Your x264 settings sound reasonable to me. Maybe CRF=16, if CRF=18 really isn't good enough, but I doubt that's the problem.

I really think you should compare three things and see at which step the "problem" occurs:

(1) Original video
(2) Resized video - lossless commpression (e.g. HuffYUV)
(3) Resized video - H.264 (x264)


If video (2) looks "bad" already, you might consider applying a (moderate) sharping filter after resize.

Also there are other resizers available in Avisyth, such as Lanczos4Resize(), Spline36Resize() or even SincResize().

See also:
http://avisynth.org/mediawiki/Resize

Is it a good encoder for 720p too ? How about VP8 I keep reading about lately ?

I wouldn't consider VP6 for anything nowadays, now that its successor's successor, VP8, has been OpenSource'd ;)

For a comparison of "VP8 -vs- x264" have a look here:
http://x264dev.multimedia.cx/?p=377

Especially see:
* http://doom10.org/compare/vp8.png
* http://doom10.org/compare/x264.png

[TheImperial2004]

While CRF18 + Inloop -4 -4 is super , I tried the same source (RAW desktop capture) with CRF30 + Inloop -4 -4 and it results in a great sharpness in a very low bitrates --> Size.

The problem was with the Inloop filter set to 0-0 ;)

The only thing was changing between frames was the mouse cursor position , so CRF30 is fair enough :)

Edit : Thanks for the reading resources of VP8 , will keep me busy for a while :)

[Motenai Yoda]

can someone add a preset for converting to a sap comp file?
ie filtering (resize to mod 16, low denoise) + asp (q 2, 1 b-frames, vhq for b, high search for vhq ecc) + mp3 (stereo cbr 128kbps) + avi?

[LoRd_MuldeR]

libx264 SVN-r1703:

libx264-r1703, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/w9iru7hva2cuyf7/libx264-104-r1703M-gcc451-core2-fprofiled.7z)
libx264-r1703, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/328l5x62w1c6077/libx264-104-r1703M-gcc451-amdfam10-fprofiled.7z)
libx264-r1703, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/v0802gd8np7xjs3/libx264-104-r1703M-gcc451-pentium3-fprofiled.7z)
libx264-r1703, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/hhrd26khsebmyuo/libx264-104-r1703M-gcc451-i686-fprofiled.7z)
libx264-r1703, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/q68z9abl7hnb6hc/libx264-104-r1703M-gcc451-noasm-fprofiled.7z)

libx264-r1703, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/n5t7q9ghxr9faw5/libx264-104-r1703M-gcc460-i686-fprofiled.7z) <-- MD5 mismatch detected, take care!
libx264-r1703, MinGW GCC 4.5.2, generic build (http://www.mediafire.com/file/b4rd5cwrnoj9wd8/libx264-104-r1703M-gcc452-i686-fprofiled.7z)
libx264-r1703, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/rwl3uwagatf1pgu/libx264-104-r1703M-gcc450-i686-fprofiled.7z)
libx264-r1703, MinGW GCC 4.4.5, generic build (http://www.mediafire.com/file/9bxd4lkzmyskalc/libx264-104-r1703M-gcc445-i686-fprofiled.7z)

libx264-r1703, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/q6ixc3qeeuo4jyq/libx264-104-r1703M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1703 with AutoVAQ enabled:

libx264-r1703, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/83coml6y2w6vj7i/libx264-104-r1703M-AutoVAQ-gcc451-core2-fprofiled.7z)
libx264-r1703, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/8562k4n59bpdep5/libx264-104-r1703M-AutoVAQ-gcc451-amdfam10-fprofiled.7z)
libx264-r1703, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/6jglapb8pm6734c/libx264-104-r1703M-AutoVAQ-gcc451-pentium3-fprofiled.7z)
libx264-r1703, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/nb2f1q43d5n2kzt/libx264-104-r1703M-AutoVAQ-gcc451-i686-fprofiled.7z)
libx264-r1703, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/oh3t9u64px4mhuy/libx264-104-r1703M-AutoVAQ-gcc451-noasm-fprofiled.7z)


libx264 SVN-r1703 with OpenGOP enabled:

libx264-r1703, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/pfj650f7obx438d/libx264-104-r1703M-OpenGOP-gcc451-core2-fprofiled.7z)
libx264-r1703, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/x602fp3nvl0b7kq/libx264-104-r1703M-OpenGOP-gcc451-amdfam10-fprofiled.7z)
libx264-r1703, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/asew0e8jqgjk6ib/libx264-104-r1703M-OpenGOP-gcc451-pentium3-fprofiled.7z)
libx264-r1703, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/6k762s6qzg4ojjd/libx264-104-r1703M-OpenGOP-gcc451-i686-fprofiled.7z)
libx264-r1703, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/g26gz6g0u7fwth2/libx264-104-r1703M-OpenGOP-gcc451-noasm-fprofiled.7z)


libx264 SVN-r1703 library pack:

libx264 SVN-r1703 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-104-r1703M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6502 (http://forum.doom9.org/showpost.php?p=1423078&postcount=1556) or later now!

[johnsonlam]

Maybe it'd be a lot easier to just copy the gui code from x264vfw? Than you have the bonus of an already nicely designed form and (depending on how much you have to modify) debugged form actions. It's not entirely complete, but it's a solid starting point.

Agree!
x264vfw interface is clean and good, why waste the precious time and effort to design another one?

[LoRd_MuldeR]

Agree!
x264vfw interface is clean and good, why waste the precious time and effort to design another one?

...because VFW is proprietary crap. Outdated technology from the early 90's. And most important: VFW is Windows-only! Consequently it cannot be used in any cross-platform application, such as Avidemux. Avidemux works on Windows and Linux as well as MacOS. Furthermore not even the GUI code of the x264 VFW Codec can be re-used, because it's written in a Windows-specific way too. In order to be portable between Windows, Linux and MacOS, the GUI code must be built on top of a cross-platform Toolkit, such as Qt, GTK+ or WxWidgets. The Avidemux GUI uses the Qt Framework (there also is a GTK+ version). Or in other words: Porting the x264 VFW GUI code to a cross-platform Toolkit would have been at least the same amount of work as writing a new GUI from the scratch. Last but not least: There is not "the" x264 VFW interface. The "official" one has been abandoned long ago. Since then the "unofficial" VFW interface has been maintained by other people and it has gone through a complete re-design at least twice...

(BTW: You think digging out a four-year-old post is funny ???)

[royia]

Hello LoRd_MuldeR,
I started using AVIDemux lately and it's great.

I was wondering about your libx264 releases.
I guess the GCC number is the version of the compiler.
Should we chose higher as possible or?

Moreover, about AVIDemux.
I have a Q9550 with 8GB on Win7 64Bit.
I transcode AVI captured in PAL (720x576 25fps).

I apply Deinterlace (yadif), Cropping and NR (CNR2).
I encode into MKV using x.264. The only parameter I change is quality (26 -> 25 / 22).
Audio encoding is into MP3 Mono 64kbps (CBR).

I get really slow framerate ~ 15fps.
Isn't it too slow?
I see people using MeGUI and DGAVIDec getting much faster rates.

Thanks.

[LoRd_MuldeR]

I guess the GCC number is the version of the compiler.

Right.


Should we chose higher as possible or?

Nope. GCC 4.6.0 is still "experimental" and in my last regression test I got MD5 mismatches with the GCC 4.6.0 build. So the GCC 4.6.0 build probably is miscompiled! :eek:

That's also the reason why I put up the warning after I noticed the problem. Currently I'd recommend to use the GCC 4.5.1 or GCC 4.4.5 builds...


Moreover, about AVIDemux.
I have a Q9550 with 8GB on Win7 64Bit.
I transcode AVI captured in PAL (720x576 25fps).

I apply Deinterlace (yadif), Cropping and NR (CNR2).
I encode into MKV using x.264. The only parameter I change is quality (26 -> 25 / 22).
Audio encoding is into MP3 Mono 64kbps (CBR).

I get really slow framerate ~ 15fps.
Isn't it too slow?

The video filters shouldn't be the bottleneck here. And 15 fps sounds pretty fast for x264. I usually use much "slower" settings and get ~6 fps for SD content ;)

Of course you can always use even "faster" x264 settings in order to sacrifice quality/compression for speed...


I see people using MeGUI and DGAVIDec getting much faster rates.

You mean DGAVCDec, I assume. DGAVCDec is a H.264 decoder for Avisynth. Avidemux can use Avisynth input (though AVSProxy), but it doesn't need to.

Also note that the DGAVCDec project has been discontinued in favor of DGDecodeNV, which uses hardware (GPU) decoding and which is payware.

If your source is H.264 and you really want to use Avisynth input and you don't own a DGDecodeNV license, then I'd recommend using FFmpegSource2 nowadays.

Moreover the decoder has negligible influence on the overall encoding speed, because ~99% of CPU time is spent in the encoder, usually...

[royia]

Thanks for your response.
So you say if I get ~15fps it's ok?
I use Rate Control (One Pass) 25 and get 15fps.
The average bit rate is about 1300kbps.

I was sure this configuration is able to do much better.
I gave you Core Optimized builds a chance, yet nothing improved significantly.

I thought that for a decent quality (The SD content I capture is from Hi8 Video, Nothing to write home about) I'll get at least twice the source frame rate (~50fps).
Any advice for that? You say I won't get better result using MeGUI and DGIndex (The source is in AVI format, Uncomressed straight from VirtualDUB I used for capturing, So I think I can use MeGUI without any need of DGIndex, Yet I need the ability to cut segments of the Source Video).

Thanks.

[LoRd_MuldeR]

Thanks for your response.
So you say if I get ~15fps it's ok?

For me it would be more than okay. Don't know what you expect! This always is a "speed -vs- quality/compression" trade-off, so decide yourself...


I use Rate Control (One Pass) 25 and get 15fps.

The rate control mode only has limited influence one encoding speed. There are other options, independent of rate control mode, that can have bigger influence.


The average bit rate is about 1300kbps.

If you use CRF mode (Constant Rate Factor) the resulting average bitrate is totally source-dependent. So I don't know what you want to say with that info :confused:


I was sure this configuration is able to do much better.
I gave you Core Optimized builds a chance, yet nothing improved significantly.

Again: The encoder speed is defined by the settings you have decided to use (given that you aren't bottlenecked by the decoder or by heavy filtering, of course)

If you want even more speed then use even faster settings! Faster settings will of course sacrifice quality/compression. You decide. That's life ;)


I thought that for a decent quality (The SD content I capture is from Hi8 Video, Nothing to write home about) I'll get at least twice the source frame rate (~50fps).

Maybe you have read too much marketing bull crap :D

There are all those companies who claim that their encoder is n-times faster than encoder XYZ, but they completely leave out the aspect of quality!

Any encoder can be damn fast - by producing crap quality. x264 can easily do this too - by using "ultra fast" settings :rolleyes:

Read this:
http://x264dev.multimedia.cx/?p=472

[royia]

Could you help me tune it?
Again the source is Hi8 VideoCamera.
I capture it into uncompressed AVI's using VirtualDub. The result is 720x576 25fps AVI (PAL).
The video quality is pretty poor, not even close to DVD. All I need is to keep it, not make it worse.

Now, all I want is to Deinterlace it, Crop, Remove some noise and Encode it into MKV file using x.264.
Till now I used CFR at 25. On average (for the 8 AVI so far) the rate was about 1300kbps (I know CFR works differently, yet that was the result).
The output looked much better than the source (Deinterlacing, Noise Removal).

All other parameters are in their default.
You think I could change something, given the poor quality of the source, to speed things up and keeping the output at quality above the source (Since the Deinterlacing and Noise Removal do most of the quality improvement)?

I'm looking for balanced, good enough settings. Since the source quality is poor, I guess some compromises can be done at the encoding without any significant quality loss.

Thanks.

[LoRd_MuldeR]

Could you help me tune it?

http://mulder.dummwiedeutsch.de/pub/x264/

And that's all I have to say about that...


Again the source is Hi8 VideoCamera.
I capture it into uncompressed AVI's using VirtualDub. The result is 720x576 25fps AVI (PAL).
The video quality is pretty poor, not even close to DVD. All I need is to keep it, not make it worse.

If you source is uncompressed AVI, then why talking about H.264 decoders, such as DGAVCDec, all the time? :confused:


Now, all I want is to Deinterlace it, Crop, Remove some noise and Encode it into MKV file using x.264.
Till now I used CFR at 25. On average (for the 8 AVI so far) the rate was about 1300kbps (I know CFR works differently, yet that was the result).
The output looked much better than the source (Deinterlacing, Noise Removal).

Well, Yadif is a pretty fast deinterlacer and still gives quite decent results. There of course are better (and much slower ones), such as TempGaussMC.

Pretty much the same with noise filters: You can have everything from "quick and dirty" to "ultra-slow and excellent". Again it depends on how much time you are willing to spent.

If you look for a simple and fast denoiser, why not give x264's built-in denoiser a try ???


All other parameters are in their default.
You think I could change something, given the poor quality of the source, to speed things up and keeping the output at quality above the source (Since the Deinterlacing and Noise Removal do most of the quality improvement)?

Sure. Disable CABAC and Trellis, use a faster ME Method (such as "Diamond"), use a lower Sub-ME Method, user fewer references use smaller RC Lookahead and so forth.

However note that with CRF mode using "faster" settings will not only hurt quality, but also hurt compression!

So the file might come out "bigger" at the same CRF when using "faster" settings. You might want to raise the CRF value a bit in order to compensate for this...


I'm looking for balanced, good enough settings.

The problem is that if you ask ten people, then you'll get ten different opinions on what is still "good enough" ;)

Consequently it is unavoidable to do some experiments yourself and decide what still looks "acceptable" for your eyes and what does not...


(BTW: When dealing with uncompressed video data, it's quite possible that you actually are bottleneck by HDD throughput)

[johnsonlam]

...because VFW is proprietary crap. Outdated technology from the early 90's. And most important: VFW is Windows-only!


Sorry, I'm talking about GUI only, no offense!


Consequently it cannot be used in any cross-platform application, such as Avidemux. Avidemux works on Windows and Linux as well as MacOS. Furthermore not even the GUI code of the x264 VFW Codec can be re-used, because it's written in a Windows-specific way too.


IMO, I know VFW is crap and should be completely thrown away ... but why it still exist? I think it's a historical reason, utilities such as VirtualDub still VFW based, and no application can replace it completely, that's why I don't like but forced to use VFW.


In order to be portable between Windows, Linux and MacOS, the GUI code must be built on top of a cross-platform Toolkit, such as Qt, GTK+ or WxWidgets. The Avidemux GUI uses the Qt Framework (there also is a GTK+ version). Or in other words: Porting the x264 VFW GUI code to a cross-platform Toolkit would have been at least the same amount of work as writing a new GUI from the scratch. Last but not least: There is not "the" x264 VFW interface. The "official" one has been abandoned long ago. Since then the "unofficial" VFW interface has been maintained by other people and it has gone through a complete re-design at least twice...


Understand.

I didn't refuse a better design but the current design was good and "seems" nothing was miss out.

I notice x264 seems got fewer activity on the front-end, I'd follow the codec news update on Doom9 and xvid.ru, now xvid.ru update more frequent then other site.

Honestly, in a user point of view (I'm just a bit more than user). I really don't care which technology was behind if it can help me to do the job, the X264 VFW's GUI is good, there's really no need to design a new one.


(BTW: You think digging out a four-year-old post is funny ???)


I really don't know about this, just receive an email and saw someone got new comments. If this is 4 years old post then I'm very disappointed, since then the official site stop updating (dead?) and development "look like" slow down a lot.

[LoRd_MuldeR]

1) You replied to foxyshadis' post, which (as everybody can see) is more than four years old. And now you "don't know about this"? That's hard to believe.

2) I already explained why a proprietary and platform-specific technology, such as VFW, cannot be used in a cross-platform software like Avidemux.

3) I also explained why not even the GUI code of the x264 VFW Codec could be re-used in a cross-platform software, which made writing a "new" GUI unavoidable.

4) Since this thread was started (more than four years ago !!!) a whole lot has happened. Avidemux now has a MUCH improved and (almost) complete x264 GUI.

So why this discussion NOW? What exactly do you want? :confused:

[johnsonlam]

1) You replied to foxyshadis' post, which (as everybody can see) is more than four years old. And now you "don't know about this"? That's hard to believe.


Overall is my fault, I'm sorry to restart an old thread.
I missed the date, exact said, I'm replying from my PC which have an 17inch LCD monitor, the date is small and usually I didn't read it intentionally.


2) I already explained why a proprietary and platform-specific technology, such as VFW, cannot be used in a cross-platform software like Avidemux.


Yes, I agree to abandon the Windows proprietary code is necessary.
What I want to say is "the old VFW interface worth to copy", just copy the outlook, not the code.


3) I also explained why not even the GUI code of the x264 VFW Codec could be re-used in a cross-platform software, which made writing a "new" GUI unavoidable.


Sorry for my bad English, I mean "outlook", the location of dialog box and buttons, not the code.


4) Since this thread was started (more than four years ago !!!) a whole lot has happened. Avidemux now has a MUCH improved and (almost) complete x264 GUI.


I use Avidemux also, the dialog is rich in function but the totally changed outlook took me a lot of time to "learn again", this is my message to all the programmers: please change as less as possible.


So why this discussion NOW? What exactly do you want? :confused:
[/quote]

Thanks for your time, just want to let the others know what I feel.
This is my last message of this thread.

I am sorry.

[LoRd_MuldeR]

What I want to say is "the old VFW interface worth to copy", just copy the outlook, not the code.

Sure, the x264 configuration dialog in Avidemux could have been created as an exact clone of the the x264 VFW GUI.

But then, which of the various incarnations of "x264 VFW" should have been chosen as model? This one (http://img59.imageshack.us/img59/5773/x264vfwconfiguration201.png) or this one (http://img707.imageshack.us/img707/5773/x264vfwconfiguration201.png) or maybe this one (http://img829.imageshack.us/img829/5773/x264vfwconfiguration201.png) ???

After all it was up the Avidemux developers' creativity to design the their own GUI.

So if you have any problem with Avidemux' current x264 configuration dialog, you should name the particular problem - and it might get addressed!

A complete re-write of the the x264 GUI in Avidemux, just to immitate the "x264 VFW" look, is extremely unrealistic at this point...

[LoRd_MuldeR]

Avidemux 2.5.3 r6587 (2010-09-05)
http://www.avidemux.org/

Revision 6587 (05 Sep 2010)
# Compiled with GCC 4.5.1.
# Updated Cairo to version 1.8.10-4.
# Updated Freetype to version 2.4.2-1.
# Updated GLib to version 2.24.2-1.
# Updated libvpx to version 0.9.2.
# Updated NSPR to version 4.8.6.
# Updated Pango to version 1.28.1-1.
# Updated x264 to r1713.
# Updated zlib to version 1.2.5-2.

6587 - [win32] update build scripts
6586 - [coreimage] gcc 4.5 patch
6585 - [ffmpeg] update FFmpeg to r25041 & libswscale to r32049
6581 - [opendml] Dont assert if header says there is audio wherease there is not
6571 - [MOV] Skip chan atom, fix playback of IMG_XX.MOV
6567 - [logoFilter] Re-enable it on non win32 platform + force symbol createImageFromFile
6559 - [mkv/demux] Also take into account repeat header when setting the frame type
6540 - [po] Czech translation update by Jakub M
6539 - [po] Hungarian translation update by alaci
6534 - [mkv] add support for stripped/repeat headers, fixes # 106
6530 - [TS/h264] Fix indexing h264 in mpeg TS
6502 - [ffmpeg] link and install avcore

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1713:

libx264-r1713, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/1moeio87zljdjld/libx264-104-r1713M-gcc451-core2-fprofiled.7z)
libx264-r1713, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/ccxbiccxvzkowml/libx264-104-r1713M-gcc451-amdfam10-fprofiled.7z)
libx264-r1713, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/xt1b46f7npfkbf3/libx264-104-r1713M-gcc451-pentium3-fprofiled.7z)
libx264-r1713, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/62moo74ui2yme39/libx264-104-r1713M-gcc451-i686-fprofiled.7z)
libx264-r1713, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/kw1hccync0wft21/libx264-104-r1713M-gcc451-noasm-fprofiled.7z)

libx264-r1713, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/z5yaoe6y6e980ga/libx264-104-r1713M-gcc460-i686-fprofiled.7z)
libx264-r1713, MinGW GCC 4.5.2, generic build (http://www.mediafire.com/file/te85oheybte5tgi/libx264-104-r1713M-gcc452-i686-fprofiled.7z)
libx264-r1713, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/7pha1ixgktdlb3n/libx264-104-r1713M-gcc450-i686-fprofiled.7z)
libx264-r1713, MinGW GCC 4.4.5, generic build (http://www.mediafire.com/file/yz8yrmd2bgnkk7q/libx264-104-r1713M-gcc445-i686-fprofiled.7z)

libx264-r1713, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/xoe4c7h0727tx8n/libx264-104-r1713M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1713 with AutoVAQ enabled:

libx264-r1713, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/s7m8su3srmsb9my/libx264-104-r1713M-AutoVAQ-gcc451-core2-fprofiled.7z)
libx264-r1713, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/24uu870bflicbcm/libx264-104-r1713M-AutoVAQ-gcc451-amdfam10-fprofiled.7z)
libx264-r1713, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/wj9y8ynydaxm2z6/libx264-104-r1713M-AutoVAQ-gcc451-pentium3-fprofiled.7z)
libx264-r1713, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/0irxxdeh407jbl7/libx264-104-r1713M-AutoVAQ-gcc451-i686-fprofiled.7z)
libx264-r1713, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/620cp26fue83y9d/libx264-104-r1713M-AutoVAQ-gcc451-noasm-fprofiled.7z)


libx264 SVN-r1713 with OpenGOP enabled:

libx264-r1713, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/s8r05d2wx4eeia9/libx264-104-r1713M-OpenGOP-gcc451-core2-fprofiled.7z)
libx264-r1713, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/qhc3uy8vbhs810z/libx264-104-r1713M-OpenGOP-gcc451-amdfam10-fprofiled.7z)
libx264-r1713, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/k4jgcxu787xcvk2/libx264-104-r1713M-OpenGOP-gcc451-pentium3-fprofiled.7z)
libx264-r1713, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/6ct0hizx3f71sf5/libx264-104-r1713M-OpenGOP-gcc451-i686-fprofiled.7z)
libx264-r1713, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/8xlgqztseg189mx/libx264-104-r1713M-OpenGOP-gcc451-noasm-fprofiled.7z)


libx264 SVN-r1713 with NAL-HRD (VBR mode) enabled:

libx264-r1713, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/w9t8iuuc28pl6dd/libx264-104-r1713M-NALHRD-gcc451-core2-fprofiled.7z)
libx264-r1713, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/5m1v3a6j71z35yt/libx264-104-r1713M-NALHRD-gcc451-amdfam10-fprofiled.7z)
libx264-r1713, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/ddwlrgroh2v24f0/libx264-104-r1713M-NALHRD-gcc451-pentium3-fprofiled.7z)
libx264-r1713, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/o3cwpbtmub6yqzb/libx264-104-r1713M-NALHRD-gcc451-i686-fprofiled.7z)
libx264-r1713, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/bc0ezml0i8aux45/libx264-104-r1713M-NALHRD-gcc451-noasm-fprofiled.7z)


libx264 SVN-r1713 library pack:

libx264 SVN-r1713 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-104-r1713M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6587 (http://forum.doom9.org/showpost.php?p=1432083&postcount=1582) or later now!

[LoRd_MuldeR]

It seems (not only) the audio decoders plugins are broken in Avidemux r6587, so here are the "old" plugins that appear to be working:
http://www.mediafire.com/file/26dcy5jrcay8tdw/Avidemux_Plugins_AudioDecoder_r6502.rar

Put those DLL's into your "C:\Program Files (x86)\Avidemux\plugins\audioDecoder" directory and replace the existing ones...


Avidemux r6587 has more problems. If you encounter crash with r6587, I recommend to stick with r6502 for the moment!

[UPDATE 2] The stability problems of Avidemux r6587 have been fixed in Avidemux r6636. Update is highly recommended, see below! [/UPDATE 2]

[LoRd_MuldeR]

libx264 SVN-r1724:

libx264-r1724, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/wdhbgvp2vxbefcf/libx264-104-r1724M-gcc451-core2-fprofiled.7z)
libx264-r1724, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/adg52drizyobwfj/libx264-104-r1724M-gcc451-amdfam10-fprofiled.7z)
libx264-r1724, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/9gxr7zr52oblg89/libx264-104-r1724M-gcc451-pentium3-fprofiled.7z)
libx264-r1724, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/i287utd23w855jx/libx264-104-r1724M-gcc451-i686-fprofiled.7z)
libx264-r1724, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/150jjnda1mmf6ya/libx264-104-r1724M-gcc451-noasm-fprofiled.7z)

libx264-r1724, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/3dyxkjlw838gp6p/libx264-104-r1724M-gcc460-i686-fprofiled.7z)
libx264-r1724, MinGW GCC 4.5.2, generic build (http://www.mediafire.com/file/6nffzpmfhtpjnow/libx264-104-r1724M-gcc452-i686-fprofiled.7z)
libx264-r1724, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/9hmpa2r4ywrm59a/libx264-104-r1724M-gcc450-i686-fprofiled.7z)
libx264-r1724, MinGW GCC 4.4.5, generic build (http://www.mediafire.com/file/2mbwv95o34nonkd/libx264-104-r1724M-gcc445-i686-fprofiled.7z)

libx264-r1724, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/eju3ml9kd4k9845/libx264-104-r1724M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1724 library pack:

libx264 SVN-r1724 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-104-r1724M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6587 (http://forum.doom9.org/showpost.php?p=1432083&postcount=1582) or later now!

I'm lazy, so extra builds with AutoVAQ, OpenGOP and NAL-HRD enabled are now included in the "all-in-one" library pack only!

[LoRd_MuldeR]

Avidemux 2.5.3 r6636 (2010-09-21)
http://www.avidemux.org/

This should fix the stability issues encountered with the previous (r6587) build. Update is highly recommended!

Revision 6636 (21 Sep 2010)
# Updated Cairo to version 1.10.0-1.
# Compiled with GCC 4.5.2 pre-release (20100917)
# Updated Qt to version 4.6.3.
# Updated x264 to r1724.

6636 - [win32] update installer
6631 - [render] make OpenGL renderer a little more cross-platform friendly
6630 - [render] OpenGL renderer for Qt
6617 - [apple] at least get 64-bit with SDL to compile
6613 - [apple] ppc build fix
6612 - Add script to unpack avsfilter wine binaries into /usr/share/ADM_addons/avsfilter under Linux
6609 - [apple] build fixes for plugins
6607 - [apple] build fix
6587 - [win32] update build scripts

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1724:

libx264-r1724, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/2f4p3kx97rzx2ec/libx264-105-r1724M-gcc451-core2-fprofiled.7z)
libx264-r1724, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/75x7zamfc2zn74n/libx264-105-r1724M-gcc451-amdfam10-fprofiled.7z)
libx264-r1724, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/7q8b5lg9l81pcd3/libx264-105-r1724M-gcc451-pentium3-fprofiled.7z)
libx264-r1724, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/a7z6ic1npc078tk/libx264-105-r1724M-gcc451-i686-fprofiled.7z)
libx264-r1724, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/r95i143ya7uo800/libx264-105-r1724M-gcc451-noasm-fprofiled.7z)

libx264-r1724, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/9001x1avuhs58fr/libx264-105-r1724M-gcc460-i686-fprofiled.7z)
libx264-r1724, MinGW GCC 4.5.2, generic build (http://www.mediafire.com/file/rc35dw4ru9hpv8o/libx264-105-r1724M-gcc452-i686-fprofiled.7z)
libx264-r1724, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/e1f7z4kg1sk0khe/libx264-105-r1724M-gcc450-i686-fprofiled.7z)
libx264-r1724, MinGW GCC 4.4.5, generic build (http://www.mediafire.com/file/rtrzl1ddurep7rv/libx264-105-r1724M-gcc445-i686-fprofiled.7z)

libx264-r1724, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/7cb2ibrewl0d25h/libx264-105-r1724M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1724 library pack:

libx264 SVN-r1724 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-105-r1724M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6636 (http://forum.doom9.org/showpost.php?p=1445010&postcount=1586) or later now!

Re-compiled x264 r1724 as core 105 for compatibility with Avidemux r6636. Update is recommended!

I'm lazy, so extra builds with AutoVAQ, OpenGOP and NAL-HRD enabled are now included in the "all-in-one" library pack only!

[LoRd_MuldeR]

libx264 SVN-r1732:

libx264-r1732, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/109fj4okbu65u7d/libx264-105-r1732M-gcc451-core2-fprofiled.7z)
libx264-r1732, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/emx4jm7cwf4ccvo/libx264-105-r1732M-gcc451-amdfam10-fprofiled.7z)
libx264-r1732, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/kbfia3ibqq0p2bw/libx264-105-r1732M-gcc451-pentium3-fprofiled.7z)
libx264-r1732, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/pa3cls3ui3qo3hy/libx264-105-r1732M-gcc451-i686-fprofiled.7z)
libx264-r1732, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/i9dqdg1n34h1i0z/libx264-105-r1732M-gcc451-noasm-fprofiled.7z)

libx264-r1732, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/n3x555rih3x1bcu/libx264-105-r1732M-gcc460-i686-fprofiled.7z)
libx264-r1732, MinGW GCC 4.5.2, generic build (http://www.mediafire.com/file/777zqw3dkyigf77/libx264-105-r1732M-gcc452-i686-fprofiled.7z)
libx264-r1732, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/nzz9x8vgq9hm9q3/libx264-105-r1732M-gcc450-i686-fprofiled.7z)
libx264-r1732, MinGW GCC 4.4.5, generic build (http://www.mediafire.com/file/da6gveqgc2hwd54/libx264-105-r1732M-gcc445-i686-fprofiled.7z)

libx264-r1732, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/y476m57aejiru12/libx264-105-r1732M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1732 library pack:

libx264 SVN-r1732 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-105-r1732M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6636 (http://forum.doom9.org/showpost.php?p=1445010&postcount=1586) or later now!

I'm lazy, so extra builds with AutoVAQ, OpenGOP and NAL-HRD enabled are now included in the "all-in-one" library pack only!

[wata]

when using x264 zones, is it possible for avidemux to record it in the mp4 create, right now it only show zones
using megui the mp4 has this written eg zones=145650,153758,q=26

also
when opening mkv, can this dialog be set to auto yes/no, if not how to batch encode a bunch of mkv/x264 files?

"H264 detected

If the file is using bframe as reference, it can lead to crash or stutteting.
Avidemux can use another mode which is safed but YOU WILL LOOSE FRAME ACCURACY.
Do you want to use that mode ?"

lastly,
opening a big mkv take a few minutes, can this info be save so that next time open the same mkv will be instant
just like the mpeg the index file is save to disk so open same file again will be instant.

[LoRd_MuldeR]

when using x264 zones, is it possible for avidemux to record it in the mp4 create, right now it only show zones
using megui the mp4 has this written eg zones=145650,153758,q=26

How exactly is that info added by MeGUI/x264 ???

If x264 writes that info as "option" string directly into the H.264 stream, then the info will be present, no matter what application calls (lib)x264 and no matter to what container the stream is saved. So in that case the info will be present with Avidemux as well. However if the info is added to the MP4 file as meta data (by x264's built-in MP4 muxer or even by MP4Box), then it won't work with Avidemux. That's because Avidemux uses its own MP4 muxer which doesn't add such info.

(Note the some older versions of Avidemux had a bug which dropped the x264 "option" string from the H.264 stream when muxing to MP4. If you use such old version, it may be sufficient to update to a less outdated build of Avidemux and info will be there ^^)


also
when opening mkv, can this dialog be set to auto yes/no, if not how to batch encode a bunch of mkv/x264 files?

"H264 detected

If the file is using bframe as reference, it can lead to crash or stutteting.
Avidemux can use another mode which is safed but YOU WILL LOOSE FRAME ACCURACY.
Do you want to use that mode ?"

Yes, but currently it only works via command-line.

You can pass the "--force-alt-h264" option before the "--load" command. In the GUI there is no way to skip or permanently disable the warning.

Anayway, with Avidemux 2.6 the warning will be gone anyway ;)


lastly,
opening a big mkv take a few minutes, can this info be save so that next time open the same mkv will be instant
just like the mpeg the index file is save to disk so open same file again will be instant.

This is not currently implemented. Maybe put a feature request into the Avidemux forum.

[wata]

How exactly is that info added by MeGUI/x264 ???

If x264 writes that info as "option" string directly into the H.264 stream, then the info will be present, no matter what application calls (lib)x264 and no matter to what container the stream is saved. So in that case the info will be present with Avidemux as well. However if the info is added to the MP4 file as meta data (by x264's built-in MP4 muxer or even by MP4Box), then it won't work with Avidemux. That's because Avidemux uses its own MP4 muxer which doesn't add such info.

(Note the some older versions of Avidemux had a bug which dropped the x264 "option" string from the H.264 stream when muxing to MP4. If you use such old version, it may be sufficient to update to a less outdated build of Avidemux and info will be there ^^)


i am using the latest version of both programs, i mean the info you see at the begining of the encoded file if you open it with a file viewer eg. from megui encode:

H.264/MPEG-4 AVC codec - Copyleft 2003-2010 - http://www.videolan.org/x264.html - options: cabac=1 ref=5 deblock=1:0:0 analyse=0x3:0x133 me=umh subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=-2 threads=3 sliced_threads=0 nr=0 decimate=1 interlaced=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=2 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=23 scenecut=40 intra_refresh=0 rc=crf mbtree=0 crf=19.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 pb_ratio=1.30 aq=1:1.00 zones=145650,153758,q=26

with avidemux it end with zones (the last part "=xxxx,xxxx,q=26" not written)

Yes, but currently it only works via command-line.

You can pass the "--force-alt-h264" option before the "--load" command. In the GUI there is no way to skip or permanently disable the warning.

Anayway, with Avidemux 2.6 the warning will be gone anyway ;)


guess i will try experimental 2.6 then

=edit=
nvm, seem 2.6 is an unfinished product most x264 option can't be set.

[LoRd_MuldeR]

Avidemux 2.5.3 r6689 (2010-09-29)
http://www.avidemux.org/

Revision 6689 (29 Sep 2010)
# Updated ATK to version 1.32.0-1.
# Updated GLib to version 2.26.0-2.
# Updated GTK+ to version 2.20.1-3.
# Updated Pango to version 1.28.1-2.
# Updated Qt to version 4.7.0.
# Updated x264 to r1732.

6689 - [x264] permit trellis without cabac
6688 - [x264] build fix
6687 - [x264] support infinite keyint
6686 - [x264] open gop support
6685 - [win32] drop SDL from Qt installer
6684 - [win32] redirect output regardless of SDL
6683 - [sdl] disable SDL support for Qt GUI
6679 - [x264] rearrange gop size controls
6678 - [x264] support for fake interlaced
6677 - [x264] max crf support
6674 - [x264] hrd & tff support
6670 - [win32] unicode support for js directory search class
6669 - [x264] resize window to make all tabs visible
6668 - [x264] split output options to new tab
6665 - [profile] PSP fix by bastafidli
6661 - [mkv] Use extradata in vfw compatibility mode

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1732:

libx264-r1732, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/vpisz1sjdp0bc7c/libx264-106-r1732M-gcc451-core2-fprofiled.7z)
libx264-r1732, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/mga2j8u60jwwxj6/libx264-106-r1732M-gcc451-amdfam10-fprofiled.7z)
libx264-r1732, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/x1ll001yyxtendk/libx264-106-r1732M-gcc451-pentium3-fprofiled.7z)
libx264-r1732, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/7w3h3m6y4f38wty/libx264-106-r1732M-gcc451-i686-fprofiled.7z)
libx264-r1732, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/qtx7mxoba7e6sd9/libx264-106-r1732M-gcc451-noasm-fprofiled.7z)

libx264-r1732, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/vpx6j46et43jyj6/libx264-106-r1732M-gcc460-i686-fprofiled.7z)
libx264-r1732, MinGW GCC 4.5.2, generic build (http://www.mediafire.com/file/qpo1peeoa1t1liu/libx264-106-r1732M-gcc452-i686-fprofiled.7z)
libx264-r1732, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/9vrpe63r0t3078o/libx264-106-r1732M-gcc450-i686-fprofiled.7z)
libx264-r1732, MinGW GCC 4.4.5, generic build (http://www.mediafire.com/file/4k95is4qdih53m9/libx264-106-r1732M-gcc445-i686-fprofiled.7z)

libx264-r1732, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/jfvcucupsaf13a3/libx264-106-r1732M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1732 library pack:

libx264 SVN-r1732 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-106-r1732M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6689 (http://forum.doom9.org/showpost.php?p=1447526&postcount=1592) or later now!

Re-compiled x264 r1732 as core 106 for compatibility with Avidemux r6689. Update is recommended.

As Avidemux fully supports OpenGOP as well as NAL-HRD now, special "patched" builds are NOT needed for those anymore. Yeah!
However AutoVAQ still is missing from Avidemux' x264 options. Thus AutoVAQ builds are provided in the "all-in-one" library pack.

[LoRd_MuldeR]

i am using the latest version of both programs, i mean the info you see at the begining of the encoded file if you open it with a file viewer eg. from megui encode:

H.264/MPEG-4 AVC codec - Copyleft 2003-2010 - http://www.videolan.org/x264.html - options: cabac=1 ref=5 deblock=1:0:0 analyse=0x3:0x133 me=umh subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=-2 threads=3 sliced_threads=0 nr=0 decimate=1 interlaced=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=2 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=23 scenecut=40 intra_refresh=0 rc=crf mbtree=0 crf=19.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 pb_ratio=1.30 aq=1:1.00 zones=145650,153758,q=26

with avidemux it end with zones (the last part "=xxxx,xxxx,q=26" not written).

Okay, I have checked this. x264 indeed writes the zones to the "options" string, if zones are used. And, as x264 writes the options string (including zones, if present) directly into the bitstream, the info will be present in the file, no matter what application is used. So if you open the file saved from Avidemux in some Hex-Editor, then you will see that it does contain the x264 option string!

However there are two different methods to pass zones to x264: The one method will directly pass an array of 'x264_zone_t' to the x264 library, while the other method passes all zones coded into a single string (x264 will then parse that string internally). Only with the latter method the x264 option string (the one written to the file) will contain detailed zones information. Actually the 'zones' string that was passed to x264 is simply copied into the x264 options string! That of course won't work when the former method is used to pass the zones to x264. Avidemux uses x264 as a DLL, and thus it uses the former method ^^

An excerpt from the x264 code:
char *x264_param2string( x264_param_t *p, int b_res )
{
[...]

if( p->rc.psz_zones )
s += sprintf( s, " zones=%s", p->rc.psz_zones ); // <-- used with x264 CLI
else if( p->rc.i_zones )
s += sprintf( s, " zones" ); // <-- used with x264 DLL (e.g. Avidemux)

[...]
}

[LoRd_MuldeR]

libx264 SVN-r1745:

libx264-r1745, MinGW GCC 4.5.1, optimized for Core 2 (http://www.mediafire.com/file/h00md1dvsdvjd9f/libx264-106-r1745M-gcc451-core2-fprofiled.7z)
libx264-r1745, MinGW GCC 4.5.1, optimized for K10 (http://www.mediafire.com/file/4g57cjuin28aklt/libx264-106-r1745M-gcc451-amdfam10-fprofiled.7z)
libx264-r1745, MinGW GCC 4.5.1, optimized for Pentium III (http://www.mediafire.com/file/xbxmwb1m95gagdm/libx264-106-r1745M-gcc451-pentium3-fprofiled.7z)
libx264-r1745, MinGW GCC 4.5.1, generic build (http://www.mediafire.com/file/9a6536ou067566m/libx264-106-r1745M-gcc451-i686-fprofiled.7z)
libx264-r1745, MinGW GCC 4.5.1, without ASM (slow!) (http://www.mediafire.com/file/gfe58qg078zp100/libx264-106-r1745M-gcc451-noasm-fprofiled.7z)

libx264-r1745, MinGW GCC 4.4.5, optimized for Core 2 (http://www.mediafire.com/file/e24i32od17g9h33/libx264-106-r1745M-gcc445-core2-fprofiled.7z)
libx264-r1745, MinGW GCC 4.4.5, optimized for K10 (http://www.mediafire.com/file/o9ehn7v98gycvze/libx264-106-r1745M-gcc445-amdfam10-fprofiled.7z)
libx264-r1745, MinGW GCC 4.4.5, optimized for Pentium III (http://www.mediafire.com/file/jc4x72xnn541ncx/libx264-106-r1745M-gcc445-pentium3-fprofiled.7z)
libx264-r1745, MinGW GCC 4.4.5, generic build (http://www.mediafire.com/file/sp9214q8r337sdv/libx264-106-r1745M-gcc445-i686-fprofiled.7z)
libx264-r1745, MinGW GCC 4.4.5, without ASM (slow!) (http://www.mediafire.com/file/e83iw2bbe78bev3/libx264-106-r1745M-gcc445-noasm-fprofiled.7z)

libx264-r1745, MinGW GCC 4.5.2, generic build (http://www.mediafire.com/file/mdxqg6l2sbqr35v/libx264-106-r1745M-gcc452-i686-fprofiled.7z)
libx264-r1745, MinGW GCC 4.5.0, generic build (http://www.mediafire.com/file/1gyz61khuj7erht/libx264-106-r1745M-gcc450-i686-fprofiled.7z)

libx264-r1745, MinGW GCC 4.6.0, experimental build (http://www.mediafire.com/file/4edxr86i56sl3dc/libx264-106-r1745M-gcc460-i686-fprofiled.7z)
libx264-r1745, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/cn9ik1954on5q31/libx264-106-r1745M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1745 library pack:

libx264 SVN-r1745 complete "all-in-one" library pack (mirror #1) (http://code.google.com/p/mulder/downloads/detail?name=libx264-106-r1745M-win32.7z)
libx264 SVN-r1745 complete "all-in-one" library pack (mirror #2) (http://www.mediafire.com/file/v9agrbsavacboa5/libx264-106-r1745M-win32.7z)


These builds will NOT work with Avidemux 2.5.2 or older. Please update to Avidemux 2.5.3 r6689 (http://forum.doom9.org/showpost.php?p=1447526&postcount=1592) or later now!

As Avidemux fully supports OpenGOP as well as NAL-HRD now, special "patched" builds are NOT needed for those anymore. Yeah!
However AutoVAQ still is missing from Avidemux' x264 options. Thus AutoVAQ builds are provided in the "all-in-one" library pack.

[TheImperial2004]

2.5.4 is out , still waiting for Gruntster's build though :D

Hey Mulder , any word on when we will see 10bit Libx264 ? Sorry if that has been answered before :)

[LoRd_MuldeR]

2.5.4 is out , still waiting for Gruntster's build though :D

You can simply use the latest SVN build available from Gruntster's site. It was basically built from the same code that is tagged "2.5.4" now ;)

I'm also waiting for Gruntster to review and eventually commit my x264 patch, which adds Psy-Trellis, AutoVAQ as well as Sub-ME 10 to the Avidemux' GUI.

But it seems he hasn't been active for quite a while...


Hey Mulder , any word on when we will see 10bit Libx264 ? Sorry if that has been answered before :)

10-Bit x264 is slow as hell, as no assembly code has been committed for the 10-Bit path yet.

Moreover there's no free H.264 decoder that handles 10-Bit available yet, even commercial ones are still rare. And hardware support for 10-Bit H.264 doesn't exist in consumer devices :rolleyes:

Last but not least the bit-depth of x264 is not a run-time option, but a build option. So we cannot have x264 with both, 8-Bit and 10-Bit support, at the same time.

Consequently 10-Bit x264 won't be a real topic that soon. Maybe at some point in the future...

[TheImperial2004]

And hardware support for 10-Bit H.264 doesn't exist in consumer devices

Hmmm , is that true for GPUs (DXVA - VDPAU) too ? So basically we NEED new GPUs that can decode the stream , Or does a simple driver update will add support for it ?

So we cannot have x264 with both, 8-Bit and 10-Bit support, at the same time.

Good lord , you'll have a lot of work ahead of you , preparing both builds for us the spoiled consumers :D

Best regards :)

[LoRd_MuldeR]

Hmmm , is that true for GPUs (DXVA - VDPAU) too ? So basically we NEED new GPUs that can decode the stream , Or does a simple driver update will add support for it ?

As far as I know, the hardware decoders of the current GPU generation don't support the "High 10" (or even 4:2:2/4:4:4) profile of H.264 :(

And because those hardware "video decoder" engines are not implemented as GPU programs (kernels) but as a separate/dedicated piece of hardware, a simple driver update can't fix that.

Consequently we'd need new GPU hardware, but I'm not sure whether NVidia and AMD are interested in "High 10" support in their upcoming GPU generation...

(Neither DVB-S2 nor BluRay supports the "High 10" profile, so my assumption is that 10-Bit H.264 will remain a niche market. Currently the "3D" hype is what matters for manufacturers)

[TheImperial2004]

As far as I know, the hardware decoders of the current GPU generation don't support the "High 10" (or even 4:2:2/4:4:4) profile of H.264 :(

And because those hardware "video decoder" engines are not implemented as GPU programs (kernels) but as a separate/dedicated piece of hardware, a simple driver update can't fix that.

Consequently we'd need new GPU hardware, but I'm not sure whether NVidia and AMD are interested in "High 10" support in their upcoming GPU generation...

(Neither DVB-S2 nor BluRay supports the "High 10" profile, so my assumption is that 10-Bit H.264 will remain a niche market. Currently the "3D" hype is what matters for manufacturers)
:eek: I wish that I gave a second thought before spending $500+ on my GTX480 . but ah well , as long as they don't include it in their next gen GPUs I'll be fine :D

[LoRd_MuldeR]

Avidemux 2.5.4 r6796 (2010-11-28)
http://www.avidemux.org/

Revision 6796 (28 Nov 2010)
Updated aften to version git version (commit: c0bd512c93b1186c28b45cc66f6e4f70fd41191c).
Updated libogg to version 1.2.1.
Updated libvorbis to version 1.3.2.
Updated libvpx to version 0.9.5.
Updated Qt to version 4.7.1.
Updated x264 to r1804.

6796 - [build] bump version
6795 - [win] update avidemux build scripts and installer
6792 - [win] more build scripts
6791 - [ffmpeg] update FFmpeg to r25831 & libswscale to r32647
6790 - [mingw64] compilation fix
6789 - [aften] add support for git version of Aften
6788 - [ffmpeg] remove old tarballs
6787 - [x264] support core version 110
6747 - [flv] Get width and height when metadata happens later
6746 - [Flv] Fix Zapping.flv
6745 - [mp4] Fix playback of P103xxx.MOV (LPCM in mov)
6744 - [flv] Handle nicely object_end tag
6738 - [linux/avsfilter] add wine pathname to filter dialog, set empty config pathnames to install prefix
6716 - [Gtk] dont crash if default value is out of bound
6715 - [audio] Fix audio handling, we always have audio, at worst it is dummy
6700 - [x264] correctly load hrd option
6696 - [srt] Merge gentoo patch 249367
6695 - [i18n] German update by lance
6694 - [ffmpeg] update ffmpeg & libswscale tarballs
6693 - [x264] use key frame flag rather than deriving from frame type
6692 - [po] italian update by zoppo

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

Avidemux 2.5.4 r6854 (2010-12-20)
http://www.avidemux.org/

Revision 6854 (20 Dec 2010)
Updated libogg to version 1.2.2.

6854 - [ffmpeg] update FFmpeg to r26061 & libswscale to r32724
6853 - [x264] psy trellis and autovaq patch by lord mulder
6852 - [win] update build scripts
6846 - [H264/indexer] Fix short startcode SEI
6844 - [lavcodec] Export function to get internal info about SPS through h264_parser
6843 - [H264/info extractor] Use lavcodec to decode SPS as in 2.6, it seems the internal decoder chokes on some SPS
6842 - [H264/indexer] Read the whole SPS, not 60 bytes hardcoded. Fix decoding some M2TS
6800 - [win] update lame build script

Download Mirror #1: http://mulder.googlecode.com/ (http://code.google.com/p/mulder/downloads/list)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r1834:

libx264-r1834, MinGW GCC 4.5.2, optimized for Core 2 (http://www.mediafire.com/file/647iro8qx7ug2p8/libx264-112-r1834M-gcc452-core2-fprofiled.7z)
libx264-r1834, MinGW GCC 4.5.2, optimized for K10 (http://www.mediafire.com/file/b1m5oguaj55bzqa/libx264-112-r1834M-gcc452-amdfam10-fprofiled.7z)
libx264-r1834, MinGW GCC 4.5.2, optimized for Pentium III (http://www.mediafire.com/file/v2onkqxsaum4dxt/libx264-112-r1834M-gcc452-pentium3-fprofiled.7z)
libx264-r1834, MinGW GCC 4.5.2, generic build (http://www.mediafire.com/file/7ns1p6c5sqgmbb9/libx264-112-r1834M-gcc452-i686-fprofiled.7z)
libx264-r1834, MinGW GCC 4.5.2, without ASM (slow!) (http://www.mediafire.com/file/0bnan0odb5dq7os/libx264-112-r1834M-gcc452-noasm-fprofiled.7z)

libx264-r1834, MinGW GCC 4.4.5, optimized for Core 2 (http://www.mediafire.com/file/p50hv7pigfdhib6/libx264-112-r1834M-gcc445-core2-fprofiled.7z)
libx264-r1834, MinGW GCC 4.4.5, optimized for K10 (http://www.mediafire.com/file/bet5iwc876o2ffs/libx264-112-r1834M-gcc445-amdfam10-fprofiled.7z)
libx264-r1834, MinGW GCC 4.4.5, optimized for Pentium III (http://www.mediafire.com/file/w8ciaqnq32mmfmh/libx264-112-r1834M-gcc445-pentium3-fprofiled.7z)
libx264-r1834, MinGW GCC 4.4.5, generic build (http://www.mediafire.com/file/u7opch2nqq6cv1f/libx264-112-r1834M-gcc445-i686-fprofiled.7z)
libx264-r1834, MinGW GCC 4.4.5, without ASM (slow!) (http://www.mediafire.com/file/e0rcqfds5trj529/libx264-112-r1834M-gcc445-noasm-fprofiled.7z)

libx264-r1834, MinGW GCC 4.5.1, legacy build (http://www.mediafire.com/file/kdrb53ft3jv8t98/libx264-112-r1834M-gcc451-i686-fprofiled.7z)
libx264-r1834, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/lc8y873d6z1a505/libx264-112-r1834M-gcc345-i686-fprofiled.7z)

libx264-r1834, MinGW GCC 4.6.0, experimental build (http://www.mediafire.com/file/e9oij49v606iab6/libx264-112-r1834M-gcc460-i686-fprofiled.7z)


libx264 SVN-r1834 library pack:

libx264 SVN-r1834 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-112-r1834M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r6854 (http://forum.doom9.org/showpost.php?p=1466619&postcount=1602) or later now!

Auto-VAQ, Sub-ME 10 and Psy-Trellis are now available as runtime options in Avidemux, so there are no more special builds!

[TheImperial2004]

hmmm , I can't seem to find the x264 codec under the Video dropdown menu :confused:

See attachment

[LoRd_MuldeR]

Make sure you have "Plugins" -> "Video Encoders" -> "x264" checked on the "Choose Components" page during Avidemux installation ;)

[TheImperial2004]

I tried reinstalling it , I double checked that x264 is checked ... Still a no go :(

[LoRd_MuldeR]

I tried reinstalling it , I double checked that x264 is checked ... Still a no go :(

Well, did you check, is the x264 plugin actually installed? And if so, does it get loaded at runtime ???

There should be a file:
C:\Program Files (x86)\Avidemux 2.5\plugins\videoEncoder\libADM_vidEnc_x264.dll

And in Avidemux under "Help" -> "Plugins..." you should find "x264 video encoder plugin for Avidemux" on the "Video Encoder" tab.

[TheImperial2004]

The file libADM_vidEnc_x264.dll does exist , but the x264 encoder doesn't show in the plugins tab . I'm using the 64bit version though . :rolleyes:

[LoRd_MuldeR]

The file libADM_vidEnc_x264.dll does exist , but the x264 encoder doesn't show in the plugins tab . I'm using the 64bit version though . :rolleyes:

So did you try the 32-Bit version ???

And, when you tried to use the 64-Bit version, did you make sure your "libADM_vidEnc_x264.dll" is 64-Bit too? You know, 64-Bit program cannot load 32-Bit DLL's ;)

If in doubt, the Dependency Walker (http://www.dependencywalker.com/) does a good job in such situations!

[TheImperial2004]

32bit works like charm , its definitely that these DLLs aren't 64bit ready yet . :)

[LoRd_MuldeR]

libx264 SVN-r1867:

libx264-r1867, MinGW GCC 4.5.2, optimized for Core 2 (http://www.mediafire.com/file/8wg4qxoz40cnb27/libx264-112-r1867M-gcc452-core2-fprofiled.7z)
libx264-r1867, MinGW GCC 4.5.2, optimized for K10 (http://www.mediafire.com/file/8r95l0b02758ek0/libx264-112-r1867M-gcc452-amdfam10-fprofiled.7z)
libx264-r1867, MinGW GCC 4.5.2, optimized for Pentium III (http://www.mediafire.com/file/t28rz30927ta615/libx264-112-r1867M-gcc452-pentium3-fprofiled.7z)
libx264-r1867, MinGW GCC 4.5.2, generic build (http://www.mediafire.com/file/bty8eg1c2xte5rb/libx264-112-r1867M-gcc452-i686-fprofiled.7z)
libx264-r1867, MinGW GCC 4.5.2, without ASM (slow!) (http://www.mediafire.com/file/fazxk5z6xm8run0/libx264-112-r1867M-gcc452-noasm-fprofiled.7z)

libx264-r1867, MinGW GCC 4.4.5, optimized for Core 2 (http://www.mediafire.com/file/98rxh78qhdt8d21/libx264-112-r1867M-gcc445-core2-fprofiled.7z)
libx264-r1867, MinGW GCC 4.4.5, optimized for K10 (http://www.mediafire.com/file/mt4se4aj67c8s4r/libx264-112-r1867M-gcc445-amdfam10-fprofiled.7z)
libx264-r1867, MinGW GCC 4.4.5, optimized for Pentium III (http://www.mediafire.com/file/3dohsh3d7g21516/libx264-112-r1867M-gcc445-pentium3-fprofiled.7z)
libx264-r1867, MinGW GCC 4.4.5, generic build (http://www.mediafire.com/file/1d01b697i64yifp/libx264-112-r1867M-gcc445-i686-fprofiled.7z)
libx264-r1867, MinGW GCC 4.4.5, without ASM (slow!) (http://www.mediafire.com/file/3jz39bak2bdq9o9/libx264-112-r1867M-gcc445-noasm-fprofiled.7z)

libx264-r1867, MinGW GCC 4.5.1, legacy build (http://www.mediafire.com/file/r9l9v2ydpg38u9n/libx264-112-r1867M-gcc451-i686-fprofiled.7z)
libx264-r1867, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/aile5fqjyh6840k/libx264-112-r1867M-gcc345-i686-fprofiled.7z)

libx264-r1867, MinGW GCC 4.6.0, experimental build (http://www.mediafire.com/file/ivpyt7icd32b2db/libx264-112-r1867M-gcc460-i686-fprofiled.7z)


libx264 SVN-r1867 library pack:

libx264 SVN-r1867 complete "all-in-one" library pack (http://code.google.com/p/mulder/downloads/detail?name=libx264-112-r1867M-win32.7z&can=2&q=)


These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r6854 (http://forum.doom9.org/showpost.php?p=1466619&postcount=1602) or later now!

Please note the recent changes in x264's internal quality measurement! See the commit message (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=22bfd310abced4df0b11c9620b152e5cfe746d43) for details...

[Romario]

Hi,what's going on with Avidemux 2.5x ? Can you,L:ord_MuldeR,compile newest build ?

If you want,Ican test 64-bit version of Avidemux 2.58,so tell me what I need to do. :)

[Rain1]

LoRd_MuldeR, can you compile 64bit version, please ?

Thanks :)

[LoRd_MuldeR]

I usually don't compile Avidemux for win-x86 (32-Bit) or win-x64 (64-Bit), as Gruntster (http://avidemux.razorbyte.com.au/) creates new Avidemux 2.5.x builds for Windows at regular intervals.

The latest build currently is r6854 (2010-12-20) and I don't think much has happened since then. That's because most (if not all) development is currently going into the Avidemux 2.6 branch.

And if you want to give Avidemux 2.6 a try, then see this (http://forum.doom9.org/showthread.php?t=158580) thread please. There are "nightly" builds of the 2.6 branch for Win32 available...

[Romario]

Thank you,but can you,at least,compile libx264 SVN-r1867 complete "all-in-one" library pack but for 64-bit. Thanks.

[LoRd_MuldeR]

Thank you,but can you,at least,compile libx264 SVN-r1867 complete "all-in-one" library pack but for 64-bit. Thanks.

I don't make 64-Bit builds of libx264 currently (don't have the build env set up). You can use the libx264 that ships with Gruntster's 64-Bit Avidemux builds...

[LoRd_MuldeR]

libx264 SVN-r1881:

libx264-r1881, MinGW GCC 4.5.2, optimized for Core 2 (http://www.mediafire.com/file/5bpjdvjylmm9cx3/libx264-112-r1881M-gcc452-core2-fprofiled.7z)
libx264-r1881, MinGW GCC 4.5.2, optimized for K10 (http://www.mediafire.com/file/ppo95p8natx1e3a/libx264-112-r1881M-gcc452-amdfam10-fprofiled.7z)
libx264-r1881, MinGW GCC 4.5.2, optimized for Pentium III (http://www.mediafire.com/file/ys8f948ks4u81k0/libx264-112-r1881M-gcc452-pentium3-fprofiled.7z)
libx264-r1881, MinGW GCC 4.5.2, generic build (http://www.mediafire.com/file/nabp85lonqzc2b5/libx264-112-r1881M-gcc452-i686-fprofiled.7z)
libx264-r1881, MinGW GCC 4.5.2, without ASM (slow!) (http://www.mediafire.com/file/zb1fdaoap35ja10/libx264-112-r1881M-gcc452-noasm-fprofiled.7z)

libx264-r1881, MinGW GCC 4.4.5, optimized for Core 2 (http://www.mediafire.com/file/xx1vr26j6xd2qab/libx264-112-r1881M-gcc445-core2-fprofiled.7z)
libx264-r1881, MinGW GCC 4.4.5, optimized for K10 (http://www.mediafire.com/file/dq5am2b5ecywqib/libx264-112-r1881M-gcc445-amdfam10-fprofiled.7z)
libx264-r1881, MinGW GCC 4.4.5, optimized for Pentium III (http://www.mediafire.com/file/8dkri17pdxzctii/libx264-112-r1881M-gcc445-pentium3-fprofiled.7z)
libx264-r1881, MinGW GCC 4.4.5, generic build (http://www.mediafire.com/file/yli6bbm9iebabkg/libx264-112-r1881M-gcc445-i686-fprofiled.7z)
libx264-r1881, MinGW GCC 4.4.5, without ASM (slow!) (http://www.mediafire.com/file/7d76g71ijllx7jb/libx264-112-r1881M-gcc445-noasm-fprofiled.7z)

libx264-r1881, MinGW GCC 4.5.1, legacy build (http://www.mediafire.com/file/4zhkb8q3z03jbc8/libx264-112-r1881M-gcc451-i686-fprofiled.7z)
libx264-r1881, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/8e5ypdyxa4qes4t/libx264-112-r1881M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1881 library pack:

libx264 SVN-r1881 complete "all-in-one" library pack (mirror #1) (http://code.google.com/p/mulder/downloads/detail?name=libx264-112-r1881M-win32.7z&can=2&q=)
libx264 SVN-r1881 complete "all-in-one" library pack (mirror #2) (http://www.mediafire.com/file/rc1nhm1o4xr2xaw/libx264-112-r1881M-win32.7z)


These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r6854 (http://forum.doom9.org/showpost.php?p=1466619&postcount=1602) or later now!

[LoRd_MuldeR]

libx264 SVN-r1882:

libx264-r1882, MinGW GCC 4.5.2, optimized for Core 2 (http://www.mediafire.com/file/7ddb20bi3w197g7/libx264-112-r1882M-gcc452-core2-fprofiled.7z)
libx264-r1882, MinGW GCC 4.5.2, optimized for K10 (http://www.mediafire.com/file/46dmrqhdbqwchq0/libx264-112-r1882M-gcc452-amdfam10-fprofiled.7z)
libx264-r1882, MinGW GCC 4.5.2, optimized for Pentium III (http://www.mediafire.com/file/qpzxaxlykfvw4ex/libx264-112-r1882M-gcc452-pentium3-fprofiled.7z)
libx264-r1882, MinGW GCC 4.5.2, generic build (http://www.mediafire.com/file/lu3j51v272x6fgu/libx264-112-r1882M-gcc452-i686-fprofiled.7z)
libx264-r1882, MinGW GCC 4.5.2, without ASM (slow!) (http://www.mediafire.com/file/hbdrj6v34ryobg7/libx264-112-r1882M-gcc452-noasm-fprofiled.7z)

libx264-r1882, MinGW GCC 4.4.5, optimized for Core 2 (http://www.mediafire.com/file/zz3f6t3gum17v3d/libx264-112-r1882M-gcc445-core2-fprofiled.7z)
libx264-r1882, MinGW GCC 4.4.5, optimized for K10 (http://www.mediafire.com/file/h77kp19jw5hc1g5/libx264-112-r1882M-gcc445-amdfam10-fprofiled.7z)
libx264-r1882, MinGW GCC 4.4.5, optimized for Pentium III (http://www.mediafire.com/file/w5p8powy4i5na5x/libx264-112-r1882M-gcc445-pentium3-fprofiled.7z)
libx264-r1882, MinGW GCC 4.4.5, generic build (http://www.mediafire.com/file/4latvvvb22fn0h8/libx264-112-r1882M-gcc445-i686-fprofiled.7z)
libx264-r1882, MinGW GCC 4.4.5, without ASM (slow!) (http://www.mediafire.com/file/l5n5ut1p87o3cum/libx264-112-r1882M-gcc445-noasm-fprofiled.7z)

libx264-r1882, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/xf6npsezqz2f76z/libx264-112-r1882M-gcc460-core2-fprofiled.7z)
libx264-r1882, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/5dcxtntl22mff5q/libx264-112-r1882M-gcc460-amdfam10-fprofiled.7z)
libx264-r1882, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/g95utwn46r3hm35/libx264-112-r1882M-gcc460-pentium3-fprofiled.7z)
libx264-r1882, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/9kq7he1cu9955sh/libx264-112-r1882M-gcc460-i686-fprofiled.7z)
libx264-r1882, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/bntcf6hlriaa61c/libx264-112-r1882M-gcc460-noasm-fprofiled.7z)

libx264-r1882, MinGW GCC 4.5.1, legacy build (http://www.mediafire.com/file/sezsznv19fz8om4/libx264-112-r1882M-gcc451-i686-fprofiled.7z)
libx264-r1882, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/rbb01isyb3yo9bz/libx264-112-r1882M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1882 library pack:

libx264 SVN-r1882 complete "all-in-one" library pack (mirror #1) (http://code.google.com/p/mulder/downloads/detail?name=libx264-112-r1882M-win32.7z&can=2&q=)
libx264 SVN-r1882 complete "all-in-one" library pack (mirror #2) (http://www.mediafire.com/file/451a403rrktogw2/libx264-112-r1882M-win32.7z)


These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r6854 (http://forum.doom9.org/showpost.php?p=1466619&postcount=1602) or later now!

r1882 should fix a potential crash on AVX-enabled CPU's, when running on Windows prior to Windows 7 Service-Pack 1.

[LoRd_MuldeR]

libx264 SVN-r1884:

libx264-r1884, MinGW GCC 4.5.2, optimized for Core 2 (http://www.mediafire.com/file/5anrc8aiaak7ac7/libx264-112-r1884M-gcc452-core2-fprofiled.7z)
libx264-r1884, MinGW GCC 4.5.2, optimized for K10 (http://www.mediafire.com/file/n4xdphlr5qa6ra9/libx264-112-r1884M-gcc452-amdfam10-fprofiled.7z)
libx264-r1884, MinGW GCC 4.5.2, optimized for Pentium III (http://www.mediafire.com/file/s8803x3wz2cw5v7/libx264-112-r1884M-gcc452-pentium3-fprofiled.7z)
libx264-r1884, MinGW GCC 4.5.2, generic build (http://www.mediafire.com/file/9jea6g761w7jicb/libx264-112-r1884M-gcc452-i686-fprofiled.7z)
libx264-r1884, MinGW GCC 4.5.2, without ASM (slow!) (http://www.mediafire.com/file/q9eby2qw1dcnj3f/libx264-112-r1884M-gcc452-noasm-fprofiled.7z)

libx264-r1884, MinGW GCC 4.4.5, optimized for Core 2 (http://www.mediafire.com/file/ntk3qdmhulvd03n/libx264-112-r1884M-gcc445-core2-fprofiled.7z)
libx264-r1884, MinGW GCC 4.4.5, optimized for K10 (http://www.mediafire.com/file/byx5dcw1yn9xd34/libx264-112-r1884M-gcc445-amdfam10-fprofiled.7z)
libx264-r1884, MinGW GCC 4.4.5, optimized for Pentium III (http://www.mediafire.com/file/uimfwxrlrwwz2dm/libx264-112-r1884M-gcc445-pentium3-fprofiled.7z)
libx264-r1884, MinGW GCC 4.4.5, generic build (http://www.mediafire.com/file/hegx3cslxh0vbhs/libx264-112-r1884M-gcc445-i686-fprofiled.7z)
libx264-r1884, MinGW GCC 4.4.5, without ASM (slow!) (http://www.mediafire.com/file/1u5py9db8ua5c6l/libx264-112-r1884M-gcc445-noasm-fprofiled.7z)

libx264-r1884, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/687x2z8bt4thvz2/libx264-112-r1884M-gcc460-core2-fprofiled.7z)
libx264-r1884, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/be2b5socava89h7/libx264-112-r1884M-gcc460-amdfam10-fprofiled.7z)
libx264-r1884, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/nb1c5endf5nc3d1/libx264-112-r1884M-gcc460-pentium3-fprofiled.7z)
libx264-r1884, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/285csh84lb6f64c/libx264-112-r1884M-gcc460-i686-fprofiled.7z)
libx264-r1884, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/xtok5v32ujbagw9/libx264-112-r1884M-gcc460-noasm-fprofiled.7z)

libx264-r1884, MinGW GCC 4.5.1, legacy build (http://www.mediafire.com/file/tp0hrcsj5usx1au/libx264-112-r1884M-gcc451-i686-fprofiled.7z)
libx264-r1884, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/r7dco78vye1dq67/libx264-112-r1884M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1884 library pack:

libx264 SVN-r1884 complete "all-in-one" library pack (mirror #1) (http://code.google.com/p/mulder/downloads/detail?name=libx264-112-r1884M-win32.7z&can=2&q=)
libx264 SVN-r1884 complete "all-in-one" library pack (mirror #2) (http://www.mediafire.com/file/ufo07665n02flny/libx264-112-r1884M-win32.7z)


These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r6854 (http://forum.doom9.org/showpost.php?p=1466619&postcount=1602) or later now!

r1884 includes a hot-fix for a regression introduced with r1881. Update is highly recommended!

[Romario]

Lord_Mulder,please,can you persuade Gruntster to compile newest revosion of Avidemux 2.54 ? With x264 1913 revision,of course.

[LoRd_MuldeR]

Lord_Mulder,please,can you persuade Gruntster to compile newest revosion of Avidemux 2.54 ? With x264 1913 revision,of course.

I will make new x264 builds soon. No need to make new Avidemux builds, nothing has happened since the last build (in the 2.4 branch).

[Romario]

Well,ok,but still,it's very very long time since previous 2.54 build. Can you,also,please,compile x264 builds for 64-bit ? Thank you.

[LoRd_MuldeR]

Well,ok,but still,it's very very long time since previous 2.54 build.

It doesn't make sense to create new builds, if nothing has changed.

Currently most (if not all) effort is going into Avidemux 2.6 series and there are "nightly" builds at the well known location.

Can you,also,please,compile x264 builds for 64-bit ? Thank you.

As said earlier, I'm currently not interested in making any 64-Bit builds... :o

[LoRd_MuldeR]

libx264 SVN-r1913:

libx264-r1913, MinGW GCC 4.5.2, optimized for Core 2 (http://www.mediafire.com/file/6dhmx3e34zyanc8/libx264-112-r1913M-gcc452-core2-fprofiled.7z)
libx264-r1913, MinGW GCC 4.5.2, optimized for K10 (http://www.mediafire.com/file/b2j2d4t7serp219/libx264-112-r1913M-gcc452-amdfam10-fprofiled.7z)
libx264-r1913, MinGW GCC 4.5.2, optimized for Pentium III (http://www.mediafire.com/file/63derqiajd7ds6b/libx264-112-r1913M-gcc452-pentium3-fprofiled.7z)
libx264-r1913, MinGW GCC 4.5.2, generic build (http://www.mediafire.com/file/ji89bop4dw4t38k/libx264-112-r1913M-gcc452-i686-fprofiled.7z)
libx264-r1913, MinGW GCC 4.5.2, without ASM (slow!) (http://www.mediafire.com/file/7u91p682rpw4v2j/libx264-112-r1913M-gcc452-noasm-fprofiled.7z)

libx264-r1913, MinGW GCC 4.4.5, optimized for Core 2 (http://www.mediafire.com/file/z9apfysxawsovfd/libx264-112-r1913M-gcc445-core2-fprofiled.7z)
libx264-r1913, MinGW GCC 4.4.5, optimized for K10 (http://www.mediafire.com/file/aduc4ik9qd9e3jr/libx264-112-r1913M-gcc445-amdfam10-fprofiled.7z)
libx264-r1913, MinGW GCC 4.4.5, optimized for Pentium III (http://www.mediafire.com/file/jdw716x82hm7d46/libx264-112-r1913M-gcc445-pentium3-fprofiled.7z)
libx264-r1913, MinGW GCC 4.4.5, generic build (http://www.mediafire.com/file/r1w4n84dgsxmhst/libx264-112-r1913M-gcc445-i686-fprofiled.7z)
libx264-r1913, MinGW GCC 4.4.5, without ASM (slow!) (http://www.mediafire.com/file/n05nndm1dn7tvg3/libx264-112-r1913M-gcc445-noasm-fprofiled.7z)

libx264-r1913, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/23b6q966pgong8f/libx264-112-r1913M-gcc460-core2-fprofiled.7z)
libx264-r1913, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/sci7vsry8sb4200/libx264-112-r1913M-gcc460-amdfam10-fprofiled.7z)
libx264-r1913, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/4352ta44mwtzsrf/libx264-112-r1913M-gcc460-pentium3-fprofiled.7z)
libx264-r1913, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/uray1jeo2l522uv/libx264-112-r1913M-gcc460-i686-fprofiled.7z)
libx264-r1913, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/k8xur5zod8vqe23/libx264-112-r1913M-gcc460-noasm-fprofiled.7z)

libx264-r1913, MinGW GCC 4.5.1, legacy build (http://www.mediafire.com/file/dt2mtk7q850oz6z/libx264-112-r1913M-gcc451-i686-fprofiled.7z)
libx264-r1913, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/h0g2hnr110cptc3/libx264-112-r1913M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1913 library pack:

libx264 SVN-r1913 complete "all-in-one" library pack (mirror #1) (http://code.google.com/p/mulder/downloads/detail?name=libx264-112-r1913M-win32.7z&can=2&q=)
libx264 SVN-r1913 complete "all-in-one" library pack (mirror #2) (http://www.mediafire.com/file/4470hcjtcc6us6i/libx264-112-r1913M-win32.7z)


These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r6854 (http://forum.doom9.org/showpost.php?p=1466619&postcount=1602) or later now!

[LoRd_MuldeR]

libx264 SVN-r1924:

libx264-r1924, MinGW GCC 4.5.2, optimized for Core 2 (http://www.mediafire.com/file/inax83px6nbaah3/libx264-112-r1924M-gcc452-core2-fprofiled.7z)
libx264-r1924, MinGW GCC 4.5.2, optimized for K10 (http://www.mediafire.com/file/pyv52e48hxh5fuk/libx264-112-r1924M-gcc452-amdfam10-fprofiled.7z)
libx264-r1924, MinGW GCC 4.5.2, optimized for Pentium III (http://www.mediafire.com/file/2i68xl55lrmn1yh/libx264-112-r1924M-gcc452-pentium3-fprofiled.7z)
libx264-r1924, MinGW GCC 4.5.2, generic build (http://www.mediafire.com/file/2tbjifl4ymk1kid/libx264-112-r1924M-gcc452-i686-fprofiled.7z)
libx264-r1924, MinGW GCC 4.5.2, without ASM (slow!) (http://www.mediafire.com/file/l0a3rl1632o4pa6/libx264-112-r1924M-gcc452-noasm-fprofiled.7z)

libx264-r1924, MinGW GCC 4.4.5, optimized for Core 2 (http://www.mediafire.com/file/q6ur3981h71decy/libx264-112-r1924M-gcc445-core2-fprofiled.7z)
libx264-r1924, MinGW GCC 4.4.5, optimized for K10 (http://www.mediafire.com/file/8p3di7u3a5h00am/libx264-112-r1924M-gcc445-amdfam10-fprofiled.7z)
libx264-r1924, MinGW GCC 4.4.5, optimized for Pentium III (http://www.mediafire.com/file/nbzkfzwvwdj3p96/libx264-112-r1924M-gcc445-pentium3-fprofiled.7z)
libx264-r1924, MinGW GCC 4.4.5, generic build (http://www.mediafire.com/file/hfaolcqxed2s5k0/libx264-112-r1924M-gcc445-i686-fprofiled.7z)
libx264-r1924, MinGW GCC 4.4.5, without ASM (slow!) (http://www.mediafire.com/file/jvk1mxfv4h6uqg4/libx264-112-r1924M-gcc445-noasm-fprofiled.7z)

libx264-r1924, MinGW GCC 4.6.0, optimized for Core 2 (http://www.mediafire.com/file/naraw8bdq3thxmg/libx264-112-r1924M-gcc460-core2-fprofiled.7z)
libx264-r1924, MinGW GCC 4.6.0, optimized for K10 (http://www.mediafire.com/file/cihrw6qc8bo81ap/libx264-112-r1924M-gcc460-amdfam10-fprofiled.7z)
libx264-r1924, MinGW GCC 4.6.0, optimized for Pentium III (http://www.mediafire.com/file/vbbb8tanvn39be3/libx264-112-r1924M-gcc460-pentium3-fprofiled.7z)
libx264-r1924, MinGW GCC 4.6.0, generic build (http://www.mediafire.com/file/en1j4eizgo4kfyd/libx264-112-r1924M-gcc460-i686-fprofiled.7z)
libx264-r1924, MinGW GCC 4.6.0, without ASM (slow!) (http://www.mediafire.com/file/zgb82da63tmyolt/libx264-112-r1924M-gcc460-noasm-fprofiled.7z)

libx264-r1924, MinGW GCC 4.5.1, legacy build (http://www.mediafire.com/file/s40yz5s8htfe2j6/libx264-112-r1924M-gcc451-i686-fprofiled.7z)
libx264-r1924, MinGW GCC 3.4.5, legacy build (http://www.mediafire.com/file/nqh6xnnjwz2ax8q/libx264-112-r1924M-gcc345-i686-fprofiled.7z)


libx264 SVN-r1924 library pack:

libx264 SVN-r1924 complete "all-in-one" library pack (mirror #1) (http://code.google.com/p/mulder/downloads/detail?name=libx264-112-r1924M-win32.7z&can=2&q=)
libx264 SVN-r1924 complete "all-in-one" library pack (mirror #2) (http://www.mediafire.com/file/2xw6dbdn90dg023/libx264-112-r1924M-win32.7z)


These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r6854 (http://forum.doom9.org/showpost.php?p=1466619&postcount=1602) or later now!

[Romario]

Thanks. But,I know that I am little boring....but still i have one tricky question for you, LoRd_MuldeR.

When somebody (if not you,eventually) will compile x64 builds of libx264 for Avidemux ? Because I use x64 version of Avidemux 2.54 r6854.

[boyumeow]

Yohoo LM, do U have any free time to compile ur version of libx264 since there is new Avidemux 2.5.4 r7194 out too. Thanks in advance, even U do not have time for it too. Thanks.

[LoRd_MuldeR]

Yohoo LM, do U have any free time to compile ur version of libx264 since there is new Avidemux 2.5.4 r7194 out too. Thanks in advance, even U do not have time for it too. Thanks.

Actually I'm getting tired to patch the latest x264 to make it work with the outdated API version that Avidemux 2.5.4 expects.

So I will probably not make any new builds, until a fresh Avidemux build with latest (or at least more recent) x264 API becomes available.

Unfortunately it seems Gruntster hasn't done any work to Avidemux since around November last year...

[boyumeow]

...
Unfortunately it seems Gruntster hasn't done any work to Avidemux since around November last year...

I dun quite understand what U mean by it, but it's not important. Btw, I saw that the change log has specified this

6853 - 20 Dec 2010 - gruntster - [x264] psy trellis and autovaq patch by lord mulder

So does that mean that your special build here is targeted more on cpu core performance? (I think I miss this part :p)

:thanks:

[LoRd_MuldeR]

The problem here is that the programming interface (API) of x264 changes, as the development proceeds. New options are added, deprecated ones are removed.

Consequently applications that want to use latest x264 need to be updated. They need, at least, to be re-compiled from the sources with the latest x264 header file.

If the application actually wants to make use of the latest x264 features/options, then more code changes will be required on the application's side, of course.

The last Avidemux 2.5.4 build for Win32 was made on 1st Nov 2010. Since then the x264 API has changed multiple times and thus it won't work with an up-to-date x264.

I can, of course, try to cripple x264 in order to make it work with that old Avidemux build (in fact I did that frequently in the past), but at some point it gets annoying.

Therefore I will simply wait for Gruntster to re-appear and make a new Avidemux build, which then can work with latest x264 without workarounds/modifications...

(BTW: If you look at the Avidemux changelog, you will see a lot of activity, but it's all in the 2.6 branch. The 2.5.x branch hasn't seen any updates for quite some time)


[UPDATE]

I just checked again. And indeed there finally is a new Avidemux 2.5.4 build from 8th May 2011 (http://avidemux.razorbyte.com.au/#avidemux2.5). So the problem described above should be solved - for now :)

So unless an unexpected problem pops up, I will make new libx264 builds for Avidemux soon...

[LoRd_MuldeR]

Avidemux 2.5.4 r7194 (2011-05-08)
http://www.avidemux.org/

Revision 7194 (08 May 2011)
Compiled with GCC 4.5.2
Updated Freetype to version 2.4.4-1.
Updated GLib to version 2.28.1-1.
Updated libvpx to version 0.9.6.
Updated NSPR to version 4.8.8.
Updated Pango to version 1.28.1-3.
Updated Qt to version 4.7.3.
Updated x264 to r1947.
Updated Xvid to version 1.3.1.

7169 - [xvid: gcc 46]
7166 - [save] be more verbose when failing, patch by JaLee
7165 - [build] Fix right of lav libraries to be not executable, patch from rpmfusion
7164 - [qt4] gcc 4.6 fix
7163 - [qt4] gcc 4.6 fix
7125 - [x264] Add field order checkbox in gtk x264 dialog instead default bottom field first
7096 - [avsfilter] Fix load avsfilter from .js script
7077 - [i18n] Ca translation update by Joan Farrerons
7037 - [Qt] Append patch by Valerian_24
7017 - [i18n] hu translation by alaci
6992 - [codec] Merge jaLee patch to select video codec from cli
6974 - [ffmpeg] Revert to older version we have still locally
6953 - [mov] Partial support for hdv5 (incomplete), ref #118
6906 - [x264] support min and max quantiser > 10
6855 - [mkv] When no channels, default is mono not stereo, fix #115

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://code.google.com/p/mulder/downloads/detail?name=Avidemux.2011-05-08.Win32.exe&can=2&q=)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[Super Nik]

I don't know if this is the right topic, but I have a problem with this program: I can't add .srt subtitle to an mp4 file...
I exlpain better: I have my mp4 file, I select mp4 (xvid) under "Video", I select Filters, then I add the subs, I select "Copy" under "Audio" and I select MP4 under "Format", then I save the video and the process starts, but when it ends, I find a file whitout extension, with the description of "file"... It isn't an mp4 and it isn't playable in any way...
Where am I mistaking?

[parsifal]

Sadly, Avidemux does not automatically add a file extension if you omit to do this yourself in the "Save As" dialog. For now, just rename the file and add an .mp4 extension (since you chose MP4 as the output container format).

For all future endeavors, just remember to include a specific extension when entering the desired output filename. For example, "output.mp4" instead of just "output". Also, no arbitrary extensions, the extension used should reflect the chosen output container: .avi for AVI container, .mkv for MKV container, .mpg for MPEG-PS and so on.

[Super Nik]

Sadly, Avidemux does not automatically add a file extension if you omit to do this yourself in the "Save As" dialog. For now, just rename the file and add an .mp4 extension (since you chose MP4 as the output container format).

For all future endeavors, just remember to include a specific extension when entering the desired output filename. For example, "output.mp4" instead of just "output". Also, no arbitrary extensions, the extension used should reflect the chosen output container: .avi for AVI container, .mkv for MKV container, .mpg for MPEG-PS and so on.
Aaaahh! :rolleyes:
There was so simple? Lol!
Honestly I'd have never thought this! Thank you very much for the info! ;)

[boyumeow]

Hold Your breath, there is new 2.5.4 r7200 out now.
Hold Your breath longer, there is a great change log for x264 too, which I think is not include in r7200 yet.
Thanks.

[LoRd_MuldeR]

Hold Your breath, there is new 2.5.4 r7200 out now.

As far as I can see, that's only a quick fix for some problem with the previous x64 build.

Hold Your breath longer, there is a great change log for x264 too, which I think is not include in r7200 yet.
Thanks.

1. There have been a lot of changes to interlaced encoding. The "MBAFF" (Macro Block Adaptive Frame/Field Coding) support was much improved.

2. If you encode a lot of interlaced footage, this might be great. But if you encode progressive footage (which includes deinterlaced footage) it does not make any difference.

3. The x264 API didn't change. It's still at core-115. So it should work with Avidemux r7194/r7200 just fine without any modification.

[LoRd_MuldeR]

libx264 SVN-r1995:

libx264-r1995, MinGW GCC 4.5.3, optimized for Core 2 (http://www.mediafire.com/file/4i4f2qricqgi58l/libx264-115-r1995M-gcc453-core2-fprofiled.7z)
libx264-r1995, MinGW GCC 4.5.3, optimized for K10 (http://www.mediafire.com/file/hxn3vlc3lbkr4o0/libx264-115-r1995M-gcc453-amdfam10-fprofiled.7z)
libx264-r1995, MinGW GCC 4.5.3, optimized for Pentium III (http://www.mediafire.com/file/r23zcbpbpnzf7zu/libx264-115-r1995M-gcc453-pentium3-fprofiled.7z)
libx264-r1995, MinGW GCC 4.5.3, generic build (http://www.mediafire.com/file/yc80uhk309c00k6/libx264-115-r1995M-gcc453-i686-fprofiled.7z)
libx264-r1995, MinGW GCC 4.5.3, without ASM (slow!) (http://www.mediafire.com/file/35ng4v2wca62p8s/libx264-115-r1995M-gcc453-noasm-fprofiled.7z)
(Click here for the complete list) (http://www.mediafire.com/?v72bu6v7845hi)


libx264 SVN-r1995 library pack:

libx264 SVN-r1995 complete "all-in-one" library pack (mirror #1) (http://code.google.com/p/mulder/downloads/detail?name=libx264-115-r1995M-win32.7z&can=2&q=)
libx264 SVN-r1995 complete "all-in-one" library pack (mirror #2) (http://www.mediafire.com/file/p38fw8al4858io4/libx264-115-r1995M-win32.7z)


These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r7194 (http://forum.doom9.org/showpost.php?p=1499718&postcount=1631) or later now!

Better late than never, I guess :)

[boyumeow]

Thanks You very much, hehe :D.

Errr, having error downloading the single file for core-2 at mediafire, just thought to let U know. Anyhow, I use the mirror to download. Thanks again.

[LoRd_MuldeR]

Avidemux 2.5.4 r7296 (2011-06-19)
http://www.avidemux.org/

Revision 7296 (19 Jun 2011)
# Compiled with GCC 4.6.1 pre-release (20110618)
# Updated x264 to r2008.
# Updated Xvid to version 1.3.2.

7296 - [mswin] fix 32-bit backtrace to work with recent compilers and add 64-bit backtrace support
7295 - [log] separate files for backtrace by platform
7292 - [mswin] gcc 4.6 fix (GPF on startup)
7291 - [mswin] gcc 4.6 fix
7290 - [mswin] gcc 4.6 fix
7289 - [mswin] update build scripts
7288 - [x264] support core version 115
7287 - [lavc] fix libavcodec based audio encoders (patch by mean)
7244 - [videoCodec] Update multithreading handling with newer lavcodec, backport from 2.6
7243 - [mpegaudio layer2] merge fix from 2.6
7200 - [ffmpeg] remove previous ffmpeg source
7199 - [ffmpeg] roll ffmpeg forward again so win64 works properly (0.7rc1)

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://code.google.com/p/mulder/downloads/detail?name=Avidemux.2011-06-19.Win32.exe)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

libx264 SVN-r2008:

libx264-r2008, MinGW GCC 4.5.3, optimized for Core 2 (http://www.mediafire.com/file/s9u3bfj5ee8sml5/libx264-115-r2008M-gcc453-core2-fprofiled.7z)
libx264-r2008, MinGW GCC 4.5.3, optimized for K10 (http://www.mediafire.com/file/nuqpvpqxlz1timl/libx264-115-r2008M-gcc453-amdfam10-fprofiled.7z)
libx264-r2008, MinGW GCC 4.5.3, optimized for Pentium III (http://www.mediafire.com/file/391cic7nxqcr7fs/libx264-115-r2008M-gcc453-pentium3-fprofiled.7z)
libx264-r2008, MinGW GCC 4.5.3, generic build (http://www.mediafire.com/file/wecz4zuxxo02uog/libx264-115-r2008M-gcc453-i686-fprofiled.7z)
libx264-r2008, MinGW GCC 4.5.3, without ASM (slow!) (http://www.mediafire.com/file/i8zip28f7k8ay3h/libx264-115-r2008M-gcc453-noasm-fprofiled.7z)
(Click here for the complete list) (http://www.mediafire.com/?wwf7559804300)


libx264 SVN-r2008 library pack:

libx264 SVN-r2008 complete "all-in-one" library pack (mirror #1) (http://code.google.com/p/mulder/downloads/detail?name=libx264-115-r2008M-win32.7z&can=2&q=)
libx264 SVN-r2008 complete "all-in-one" library pack (mirror #2) (http://www.mediafire.com/file/sb942g4mfzrkl4k/libx264-115-r2008M-win32.7z)


These builds will NOT work with Avidemux 2.5.3 or older. Please update to Avidemux 2.5.4 r7296 (http://forum.doom9.org/showpost.php?p=1509665&postcount=1639) or later now!

[Brazil2]

libx264 SVN-r2008 library pack:
libx264 SVN-r2008 complete "all-in-one" library pack (mirror #1) (http://code.google.com/p/mulder/downloads/detail?name=libx264-115-r2008M-win32.7z&can=2&q=)

Is it normal that x264.exe from libx264-115-r2008M-gcc453-core2-fprofiled is 7.19 MB (almost the same as the gcc446-core2-fprofiled build) but the one from libx264-115-r2008M-gcc460-core2-fprofiled is only 891 KB ? What is the difference ?

[LoRd_MuldeR]

Is it normal that x264.exe from libx264-115-r2008M-gcc453-core2-fprofiled is 7.19 MB (almost the same as the gcc446-core2-fprofiled build) but the one from libx264-115-r2008M-gcc460-core2-fprofiled is only 891 KB ? What is the difference ?

Yes, it's perfectly normal:

If x264 was built with libav/ffms2 enabled, then the binary will be much bigger than without. As you may have noticed, not all of my builds are built with libav/ffms2 though.

Last but not least, for the x264 DLL file (which, for example, can be used with Avidemux) there's no such difference...

[katzenjoghurt]

Hm hm hm... I'm looking and looking and looking...

Where may I find x264's deblocking option in Avidemux?
(I'd like to reduce it)

[LoRd_MuldeR]

Hm hm hm... I'm looking and looking and looking...

Where may I find x264's deblocking option in Avidemux?
(I'd like to reduce it)

In the x264 configuration dialog, on the "Frame" tab ;)

(What you want to adjust are the "Loop Filter" strength and/or threshold)

[katzenjoghurt]

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!

[LoRd_MuldeR]

Woohoo! And after deactivating the additional deblocking in the postprocessing tab
the output finally looks like the input. :)

The "Postprocessing" is applied after the source video has been decoded, but before the video is forwarded to the encoder. And this is always a trade-off: You get reduced "blocking" or "ringing" at the cost of reduced sharpness/detail! IMO you should never use Postprocessing, except for "low quality" sources.

(The purpose of the x264 Loop Filter is completely different: It's purpose is to avoid "new" blocking artifacts introduced by the H.264 encoding. It's purpose is NOT to remove "old" blocking artifacts that already were in the source video!)

[katzenjoghurt]

Odd that it's activated by default then, isn't it?

I'm pretty new to avidemux. So I'm not belonging
to the ones used to the features as they are and
not liking any changes. :D

So of course I'm wondering...
If I convert something, then I expect the output
to come out pretty much like the input.

If I know the input is bad I myself start tweaking
and using filters.

Not the other way around. :confused:


I think most users don't like it when machines
start to think for them. :)


edit: Hm. I just see that it was only activated in
the current svn version I took from gruntster.

In the official release it's deactivated by default.
Maybe it's just build related I stumbled over this.

[LoRd_MuldeR]

What do you mean with "official release" versions? AFAIK all the Avidemux 2.5.x releases for Win32 are made by Gruntster.

The default for Postprocessing may have changed in the upcoming Avidemux 2.6 series though. And I agree that it should be disabled by default.

[katzenjoghurt]

I considered r7200 to be official
http://avidemux.berlios.de/download.html

and r7296 (I took as 64bit built) to be "unofficial" svn builds.
http://avidemux.razorbyte.com.au/

I really can't remember having checked those postprocessing
deblocking filters myself. Stumbled over them after I wondered
why everything's so blurry.

Then I checked r7200 (32bit) I've also installed and there those
were deactivated.

[LoRd_MuldeR]

Avidemux 2.5.4 r7317 (2011-07-10)
http://www.avidemux.org/

Revision 7317 (10 Jul 2011)
Compiled with GCC 4.6.1.
Updated x264 to r2019.

7317 - [qt] support audio drag and drop
7309 - [qt] don't block source application after drag and drop
7299 - [ffmpeg] upgrade ffmpeg to 0.8

Download Mirror #1: http://mulder.googlecode.com/ (http://code.google.com/p/mulder/downloads/detail?name=Avidemux.2011-07-10.Win32.exe&can=2&q=)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

[LoRd_MuldeR]

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]

Dear LoRd_MuldeR, please update libx264 with build 2037. :)

[LoRd_MuldeR]

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]

Ohh, ok ok, I understand. But I don't understand, what Sub-ME 11 brings to us ? Quality improvments or speed ?

[LoRd_MuldeR]

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]

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]

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]

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]

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]

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]

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]

BTW: You can change the default setting for the "Post-Processing" filter in the Avidemux preferences.

[Cornelis]

Thanks I will do it!

[LoRd_MuldeR]

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]

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]

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]

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]

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]

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]

I get an "error while coding" pop-up (r7296 version, the same happens with the latest version posted above)

[LoRd_MuldeR]

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]

Your algorithm sounds great. Thank you as usual. ;)

[LoRd_MuldeR]

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]

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]

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]

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]

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]

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]

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]

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]

Any way to do a 7/8hours x264 1st pass encoding, and than do the 2nd pass encoding the next day?

[LoRd_MuldeR]

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]

Thanks, I'll do a couple of short tests using the stats file created after the 1st pass. :)

[Pulstar]

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]

Probably bottlenecked by slow input or slow filters...

[Pulstar]

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]

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]

Thanks for the clarification. :)

[LoRd_MuldeR]

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]

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]

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]

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]

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]

Thanks again for taking the time to clear the picture. GPU processing has been receiving a lot of hype recently.

[LoRd_MuldeR]

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]

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]

You should probably update to r2120.

[LoRd_MuldeR]

You should probably update to r2120.

Argh. Will do tomorrow. Added a warning for now ;)

[Dark Shikari]

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]

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!

[LoRd_MuldeR]

Avidemux 2.5.6 Final (2011-12-29)
http://www.avidemux.org/

What's New in Avidemux 2.5.6
• Restored AC3 and MP2 encoding (regression introduced 2.5.5)
• Added support for latest x264 core
• Updated the FFmpeg libraries (version 0.9)
• Drag-and-drop no longer blocks source application for Qt interface
• Resolved Windows XP 32-bit stability issues (regression introduced 2.5.5)
• Windows 7 taskbar now displays encoding progress
• Improved crash reporting on Windows especially Win64
• Compilation fixes for OS X Snow Leopard and Lion
• Various minor fixes and enhancements

Revision 7716 [2.5.6 Final] (29 Dec 2011)
• Updated Qt to version 4.8.0.
• Updated x264 to r2120.

7714 - [apple] fix r7712
7713 - [ac3] ffmpeg ac3 encoding is broken because the default encoder expects floats. Explicitly use 16-bit encoder instead since that's what we're feeding it.
7712 - [apple] use a more elegant workaround for compilation errors rather than disabling optimisations
7702 - [UI] Keyboard shortcuts for saving images
7700 - [build] fix common.mak.diff with newer ffmpeg
7699 - [ffmpeg] upgrade ffmpeg to 0.9

Download Mirror #1: http://mulder.googlecode.com/ (http://code.google.com/p/mulder/downloads/detail?name=Avidemux.2011-12-29.Win32.Final.exe&can=2&q=)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#download)

[Superb]

http://i.imgur.com/dt93H.png

[LoRd_MuldeR]

http://i.imgur.com/dt93H.png

Fixed ;)

[LoRd_MuldeR]

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-120-r2120M-win32.7z&can=2&q=)
libx264 SVN-r2120 complete "all-in-one" library pack (mirror #2) (http://www.mediafire.com/file/p8tbxf89irs66wl/libx264-120-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.

commit 0637cd67cb245fce5ba190fa4b9c341319ea2b37 r2119
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 r2118
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 r2117
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 r2116
Author: Kieran Kunhya <kieran@kunhya.com>
Date: Fri Nov 4 20:09:13 2011 +0000

Pass through user data

commit 04a0aeefd2f5b152c5dbca4a1c6569bd27c9f721 r2115
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Thu Oct 27 14:05:56 2011 -0700

Remove unpredictable branch in CABAC dqp

commit 4185ee883b04d9cee57a64fdebd153830b7b27ba r2114
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 r2113
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 r2112
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 r2111
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 r2110
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Sat Nov 12 00:47:48 2011 +0400

Mark some local functions as static, cosmetics

commit e0c11dc6e283569606aaa97767401c6a13c2529d r2109
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Fri Nov 11 23:19:02 2011 +0400

Fix crash if timecode file opening fails

commit a14db080c3fdba4cadc38152a292bb1fa216d50e r2108
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 r2107
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 r2106
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.5 or older. Please update to Avidemux 2.5.6 r7716 (http://forum.doom9.org/showpost.php?p=1548105&postcount=1701) or later now!

[dado023]

nicely done.....new gift for us all in this new year.....@all happy new year:D

[manolito]

For me the latest working version of Avidemux is avidemux_2.5_r7317_win32.exe.

All later versions like 2.54 final, 2.56 final and 2.6 simply refuse to start. No error message whatsoever, the "admlog.txt" file is much shorter for the newer (not working) versions than the one for the old (working) version.

The following part is missing for the newer versions:
Registered DialogFactory classes
Spidermonkey initialized.

[Locale] Locale: de_DE
[Locale] Loading language file E:/Programme/Avidemux/i18n/avidemux_de_DE succeeded
[Locale] Loading language file E:/Programme/Avidemux/i18n/qt_de_DE succeeded
[Locale] Test: &Edit -> &Bearbeiten

Directory E:\Dokumente und Einstellungen\Achim\Anwendungsdaten\avidemux\custom\ exists.Good.
No custom scripts
Custom menu built
The screen seems to be 1024 x 740 px
Found 17 video encoder(s)
Found 9 audio encoder(s)
Found 13 format(s)
No crash file (E:\Dokumente und Einstellungen\Achim\Anwendungsdaten\avidemux/crash.js)
Deleting post proc
[RDR] Resizing to 0 x 0
Cleaning up
Waiting for Spidermonkey to finish...
Cleaning up Spidermonkey.
End of cleanup

Images stat:
___________
Max memory consumed (MB) : 0
Current memory consumed (MB) : 0
Max image used : 0
Cur image used : 0
Global mem stat
______________
Memory consumed: 0 (MB)

Goodbye...

Alright, my computer is ancient and slow, but I see no reason why Avidemux should not run on it.

Specs:
Intel Celeron 1.1 Gigabyte Coppermine
576 MB RAM
ATI Rage Pro Turbo, runs DirectX 9
WinXP Pro SP3, all current updates

System partition is FAT32, data are on a NTFS partition.


Any ideas what I could do to run the current Avidemux versions?


Cheers
manolito

[LoRd_MuldeR]

Did you try clean re-install rather than installing "over" the old version?

Also, when it crashes and you look at the log file right after it crashed (do not restart the app!), are there any information that indicate what went wrong?

If not, I would suggest to load up a debugger (e.g. GDB) and make a stacktrace when Avidemux crashes on your system...

[CruNcher]

hmm drag and droping specific.asf .wmv streams causes avidemux 2.5/2.6 to crash (first no response) then white window and after click it shows the NT6 application hang dialog, or on some files huge ones it can parse correct the first time it takes very long to get back to respond without showing whats happening (indexing ?) maybe a progress bar or at least a please wait instead of no response would be better ? (you could think it crashed this way ;) )

In general .wmv .asf support looks very unstable, if you get a stream to open it crashes @ playback very strange though 2.6 seems more crashy in those regards then 2.5 which @ least works for some and doesn't crash @ playback if it has successfully opened it

Also the function that if you drag & drop on a already opened stream by default is trying to append the dragged file instead of opening the new one seems a little strange without a timeline (maybe forcing different states via a configurable key combination would be a good idea, and by default just open the new one though as being a little bit more editor then player i can understand the default being append but without a timeline it feels odd ;) )

Ehh what happened to the Audio selection (none audio track) in 2.6, there is no option for no audio track anymore ?

[LoRd_MuldeR]

Try Avisynth-input with DirectShowSource() or DSS2() for reading WMV files.

[flapane]

Avidemux 2.5.6 Final (2011-12-29)
http://www.avidemux.org/


I used to download win32 GTK version at http://avidemux.razorbyte.com.au/binaries/2.5/
Did you drop win32 GTK support or is it just me who doesn't know where to find it?
Thanks

edit: I found the final version at http://avidemux.razorbyte.com.au/milestone/2.5.6%20%287716%29/
It would be great to have a win32 gtk build of Avidemux 2.6 svn, too.

[LoRd_MuldeR]

The GTK+ UI has been dropped from active development long ago. For Windows you definitely want to use the Qt-based UI nowadays.

I think the only reason why the "old" GTK+ UI has not been removed completely is because some Linux users may prefer GTK+ over Qt, because their Linux distribution is Gnome/GTK+-based and they don't want to install the Qt packages.

For Windows this issue does not exist, because Windows neither ships with Qt nor with GTK+ libraries. On Windows, Avidemux always uses it's private Qt (or GTK+) DLL's inside its install folder...

[flapane]

It's just a matter of habit, I always preferred GTK+ style over Qt. If I'll be forced to use QT, then I'll use it.
Just in case, what if I paste C:\Program Files (x86)\Avidemux 2.5\lib\gtk-2.0 folder inside a newer 2.6 Qt build of Avidemux?
Thanks

[LoRd_MuldeR]

It's just a matter of habit, I always preferred GTK+ style over Qt. If I'll be forced to use QT, then I'll use it.

Yes, please use the Qt-based GUI of Avidemux. Actually you should be doing so for quite some time already...

Just in case, what if I paste C:\Program Files (x86)\Avidemux 2.5\lib\gtk-2.0 folder inside a newer 2.6 Qt build of Avidemux?

... nothing happens ... except that you now have a bunch of unused files in your Avidemux folder :confused:

[boyumeow]

Hi LM, I'm getting crash (when I press "B" button) or crash-like problem with Mpeg-4 Visual(XviD) file in Matroska container, admlog did log a lot of "wrong marker" message, with avidemux 2.5.6.7716 version. Putting the file in avi container was alright and doing fine.

Avidemux 2.6.7719 was doing good with it too.

Hope U could understand what I'm trying to tell. Thanks.

[LoRd_MuldeR]

libx264 SVN-r2146 library pack:

libx264 SVN-r2146 complete "all-in-one" library pack (mirror #1) (http://code.google.com/p/mulder/downloads/detail?name=libx264-120-r2146M-win32.7z&can=2&q=)
libx264 SVN-r2146 complete "all-in-one" library pack (mirror #2) (http://www.mediafire.com/file/i7c0x9si1du2skv/libx264-120-r2146M-win32.7z)


Changelog:
commit bcd41dbcaa4430b2118d9f6828c2b9635cf9d58d r2146
Author: Loren Merritt <pengvado@akuvian.org>
Date: Wed Jan 18 15:47:07 2012 -0800

Fix trellis 2 + subme >= 8
Trellis didn't return a boolean value as it was supposed to.
Regression in r2143-5.

commit 748fe16c1303b89d2a1d0378addd83fb4198f51a r2145
Author: Loren Merritt <pengvado@akuvian.org>
Date: Fri Jan 6 15:53:29 2012 +0000

CABAC trellis opts part 4: x86_64 asm
Another 20% faster.
18k->12k codesize.

This patch series may have a large impact on encoding speed.
For example, 24% faster at --preset slower --crf 23 with 720p parkjoy.
Overall speed increase is proportional to the cost of trellis (which is proportional to bitrate, and much more with --trellis 2).

commit cfdb36ece729209631f7213506685ae733d7f5d4 r2144
Author: Loren Merritt <pengvado@akuvian.org>
Date: Fri Jan 6 15:53:04 2012 +0000

CABAC trellis opts part 3: make some arrays non-static

commit 65bd12ae875a768a06b67ec6297dec18323e0768 r2143
Author: Loren Merritt <pengvado@akuvian.org>
Date: Thu Dec 22 17:56:06 2011 +0000

CABAC trellis opts part 2: C optimizations

Hoist the branch on coef value out of the loop over node contexts.
Special cases for each possible coef value (0,1,n).
Special case for dc-only blocks.
Template the main loop for two common subsets of nodes, to avoid a bunch of branches about which nodes are live.
Use the nonupdating version of cabac_size_decision in more cases, and omit those bins from the node struct.
CABAC offsets are now compile-time constants.
Change TRELLIS_SCORE_MAX from a specific constant to anything negative, which is cheaper to test.
Remove dct_weight2_zigzag[], since trellis has to lookup zigzag[] anyway.

60% faster on x86_64.
25k->18k codesize.

commit e176619d010fc32c970c7ab7a769bbfbe2665f61 r2142
Author: Loren Merritt <pengvado@akuvian.org>
Date: Thu Dec 22 17:55:06 2011 +0000

CABAC trellis opts part 1: minor change in output
Due to different tie-break order.

commit 4e87f36a0e1a78242f04db611e06f80b6b38d900 r2141
Author: Henrik Gramner <hengar-6@student.ltu.se>
Date: Sun Jan 8 04:14:10 2012 +0100

x86inc improvements for 64-bit

Add support for all x86-64 registers
Prefer caller-saved register over callee-saved on WIN64
Support up to 15 function arguments

commit 84a06e611aff1267a720bf9552b3bcf263bd83b5 r2140
Author: Ilia Valiakhmetov <zakne0ne@gmail.com>
Date: Sun Jan 15 04:47:58 2012 -0600

High bit depth SSE2/AVX add8x8_idct8 and add16x16_idct8
From Google Code-In.

commit c605e3174410ba5c7d1d0a777082e2397734d637 r2139
Author: Edward Wang <edward.c.wang@compdigitec.com>
Date: Wed Jan 4 15:35:54 2012 -0800

MMX/SSE2/AVX predict_8x16_p, high bit depth fdct8
From Google Code-In.

commit 6b06f6d3f7f800dca1a4ea154f54427d5b3cea2b r2138
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Thu Dec 22 14:03:15 2011 -0800

XOP 8-bit fDCT
Use integer MAC for one of the SUMSUB passes. About a dozen cycles faster for 16x16.

commit c4b54c83629bb92af6c4836a8859e9432dc7333a r2137
Author: Cristian Militaru <cristipiticul@yahoo.com>
Date: Wed Jan 4 12:38:08 2012 -0800

High bit depth intra_sad_x3_4x4
From Google Code-In.

commit c032fbaa3801fb4cf8dd1dd95a6479ca5bd262e2 r2136
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Thu Dec 8 13:45:41 2011 -0800

Use a large LUT for CAVLC zero-run bit codes
Helps the most with trellis and RD, but also helps with bitstream writing.
Seems at worst neutral even in the extreme case of a CPU with small L2 cache (e.g. ARM Cortex A8).

commit ebb1429e2d24f57aa4ea75284386a15f2eab553e r2135
Author: Matt Habel <habelinc@gmail.com>
Date: Fri Dec 16 23:16:09 2011 -0800

High bit depth intra_sad_x3_8x8, intra_satd_x3_4x4/8x8c/16x16
Also add an ACCUM macro to handle accumulator-induced add-or-swap more concisely.

commit 6d921c5bdefae1a733a3a4c29d88ea15fcece76e r2134
Author: Shitiz Garg <mail@dragooon.net>
Date: Sat Dec 3 15:34:57 2011 -0800

MMX 10-bit predict_8x8c_h and predict_8x16c_h
From Google Code-In.

commit 47cdaa9c3d8197d4deb711d9bcc4af869ef8a426 r2133
Author: Aaron Schmitz <me@aaronschmitz.com>
Date: Wed Nov 30 00:15:45 2011 -0600

Some MBAFF x86 assembly functions.
deblock_chroma_420_mbaff, plus 422/422_intra_mbaff implemented using existing functions.
From Google Code-In.

commit 027b05e0a22421e477847506a205a49b151ae5bf r2132
Author: George Stephanos <gaf.stephanos@gmail.com>
Date: Thu Dec 1 16:53:45 2011 -0800

More ARM NEON assembly functions
predict_8x8_v, predict_4x4_dc_top, predict_8x8_ddl, predict_8x8_ddr, predict_8x8_vl, predict_8x8_vr, predict_8x8_hd, predict_8x8_hu.
From Google Code-In.

commit 658a3585b74f77fd8f78588f3f39e0abefb104c4 r2131
Author: Ilia <zakne0ne@gmail.com>
Date: Mon Nov 28 05:20:09 2011 -0800

More 4:2:2 asm functions
High bit depth version of deblock_h_chroma_422.
Regular and high bit depth versions of deblock_h_chroma_intra_422.
High bit depth pixel_vsad.
SSE2 high bit depth and MMX 8-bit predict_8x8_vl.
Our first GCI patch this year!

commit 978abe065737089913feccffece483bc69a9e5b0 r2130
Author: Henrik Gramner <hengar-6@student.ltu.se>
Date: Thu Dec 8 16:14:35 2011 +0100

SSE2 and SSSE3 versions of sub8x16_dct_dc
Also slightly faster sub8x8_dct_dc

commit 61a78a1b417595c4b5d7ef6831692904a243a9fc r2129
Author: Steven Walters <kemuri9@gmail.com>
Date: Mon Dec 5 08:46:34 2011 -0500

Resize filter updates
Use AVPixFmtDescriptors to pick the most compatible x264 csp for any pixel format.
Fix deprecated use of av_set_int.
Now requires libavutil >= 51.19.0

commit bc6c98cf4f76c779c8c07f43aa97ac29b1150bc0 r2128
Author: Oka Motofumi <chikuzen.mo@gmail.com>
Date: Thu Jan 5 14:23:50 2012 -0800

Add out-of-tree build support

commit f33c8cb0f8fff7a83100b3e9d15baba53c6f6a35 r2127
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Fri Dec 16 18:17:00 2011 +0400

Limit SSIM to 100db
Avoids floating point error for infinite SSIM (lossless).

commit c0d698859c36be611d465f968762f042853be817 r2126
Author: Reynaldo H. Verdejo Pinochet <reynaldo@collabora.com>
Date: Wed Jan 4 13:16:12 2012 -0300

Fix wrong conditional inclusion of inttypes.h
inttypes.h is required by encoder/ratecontrol.c for SCNxxx macros, and HAVE_STDINT_H does not imply having inttypes.h.
stdint.h is a subset of inttypes.h, but this isn't enough for x264.
This change fixes building x264 with Android's toolchain.

commit b081d179e741ceffee2217f6fda06779693dce56 r2125
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Wed Dec 21 11:08:56 2011 +0400

Fix crash with sliced threads and input height <= 112

commit 64da5f9df46ac33a5a6b56ca1510d2082e6fbb62 r2124
Author: Phillip Blucas <pblucas@gmail.com>
Date: Mon Dec 19 17:43:41 2011 -0600

Fix loading custom 8x8 chroma quant matrices in 4:4:4

commit 4c08e42504af81cdbe5789a309e868ca8eda2c1f r2123
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Fri Dec 16 01:48:07 2011 +0400

Fix PCM cost overflow

commit 489a9b2d04c4828877930d2a9104ce93dde8cb85 r2122
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Fri Dec 9 01:54:22 2011 +0400

Fix overflow in 8-bit x86 vsad asm function

commit c291a9d09263708e9d9f02e28f8442fdbe46bb06 r2121
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Wed Dec 7 19:14:52 2011 +0400

Fix crash in --fullhelp when compiled against recent ffmpeg
Don't assume all pixel formats have a description.

These builds will NOT work with Avidemux 2.5.5 or older. Please update to Avidemux 2.5.6 r7716 (http://forum.doom9.org/showpost.php?p=1548105&postcount=1701) or later now!

[flapane]

I've just switched to a SB cpu, I wonder if coreduo-optimized x264 library will be fine.

Take it with a grain of salt, but switching from a 3.4ghz e5200 to a 3.3ghz i3-2120 brought an amazing 2x to 2.5x encoding speed on 3Mbps 720p files.
The only weird thing is that mediainfo now shows "threads=6" for these files, while it should be "threads=4".

[LoRd_MuldeR]

I've just switched to a SB cpu, I wonder if coreduo-optimized x264 library will be fine.

Indeed, that should be the most suitable build for your CPU. As far as I know, current GCC doesn't even offer optimizations specific for "Core i" processors.

Compiler optimizations don't make a huge difference anyway. At least with a piece of software like x264 that already has hand-optimized assembler code for all performance-critical functions.

So as long as you don't pick a build that has been compiled for an instruction set which is not support by your CPU, everything should be fine.

Take it with a grain of salt, but switching from a 3.4ghz e5200 to a 3.3ghz i3-2120 brought an amazing 2x to 2.5x encoding speed on 3Mbps 720p files.
The only weird thing is that mediainfo now shows "threads=6" for these files, while it should be "threads=4".

Nope, it shouldn't. Unless you overwrite x264's defaults, it will use "threads = 3/2 * number_of_cpu_cores". And that is for a good reason ;)



[CORRECTION]
Indeed, that should be the most suitable build for your CPU. As far as I know, current GCC doesn't even offer optimizations specific for "Core i" processors.

Okay, it seems latest GCC (v4.6.x) added "Core i" specific optimizations. But I cannot make 'fprofiled' builds with such optimizations anyway, as I still use and "old" Core 2 Quad :eek:

[flapane]

I see, thanks for the explanation, then. ;)

[cord-factor]

I have to make video-editing with many MPEG files. But firstly they must be indexed. It is not comfortably to wait of indexing through work. It will be good to make indexes of all files first, and then edit them.
I tried
$ avidemux2_cli --rebuild-index *.mpg
and it returns me
-CUT-

*** Automated : 48 entries*************
rebuild-index-->0
********************************************************************************
* Error *
* No video loaded *
********************************************************************************

Found garbage D.mpg

********** Automation ended***********
*********************************
*********************************
End of program..
*********************************
*********************************
Normal exit

-CUT-

When I opened these files in avidemux GUI, it makes index without any issues. What's wrong?

[LoRd_MuldeR]

Maybe you can't use wildcards in the command. Instead try writing a simple shell script to loop over all files and calls Avidemux once for every file.

[cord-factor]

No, it's the same
http://pastie.org/private/iuc1ywc0bkwhkfcsoxhaba

[LoRd_MuldeR]

After thinking a bit more about your issue, I think you have to use "--index-mpeg" rather than "--rebuild-index".

[cord-factor]

After thinking a bit more about your issue, I think you have to use "--index-mpeg" rather than "--rebuild-index".
heh, 'Unknown command :--index-mpeg'
http://paste.pocoo.org/show/544103/

[the_weirdo]

heh, 'Unknown command :--index-mpeg'
http://paste.pocoo.org/show/544103/

I think your command line should be:
avidemux2_cli D.mpg --rebuild-index

[cord-factor]

I find solution:
$ find ./ -iname '*.mpg' -exec avidemux2_cli {} --rebuild-index \;

[cord-factor]

I find solution:
$ find ./ -iname '*.mpg' -exec avidemux2_cli {} --rebuild-index \;
New issue. How to disable auto-append question?

Question *
* There is several mpeg file, append them ? *
********************************************************************************
Yes or No (Y/y or N/n) :

or do it automatically answer "No"?

[LoRd_MuldeR]

Give each MPEG file a distinct name (i.e. not something like "foobar_XX.mpg" with XX = 01, 02, etc.) and Avidemux won't suggest to append the other parts.

[cord-factor]

Unfortunately, I can't do that. I need sequence.
All right, I will search about bash (auto-answering the boolean questions).

[LoRd_MuldeR]

Crate a temporary copy (or a temporary symlink) that ensures a distinct name ;)

(You can later append the individual segments manually)

[cord-factor]

I found how to auto-answer. Thanks to good people.
$ yes n | find ./ -iname '*.mpg' -exec avidemux2_cli {} --rebuild-index \;

[cord-factor]

LoRd_MuldeR, can you check this HDV file for multi-thread playing?
http://dl.dropbox.com/u/59413997/Birds_HD.m2t (~76mb)
This file is retarding during avidemux play, and the CPU load is about 50% (two core processor). I have tried to change multi-threading option, but no luck :(
Or it is normal for HDV?

[quartex]

trying avidemux 2.6 revision 7740 for win32 comparing with avidemux 2.5.6
I have noticed often time on same frame differs 125ms between 2.6 and 2.5.6 (h264 video)
which one is more accurate?

[LoRd_MuldeR]

LoRd_MuldeR, can you check this HDV file for multi-thread playing?
http://dl.dropbox.com/u/59413997/Birds_HD.m2t (~76mb)
This file is retarding during avidemux play, and the CPU load is about 50% (two core processor). I have tried to change multi-threading option, but no luck :(
Or it is normal for HDV?

You may want to report this problem at the official Avidemux forum.

trying avidemux 2.6 revision 7740 for win32 comparing with avidemux 2.5.6
I have noticed often time on same frame differs 125ms between 2.6 and 2.5.6 (h264 video)
which one is more accurate?

Probably Avidemux 2.6. That's because frame accuracy in Avidemux 2.5.x was often broken for H.264 sources. This has been much improved in Avidemux 2.6.

[verydoomed]

I wish it was easier to use avisynthscripts with this program - the proxy thing well it's too complicated and a bother to even setup - I havent even managed (using Linux and have avisynth installed under wine)

[LoRd_MuldeR]

I wish it was easier to use avisynthscripts with this program - the proxy thing well it's too complicated and a bother to even setup - I havent even managed (using Linux and have avisynth installed under wine)

Using the the AVS Proxy should be straight forward. The AVS Proxy GUI makes it even easier.

And, without the AVS Proxy, it wouldn't be possible to use Avisynth on Linux at all! Thanks to the Proxy, Avisynth can run under Wine, while Aidemux can run as a "native" Linux process.

There currently is NO other way to use Avisynth under Linux. That's NOT a limitation of Avidemux. It's simply because there is NO "native" Avisynth for Linux.

(As mentioned earlier, there is AvxSynth now, which might be able to replace Avisynth under Linux one day)

[flapane]

Latest 2.6 nightly 32bit build on Win7 x64 (and first time for me with a 2.6 build).
If I select Average Bitrate Mode on AVC (x264) codec, the output file will have about half of the bitrate I selected, so I need to choose a value DOUBLE than the one I desire in order to roughly achieve the result.
If I can recall, it also happened a couple of times when 2.5 was still in beta stage.

Furthermore I can't see the remaining time on first pass (in case of double pass encoding) but just the elapsed time and the progress bar.

[flapane]

Another couple of weird things:
- If I start a two pass encoding, I can't stop the first pass one. CANCEL doesn't work, and if I try to click on the "X" icon, the encoding window disappears but I can see on task manager that the encoding process is still running. At this point Avidemux may crash.

- On Avidemux 2.5 I did the first pass encoding, then aborted the second one (http://forum.doom9.org/showpost.php?p=1536158&postcount=1682) because I hadn't time to do a 6 or 7 hours encoding. On the next day I could use the first pass encoding I already did the day before.
On Avidemux 2.6, the program doesn't recognize the .stats file from the first pass encoding, and starts from scratch creating a new .stats.temp 1st-pass encoding file.

- There are some problems in indexing some .ts 1080i files. The .ts.idx2 result file indexes just a part of the .ts file. However, this may be due to transmission errors and may not be addressed as bug.

[locotus]

When tryng to back-up my His Girl Friday Columbia/Sony DVD
to h.264 run into this:
With Avidemux Stable:
http://s16.postimage.org/z7eu93zip/Avidemux_2500.jpg (http://postimage.org/image/z7eu93zip/)
With Avidemux 2600:
http://s16.postimage.org/aff81vic1/Avidemux_2600.jpg (http://postimage.org/image/aff81vic1/)

As you may see it looks like images coming from
2 differents sources.

If use Decomb Telecide and Decomb Decimate file ends
un with VFR, with audio sincronization issues.

If I change FPS in video>frame rate,get this:
http://s16.postimage.org/p0nv75lld/mediainfo.jpg (http://postimage.org/image/p0nv75lld/)

Is there any workaround for this?

Any help will be much appreciated.
Thanks.

[LoRd_MuldeR]

libx264 SVN-r2200 library pack:

libx264 SVN-r2200 complete "all-in-one" library pack (mirror #1) (https://code.google.com/p/mulder/downloads/detail?name=libx264-125-r2200M-win32.7z&can=2&q=)
libx264 SVN-r2200 complete "all-in-one" library pack (mirror #2) (http://www.mediafire.com/file/s1eb0ze5zdrb4zx/libx264-125-r2200M-win32.7z)


Changelog:
commit 999b753ff0f4dc872077f4fa90d465e948cbe656 r2200
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Tue May 8 15:42:56 2012 -0700

Threaded lookahead

Split each lookahead frame analysis call into multiple threads. Has a small
impact on quality, but does not seem to be consistently any worse.

This helps alleviate bottlenecks with many cores and frame threads. In many
case, this massively increases performance on many-core systems. For example,
over 100% faster 1080p encoding with --preset veryfast on a 12-core i7 system.
Realtime 1080p30 at --preset slow should now be feasible on real systems.

For sliced-threads, this patch should be faster regardless of settings (~10%).

By default, lookahead threads are 1/6 of regular threads. This isn't exacting,
but it seems to work well for all presets on real systems. With sliced-threads,
it's the same as the number of encoding threads.

commit ecfbf9d8025e39783bc4262dc1972ca742d8a993 r2199
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Fri May 4 17:18:12 2012 +0400

Add support for RGB formats in bit-depth conversion filter

commit 1c97f3570fba02f768fbf649b9f7d48beb720048 r2198
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Sat May 12 13:57:49 2012 +0400

Fix some bugs in mb_info code

commit 69a0443e7d8ab032a7f3c3468a42177d5e64daa2 r2197
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Thu Mar 29 14:14:07 2012 -0700

Add mb_info API for signalling constant macroblocks
Some use-cases of x264 involve encoding video with large constant areas of the frame.
Sometimes, the caller knows which areas these are, and can tell x264.
This API lets the caller do this and adds internal tracking of modifications to macroblocks to avoid problems.
This is really only suitable without B-frames.
An example use-case would be using x264 for VNC.

commit df6252cfed7c23fbe883456f4e0607a7f8e91ad8 r2196
Author: Henrik Gramner <hengar-6@student.ltu.se>
Date: Sat Apr 7 00:40:09 2012 +0200

Faster chroma weight cost calculation

New assembly function with SSE2, SSSE3 and XOP implementations for calculating absolute sum of differences.

commit cce88ebc9e517b0fa8735b81ac30b4e6a79c8154 r2195
Author: Lucien <astrataro@gmail.com>
Date: Sat Mar 31 13:42:49 2012 +0100

Add Level 5.2 support

commit ee30c84e38b30896ffa6ddc417f3b4c281a86d1a r2194
Author: Henrik Gramner <hengar-6@student.ltu.se>
Date: Thu Apr 12 19:14:43 2012 +0200

Eradicate all mention of Extended Profile
x264 never supported it and never will because nobody uses it.

commit 8ca49cc5c40813d8b98544989eb684e167b06aa0 r2193
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Tue Apr 3 21:46:52 2012 +0400

Fix disabling of mbtree when using 2pass encoding and zones

commit 3691332c0b33a68f9d6f519edaa2b848ed34a38c r2192
Author: Alexander Prikhodko <komisar666@gmail.com>
Date: Sat Mar 31 12:06:21 2012 +0300

configure: force select -mXX gcc option for i386/x86-64
Makes multilib compilation more convenient.

commit e1ccbf9bb3abdd25d3f0c76682926ec49f3f8001 r2191
Author: Rafaël Carré <funman@videolan.org>
Date: Sun Apr 15 21:20:14 2012 -0400

Update config.guess and config.sub
Adds support for a bunch of targets, including:
aarch64 (armv8)
arm-linux-androideabi

commit f87619768dba73c1effbcfb08875d096575e079e r2190
Author: Alexander Prikhodko <komisar666@gmail.com>
Date: Sat Mar 31 11:33:41 2012 +0300

configure: correct use of RC variable and add --extra-rcflags

commit 35cf912671fddcb3e701bf667a75f77dd8b28264 r2189
Author: Steven Walters <kemuri9@gmail.com>
Date: Wed Mar 28 21:15:04 2012 -0400

ICL/MSVS: Fix shared library generation and usage
MSVS requires exported variables to be declared with the DATA keyword, and requires that imported variables be declared with dllimport.
This does not fix x264 cli being unable to use a shared library built by ICL however.

commit 259a6e57ae25c71acc1669e0aefde7ffe7e235ec r2188
Author: Kieran Kunhya <kierank@ob-encoder.com>
Date: Tue Mar 27 17:38:56 2012 +0100

Fix intra-refresh + hrd

commit e0351cdfeb45bf7f891eeb1dc475292154bb9d82 r2187
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Sun Mar 25 17:34:24 2012 +0400

Fix frame input colorspace check

commit 7392c8c31f791e9b4c10e4959f8715c8a8233d25 r2186
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Thu Mar 22 13:56:50 2012 -0700

Fix comment in deblock.c
The code does, in fact, handle CAVLC+8x8dct correctly already.

commit 6979713216d792e44e3cbaeeba74b455e0a07c62 r2185
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Tue Mar 13 14:37:26 2012 -0700

Fix sliced-threads ratecontrol bug
Was using qp instead of qscale; could cause NANs (not to mention less accurate results).

commit 5c85e0a2b7992fcaab09418e3fcefc613cffc743 r2184
Author: Anton Mitrofanov <Bugmaster@narod.ru>
Date: Sun Mar 11 23:08:18 2012 -0700

Fix clobbering of mutex/cvs
Regression in r2183.
Bizarrely seemed to work on many platforms, but crashed on win64 and may have been slower.
Only affected sliced threads during encoding, but could cause crashes on x264 encoder close even without sliced threads.

commit c522ad1fed167d0e985e4f9dcdee042473cf74db r2183
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Fri Feb 24 13:34:39 2012 -0800

Sliced-threads: do hpel and deblock after returning
Lowers encoding latency around 14% in sliced threads mode with preset superfast.
Additionally, even if there is no waiting time between frames, this improves parallelism, because hpel+deblock are done during
the (singlethreaded) lookahead.
For ease of debugging, dump-yuv forces all of the threads to wait and finish instead of setting b_full_recon.

commit 6a27a481d4c3508ce778a61a139a4734bb8126f7 r2182
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Fri Feb 24 13:16:52 2012 -0800

Add full-recon API option
Fully reconstruct frames even without dump-yuv.

commit e856755d2a67f45249c24cb51aa38fc4fa192321 r2181
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Wed Feb 22 13:33:36 2012 -0800

x86inc: switch to amdnops
Recent AMD CPUs' instruction decoders choke horribly on extremely long nops (i.e. with 4 prefixes).
Won't affect much, since we don't use ALIGN much.

commit 5a242c5862baaa4bd5829bd1b43dc11cf5c86344 r2180
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Tue Feb 14 16:54:03 2012 -0800

BMI1 decimate functions
Intel was nice enough to make tzcnt equal to "rep bsf", which is backwards-compatible.
This means we don't actually have to add new functions to make it work.

commit ac31c59a98c6c690894670b9c9af2612f799d85b r2179
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Tue Feb 14 15:07:10 2012 -0800

Minor asm changes

commit 83561e55dde06f3247aa9b99fa62ead38d7a406e r2178
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Thu Feb 9 14:23:52 2012 -0800

Add row-reencoding support to VBV for improved accuracy
Extremely accurate, possibly 100% so (I can't get it to fail even with difficult VBVs).
Does not yet support rows split on slice boundaries (occurs often with slice-max-size/mbs).
Still inaccurate with sliced threads, but better than before.

commit 5a69f8e105663497794d4bb4e58cf7baa5cd29cb r2177
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Thu Feb 9 12:38:44 2012 -0800

Abstract bitstream backup/restore functions
Required for row re-encoding.

commit 037d123cf62c4af2dc13742b8606882b6d0d3d9e r2176
Author: Anton Mitrofanov <Bugmaster@narod.ru>
Date: Thu Feb 9 15:27:53 2012 -0800

Add an small per-MB cost penalty for lowres
Helps avoid VBV predictors going nuts with very low-cost MBs.
One particular case this fixes is zero-cost MBs: adaptive quantization decreases the QP a lot, but (before this patch),
no cost penalty gets factored in for this, because anything times zero is zero.

commit de5a0adca1a7d08b1233b317ec092dbf19263d2f r2175
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Mon Feb 13 18:31:51 2012 -0800

Remove explicit run calculation from coeff_level_run
Not necessary with the CAVLC lookup table for zero run codes.

commit 9f1ac3b36eb2666e9d2ec4b859f3b63f60827bf0 r2174
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Mon Feb 13 13:20:06 2012 -0800

Export PSNR/SSIM in x264 API

commit 7e85ec036df4290697239f5dc9f4a793313ceebc r2173
Author: Ronald S. Bultje <rsbultje@gmail.com>
Date: Wed Feb 8 13:10:31 2012 -0800

x86inc: support yasm -f win64
Not necessary for x264, as -m amd64 already does the right thing, but used by external users of x86inc.

commit 02c3d5ec58d6bcbc5e22715ae80d53d8556f3c8f r2172
Author: Henrik Gramner <hengar-6@student.ltu.se>
Date: Wed Feb 1 23:52:48 2012 +0100

Fix incorrect zero-extension assumptions in x86_64 asm
Some x264 asm assumed that the high 32 bits of registers containing "int" values would be zero.
This is almost always the case, and it seems to work with gcc, but it is *not* guaranteed by the ABI.
As a result, it breaks with some other compilers, like Clang, that take advantage of this in optimizations.
Accordingly, fix all x86 code by using intptr_t instead of int or using movsxd where neccessary.
Also add checkasm hack to detect when assembly functions incorrectly assumes that 32-bit integers are
zero-extended to 64-bit.

commit 01f7a333e6c6a6d91a7fe977b491a448ddf4c117 r2171
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Thu Feb 23 09:11:23 2012 -0800

Fix possible alignment crash when linking from MSVC
x264_cavlc_init needs to be stack-aligned now.

commit b17c247178a24c218843639c3f46bcfde0edab0a r2170
Author: Anton Mitrofanov <Bugmaster@narod.ru>
Date: Tue Feb 21 12:58:22 2012 -0800

Fix rare overflow in 10-bit intra_satd_x3_16x16 asm

commit 1446fe7c47cf660d764b4cbf53694bc3df9b04de r2169
Author: Steven Walters <kemuri9@gmail.com>
Date: Sat Feb 11 22:56:43 2012 -0500

ICL: fix out of tree building and resource file usage on Windows

commit d3efb00abbedd2bbb70156bd989beefe06468116 r2168
Author: Oka Motofumi <chikuzen.mo@gmail.com>
Date: Mon Feb 6 06:07:34 2012 +0900

Add error handling for out-of-tree build

commit ec41b19edc67ee4eca09c0e3b37e6290844c5e1f r2167
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Tue Mar 6 17:34:02 2012 +0400

Fix RGB colorspace input
BGR/BGRA input was correct.

commit 39a4c6fecaaa0d6cde8d89d31ef6cd1d25ab802b r2166
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Mon Feb 13 16:40:32 2012 -0800

Fix interlaced + extremal slice-max-size
Broke if the first macroblock in the slice exceeded the set slice-max-size.

commit 3f72c99a15a07511b758d9e94217223480865124 r2165
Author: Henrik Gramner <hengar-6@student.ltu.se>
Date: Sun Feb 5 20:43:09 2012 +0100

Fix regression in r2141
Broke register preservation in x264_cpu_cpuid and x264_cpu_xgetbv.
Did not cause any problems.

commit da19765d723b06a1fa189478e9da61a1c18490f8 r2164
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Thu Jan 19 14:56:54 2012 -0800

TBM, AVX2, FMA3, BMI1, and BMI2 CPU detection support
TBM and BMI1 are supported by Trinity/Piledriver.
The others (and BMI1) will probably appear in Intel's upcoming Haswell.
Also update x86inc with AVX2 stuff.

commit efef20090a06a38f9d95755588d7830fb92a2a02 r2163
Author: Loren Merritt <pengvado@akuvian.org>
Date: Fri Feb 3 06:27:18 2012 +0000

x86inc: add TAIL_CALL macro to abstract a common asm idiom

commit a7e6e1793b4d2b49c9449d767320c71daa855cb6 r2162
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Wed Jan 25 16:44:38 2012 -0800

Minor asm optimizations/cleanup

commit 56ba096141d16ffcbabd805e2d27014f62f0d722 r2161
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Tue Jan 24 19:03:58 2012 -0800

Clean up and optimize weightp, plus enable SSSE3 weight on SB/BDZ
Also remove unused AVX cruft.

commit 961a278e0123eb662b46a6f136a48a43f6a2d427 r2160
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Mon Jan 23 18:57:58 2012 -0800

XOP frame_init_lowres
Covers both 8-bit and 16-bit, ~5-10% faster on Bulldozer.

commit c5809994990df6c63b4250546844dc77181fee0f r2159
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Tue Jan 17 15:25:10 2012 -0800

XOP 8x8 zigzags
Field: 35(mmx) ->16(xop) cycles
Frame: 32(ssse3)->20(xop) cycles

commit 14dc11f7c52fa29576e0003c8c16857a78bf5fbf r2158
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Mon Jan 23 15:09:38 2012 -0800

AVX 32-bit hpel_filter_h
Faster on Sandy Bridge.
Also add details on unsuccessful optimizations in these functions.

commit 2fcd0446b5d91ae52e143682c30000a49441e4a1 r2157
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Fri Jan 27 16:29:30 2012 -0800

x86inc: add high halfword register support
Might be useful in a few cases.

commit 5c4b8484ea9aaabfb70523ba1f9c4d8343ad3221 r2156
Author: Ronald S. Bultje <rsbultje@gmail.com>
Date: Wed Jan 25 13:53:59 2012 +0800

Change %ifdef directives to %if directives in *.asm files
This allows combining multiple conditionals in a single statement.

commit 1b558de42dc08a303c2faf79fc9999b48a876370 r2155
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Sun Jan 22 22:13:52 2012 +0400

Use TV range algorithm for bit-depth conversions
Such sources are more common, so better to be correct for the common case.
This also produces less error for the case of full range than the previous algorithm produced for the case of TV range.

commit 83c371deba853a4ebb28739e868df86b3153fb3e r2154
Author: Hii <hiiragikei@gmail.com>
Date: Wed Jan 25 16:29:22 2012 +0800

Bump dates to 2012

commit a2925c5a707e833c34fa0a64d497c02e6dcfe6e6 r2153
Author: Henrik Gramner <hengar-6@student.ltu.se>
Date: Sat Jan 28 21:38:27 2012 +0100

Add Windows resource file
Displays version info in Windows Explorer.

commit 98ade832d053f6bfca4d0dd2ab0cd1c88531721d r2152
Author: Sergey Radionov <RSATom@gmail.com>
Date: Mon Jan 16 13:22:44 2012 -0800

Fix win32 pthread_cond_signal
Isn't used by x264 currently, so didn't cause a problem.
Fix backported from libav.

commit a3f44077dc238dea92c0894d352b5a8723b9201b r2151
Author: Mans Rullgard <mans@mansr.com>
Date: Wed Feb 1 15:55:25 2012 -0800

ARM: align asm functions to 4 bytes.
Some linkers apparently fail to correctly align ARM functions when mixing with Thumb code.

commit d3a39c92f5c130cad6d45e9daffa5a2beb145ebb r2150
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Sun Jan 22 13:00:23 2012 +0400

Fix normalization of colorspace when input is packed YUV 4:2:2


These builds will NOT work with Avidemux 2.5.6 or older. Please update to Avidemux 2.6 r8054 (http://avidemux.razorbyte.com.au/#betaBuilds) or later now!

[cord-factor]

I am just tried 2.6-r8121 on Windows. So, it seems to be usable enough and stable: simple work with avc/aac, mpeg2-ts (I-frame cutting). No any loss of frame accuracy or a-v sync :cool:

[lenildosb]

please, help me friends, urgent, have a video and want cut part at the beginning, but when I save appears the error: 'The beginning frame is not a key frame. Please move the A marker.'

i mark copy for video and audio (not want render), after mark set A I(00) in beginning and set B P(00) in end the part that cut...

the avidemux cut only when set B is I(00).

can someone explain to me how to do precise cutting?


try cutting the commercial this stretch the video !!!!!

cutting in time 00:00:06.680 in mode copy video and audio

https://hotfile.com/dl/177951820/c0f08b2/Cassey_Doreen___Loona_-_Tell_It_To_My_Heart_(Official_HD)_-_YouTube.MP4.html

[laserfan]

Has anyone made a "blu-ray compatibility" profile for AviDemux? Before I go thru the myriad of the program's x264 configuration setting tabs myself it seems someone here might have already done this?

[parsifal]

Hello and a Happy New Year to all!

Frustrated by the lack of some easy/ready-made x264 presets in the latest version of Avidemux, I studied the settings for the official x264 presets (http://mewiki.project357.com/wiki/X264_Settings#preset) and adapted them as Avidemux x264 presets.

You should decompress the contents of the ZIP file I attached at the end of this post inside the following directory

Windows XP:
%USERPROFILE%\Application Data\avidemux\pluginSettings\x264\1

Windows Vista and newer:
%USERPROFILE%\AppData\Roaming\avidemux\pluginSettings\x264\1

NOTE: If the "pluginSettings\x264\1" subdirectory is not present in your system, you should start Avidemux and open+close the x264 configuration dialog at least one time.

From then on, the x264 configuration dialog of Avidemux will feature 10 additional presets:

x264 official presets - 01 - ultrafast
x264 official presets - 02 - superfast
x264 official presets - 03 - veryfast
x264 official presets - 04 - faster
x264 official presets - 05 - fast
x264 official presets - 06 - medium
x264 official presets - 07 - slow
x264 official presets - 08 - slower
x264 official presets - 09 - veryslow
x264 official presets - 10 - placebo

The rate control method I chose for the presets is the same as the official x264 default: Constant Rate Factor (CRF) with a CRF value of 23. This, you can change to the value you 'd like. For those that do not know, a brief explanation: The lower the value, the higher the visual quality for the result of the encoding. Generally, you should stay in the range of 16-26, better yet 18-24.
Additionaly, the following tip may be useful to some: setting the CRF value to 0 activates the encoder's lossless mode (if you don't understand what this means, just ignore it!).

If you have any comments, objections or questions about the content of this post, please let me hear about it!


.

[karesch]

Frustrated by the lack of some easy/ready-made x264 presets in the latest version of Avidemux, I studied the settings for the official x264 presets and adapted them as Avidemux x264 presets:

avidemux_2.6_x264_official_presets_parsifal_0.1.zip


Hi Parsifal,

Thanks a lot for your work, it is exactly what I was looking for this morning. Unfortunately, the file link does not seems to be working (mediafire responds "The file you requested has been blocked for a violation of our Terms of Service.").

Could you please repost the file?

Many thanks,

karesch

[parsifal]

Hi Parsifal,
Could you please repost the file?


Hello karesch. I edited my post, the link should be OK now.

[karesch]

Hello karesch. I edited my post, the link should be OK now.

Thanks a lot :)

[flapane]

On 2.6.x, I can't resume an encoding after the 1st pass is completed (and for whatever reason the second pass halts after an error). I have to repeat the first pass encoding from scratch, even if it's a waste of time.
On 2.5.x, this feature was very useful.

[gonwk]

Hi folks,

I hope, I am posting in the right Thread ... A Newbie Comment & Q ...

How come with AviDemux 2.6 and later (Portable versions) I No Longer get Audio during playing back my Video clip.
Video plays just fine ... but NO Audio.

I went back to 2.5.6 and Audio is working.

Q1: How can I use the latest Portable AVIDemux 2.6.1 r8696 and get Audio to work?

Q2: Why there are No More Portable Versions?

Q3: What happened to Razorbyte site?

Thanks,

G! :)

[gonwk]

Hello and a Happy New Year to all!

... You should decompress the contents of the ZIP file I attached at the end of this post inside the following directory

... If you have any comments,

Hi Parsifal,

Q: If I am using Portable Version of AviDemux and my OS is Vista X64, where would I put these Presets!?!?

Thanks,

G! :)

[LigH]

According to a report in the german doom9/Gleitz board, Avidemux (2.63, 2.64, 2.66) simply quits when trying to encode multi-channel audio with the LAV AAC encoder; I even have an APPCRASH dialog, trying to confirm this issue. The end of %APPDATA%\avidemux\admlog.txt contains:

[Lavcodec] Creating Lavcodec audio encoder (0xff)
[initialize] [Lavcodec]Too many channels
[Access] Encoder initialization failed
[Lavcodec] Deleting Lavcodec

Does this encoder not support more than 2 channels? The older FAAC encoder in Avidemux 2.6.1 does, but has other issues (low quality, noise in the beginning).
__

BTW, is this a useful place to make a feature request?

I found that Avidemux does not have decoder support for FLAC audio — while trying to convert some Blender movies which provide lossless audio sources as FLAC, which I multiplexed into an MKV as HQ source for converter quality tests.

[Ryo94]

Hi,

Since v2.6.5 I cannot see listed the fluxsmooth filter on the GUI, any idea how to solve this?

http://img163.imagevenue.com/loc48/th_71355_avidemux_122_48lo.jpg (http://img163.imagevenue.com/img.php?image=71355_avidemux_122_48lo.jpg)



Thanks in advance.

[Pulstar]

Is Avidemux on hiatus?

[LoRd_MuldeR]

Is Avidemux on hiatus?

I don't think so:
http://avidemux.sourceforge.net/news.html

And if you are lokking for the latest builds, you can even have a look here:
http://www.avidemux.org/nightly/win32/