Avidemux (with emphasis on x264/h264 GUI)

[gruntster]

Ok, should be fixed r4455. Looks like the problem has been around for quite some time.

[LoRd_MuldeR]

Avidemux 2.4.3 SVN-r4454 (2008-10-08)
http://www.avidemux.org/

Revision 4454 (08 Oct 2008)

4454 - [Qt] fix file dialogs to handle UTF-8 strings in caption
4453 - [mp4] only let libavformat calculate DTS for MP4 when encoding H.264 (fixes regression in r4363)
4452 - [Qt] handle UTF-8 strings properly when escaping ampersands (regression introduced r4449)
4451 - [Qt] don't translate container formats twice
4450 - [Qt] stop video when exiting
4449 - [Qt] escape ampersands when converting GTK+ accelerators
4448 - [Qt] use correct colourspace for Qt when resizing YUV images on flyDialogs
4447 - [Qt] correctly handle automatic resize of large images on Equaliser window
4446 - [Qt] Equaliser filter window for Qt UI
4445 - [MPEG-TS] don't include SPS NAL units as frames in H.264 video

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]

Avidemux 2.4.3 SVN-r4458 (2008-10-13)
http://www.avidemux.org/

Revision 4458 (13 Oct 2008)

4458 - [MPEG-TS] fix overflow that prevented all pids being searched (regression in r4293)
4457 - [Qt] extend FPS on Change Frame Rate dialog to 3 decimals
4456 - [dialogFactory] make number of decimals definable for float element
4455 - [FAAC] don't set bandwidth as it can give an incorrect bitrate (regression in r2663)
4454 - [Qt] fix file dialogs to handle UTF-8 strings in caption

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]

Ok, should be fixed r4455. Looks like the problem has been around for quite some time.

It seems the problem is fixed indeed:
I just ran an encode with FAAC and selected 96 kbps for the Stereo stream. It came out at an average bitrate of 95.995 kbps.

Good work :)

[ozhanesk90]

It seems the problem is fixed indeed:
I just ran an encode with FAAC and selected 96 kbps for the Stereo stream. It came out at an average bitrate of 95.995 kbps.

Good work :)

Maybe fixed for avi container but MKV still only encode 128kbps :confused:

[DarkZell666]

Maybe fixed for avi container but MKV still only encode 128kbps :confused:

The bitrate isn't reported correctly for MP4/MKV, but the stream is actually encoded with the bitrate you asked for. Simply demux the .aac track from the .mkv and playback the .aac directly so you can check the real audio bitrate (cf. a couple of posts earlier, #948 and #950).

[LoRd_MuldeR]

The bitrate isn't reported correctly for MP4/MKV, but the stream is actually encoded with the bitrate you asked for. Simply demux the .aac track from the .mkv and playback the .aac directly so you can check the real audio bitrate (cf. a couple of posts earlier, #948 and #950).

Or use Avinpatic, it will report the actual average bitrate ;)

[ozhanesk90]

I don't worry my audio kbps No matter what audio seems, I only want to encode 64 or 56 kbps or less... But isn't possible yet :(I want Because I'm x264 Small Size Video Encoder So audio not important than video for me :D

[LoRd_MuldeR]

Avidemux 2.4.3 SVN-r4473 (2008-10-15)
http://www.avidemux.org/

Revision 4473 (15 Oct 2008)

4473 - [UI] change File/Open caption
4472 - [automake] update
4466 - [Mac] use native file dialogs for Qt and set minimum required Qt version to 4.4.0
4463 - [Qt] remember last path for file dialogs
4462 - [Qt] clean up properly and save prefs, etc when closing via Close button
4461 - [m2ts] account for larger m2ts packets when tracking audio
4460 - [Qt] another fix for correct colourspace when resizing YUV images on flyDialogs for Qt
4459 - [MP4] fix compilation error when system doesn't have libx264 (FS#512)
4458 - [MPEG-TS] fix overflow that prevented all pids being searched (regression in r4293)

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]

Avidemux 2.4.3 SVN-r4486 (2008-10-18)
http://www.avidemux.org/

Revision 4486 (18 Oct 2008)
# Updated GLib to version 2.18.2-1.

4486 - [Win32] don't install GTK+ UI by default
4485 - [Qt] add PAR to x264 config dialog
4484 - [Qt] fix thumb slider's left border
4483 - [Qt] tweak thumb slider control so it doesn't overrun border
4482 - [Qt] make thumb slider thinner
4481 - [Qt] tweak Auto menu captions
4480 - [Qt] skin thumb slider
4479 - [Qt] sync thumb slider header
4478 - [Qt] don't explicitly set the font family on Qt dialogs
4477 - [Qt] tweak for main UI to better accommodate jog shuttle
4476 - [Qt] jog shuttle for main UI
4473 - [UI] change File/Open caption

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)

[wata]

regarding latest version of Avidemux, 2.4.3 SVN-r4486 (2008-10-18)

something change seem to cause filesize of encode video (x264) to varies with exact same setting (save it as project so nothing change)
the souce is a test mpeg2 file with avs setting (resize, crop etc) connect to the avsproxy
each time i close avidemux and reopen it to encode the filesize changes

test with all version from avidemux_2.4_r4445_win32 to avidemux_2.4_r4486_win32 as all is using same x264 r999
and using crf=18
notice output from r4486 alway is different size

10/20/2008 01:15 AM 11,036,529 test_avidemux_r999-2 (avidemux_2.4_r4473_win32).mp4
10/20/2008 12:44 AM 11,036,529 test_avidemux_r999-3 (avidemux_2.4_r4445_win32).mp4
10/20/2008 12:47 AM 11,036,529 test_avidemux_r999-4 (avidemux_2.4_r4458_win32).mp4
10/20/2008 12:50 AM 11,036,529 test_avidemux_r999-5 (avidemux_2.4_r4473_win32).mp4
10/20/2008 01:06 AM 10,550,751 test_avidemux_r999-6 (avidemux_2.4_r4486_win32).mp4
10/20/2008 01:12 AM 10,688,378 test_avidemux_r999-7 (avidemux_2.4_r4486_win32).mp4
10/20/2008 01:02 AM 10,987,796 test_avidemux_r999-8 (avidemux_2.4_r4486_win32).mp4

[LoRd_MuldeR]

Not sure what could have changed the filesize between Avidemux r4473 and Avidemux r4486, as both builds use libx264 r999.
Also I don't see any changes regarding x264 in the Avidemux core application between r4473 and r4486.

However I just made a few quick test encodes with Avidemux r4486 (x264 r999) in CRF mode and I got this:
x264-r999-1.avi 10.494.574 Byte
x264-r999-2.avi 10.494.574 Byte
x264-r999-3.avi 10.494.614 Byte

Two encodes came out at the exactly same size, the last one was slightly bigger (the deviation is less than 0.001%)
So I think this very small derivation can be explained with the indeterministics of multi-threaded x264...

[DarkZell666]

@wata : would you mind posting your settings ? does x264 actually behave the same with the same settings ?

OTOH, multi-threading isn't naturally undeterministic. Only the time at which each threads finishes varies, not the result of the calculations. It can be if the threads are badly coded though (with non-synchronized shared memory access for example ?). At least that's what I was taught in class (I've never had lessons on determinism in programming).

[LoRd_MuldeR]

@wata : would you mind posting your settings ? does x264 actually behave the same with the same settings ?

OTOH, multi-threading isn't naturally undeterministic. Only the time at which each threads finishes varies, not the result of the calculations. It can be if the threads are badly coded though (with non-synchronized shared memory access for example ?). At least that's what I was taught in class (I've never had lessons on determinism in programming).

Well, multi-threading is not inherently indeterministic. That's right.

However multi-threaded x264 is indeterministic for sure, if the "--non-deterministic" switch is used.
And I'm not even sure that multi-threaded x264 is guaranteed to be deterministic without that switch.

x264, in threaded mode, is not necessarily deterministic.Its not deterministic--that is, if you run it two times, it won't give exactly the same results.

[wata]

nevermind, i try a few more test encode now the filesize varies for the previous version too
i think it is cause by the avsproxy
sometime i get 2 same size file but the third one differ alot not sure which setting in the avs is causing it
right now i will just stick with the internal filters which has same otuput filesize no matter how many time i encode
anyway, here the my avs file:

DGDecode_mpeg2source("e:\=x264 test\test.d2v")
Load_Stdcall_Plugin("C:\Program Files\AviSynth 2.5\plugins\yadif.dll")
Yadif(order=1)
crop( 22, 0, -30, -4)
Spline36Resize(576,448) # Spline36 (Neutral)
#denoise

[LoRd_MuldeR]

Avidemux 2.4.3 SVN-r4494 (2008-10-22)
http://www.avidemux.org/

Revision 4494 (22 Oct 2008)
# Updated GTK+ to version 2.14.4-1.

4494 - [I18N] Italian update by zoppo
4493 - [Qt] add AVI Muxer Options to main menu and move Preferences
4492 - [Qt] use buttonBox on Working dialog
4491 - [Animated] fix title of the Animated Menu filter dialog
4490 - [Qt] more UTF-8 fixes
4489 - [I18N] make a few strings translatable & fix UTF-8 conversion on encoding window
4488 - [Qt] centre volume slider
4487 - [mp4] ensure pts != dts
4486 - [Win32] don't install GTK+ UI by default

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)

[ozhanesk90]

The AAC (Advanced Audio Codec)

AAC was first specified in the standard MPEG-2 Part 7 in 1997 and updated in MPEG-4 Part 3 in 1999. AAC is more linear, eliminating the hybrid approach in favor of a pure MDCT. To better encode both stationary signals and transient signals, the encoder can decide to use a wide 1024 samples window for the MDCT (better frequency resolution for stationary signals) or a set of 8 x 128 samples MDCTs (better time resolution in transient signals). This approach, with other optimizations (better join stereo, entropy coding, perceptual noise shaping, etc..) , assure to AAC an higher perceptual quality compared to MP3 at the same bitrate, expecially below 128Kbit/s.

HE-AAC

This enhanced version of AAC introduces the SBR Technique (Side Band Replication). With SBR, a signal frequency spectrum is split in half. The part below 22KHz (lower frequencies) is encoded as usual, the part above (higher frequencies) is reconstructed as a trasformation of the spectrum envelope of the low frequencies block. A very small side-bitstream gives to the decoder the addictional informations necessary to reconstruct the final signal. With SBR, a signal of around 70-75Kbit/s is only slightly worst than a 128Kbit/s MP3.

http://www.progettosinergia.com/flashvideo/sbr_2_codec.gif

HE-AAC v2

The latest update of AAC standard, introduces the Parametric Stereo Technique (PS). With PS, only a mono signal is encoded and trasmitted, the second audio signal (supposing a stereo signal in input) is analysed and a set of parameters found and trasmitted to the decoder. These parameters describe matematically the difference beetween the left and the right channel in a stereo sound. This technique allow a further level of compression. At 64Kbit/s, a HE-AAC coded sound and a HE-AAC v2 codec sound are almost identical, but at lower bitrate, as 48Kbit/s, 32Kbit/s and 24Kbit/s, HE-AAC v2 produces a signal with an higher perceptal quality.

http://www.progettosinergia.com/flashvideo/PS_level1.gif

Conclusion

The support of AAC allows us to encode our sounds to 64Kbit/s with the same quality of a 128Kbit/s encoded MP3. Further more, for other use more susceptible to bandwidth usage, like Internet Radio, HE-AAC v2 gives us the possibility to encode our sounds to 32Kbit/s or lower with a surpraisingly good final result. In low bitrate streaming scenarios this can make the difference.

is it possible our avidemux?

[LoRd_MuldeR]

Avidemux already supports AAC via FAAC. However only LC-AAC is supported via FAAC, because FAAC cannot encode to HE-AAC yet.

Since there is no OpenSource HE-AAC encoder available yet, it is not possible to add HE-AAC support to Avidemux at the moment!
You may encode your audio stream to HE-ACC using the free Nero AAC encoder. Then you can multiplex the HE-AAC with the video from Avidemux.
And don't expect too much benefit from HE-AAC over LC-AAC. HE-ACC really is only helpful at ultra-low bitrates.

BTW: mp3PRO used the very same technique that HE-AAC uses to squish out more quality at ultra-low bitrates - with limited success.

[ozhanesk90]

I couldn't choose jvt matrix. I choose but close window and open again its manualy choosing flat matrix

[LoRd_MuldeR]

I couldn't choose jvt matrix. I choose but close window and open again its manualy choosing flat matrix

GTK+ or Qt interface?

Also: There is no sane reason to use "jvt" matrix. x264 works best with the default "flat" matrix.

flat is not a custom matrix it's the DEFAULT quantization. JVT matrix is included too though and it's quite useless. like the default mpeg quantization matrix in xvid.

[LoRd_MuldeR]

libx264 SVN-r999 + Psy-RD Assembly Fix + Gruntster's Alignment-Fix:
http://www.mediafire.com/file/3dxmnmtyeym/libx264-r999-hadamard_ac-force_align-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-1 (fprofiled). Tested with Avidemux 2.4.3 r4494.

Hadamard_ac... ooooooooooh, it is a bug in psy-RD, but in the assembly, not the C code or the algorithm!

I'm going to guess there was some sort of overflow, considering the fact that it only happens on a black/white area like that.

[...]

Here's Akupenguin's fix. (http://akuvian.org/src/x264/hadamard_ac.diff)

It seems to fix the problem; it avoids possibility of overflow as far as I can tell.

If no issues are reported, I'll commit it locally (yes, yes, r1k is coming soon!).

[LoRd_MuldeR]

libx264 SVN-r1016 + Gruntster's Alignment-Fix:
http://www.mediafire.com/file/lwgmqvyzjfm/libx264-r1016-force_align-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-1 (fprofiled). Tested with Avidemux 2.4.3 r4494.

[Inspector.Gadget]

I have a question about setting audio delay in Avidemux: If I open a VOB or similar directly, does Avidemux automatically determine the audio delay and compensate (during encoding or remuxing) or do I need to enter the value manually? Thanks.

[DarkZell666]

I have a question about setting audio delay in Avidemux: If I open a VOB or similar directly, does Avidemux automatically determine the audio delay and compensate (during encoding or remuxing) or do I need to enter the value manually? Thanks.

You need to do that manually ^^
You can either go by trial and error, or index+demux the audio track in dgmpgdec and read the correct delay from the filename of the demuxed ac3 track :)

[Inspector.Gadget]

You need to do that manually ^^
You can either go by trial and error, or index+demux the audio track in dgmpgdec and read the correct delay from the filename of the demuxed ac3 track :)

Thanks. That's what I had done a while ago but this time around I didn't want to double the delay by mistake.

[LoRd_MuldeR]

Also you can goto "Audio" -> "Main Track" in Avidemux to see the delay calculated by Avidemux. In my experience DGIndex delivers a more accurate delay though.

I still wonder why Avidemux does calculate a delay (accurate or not), but doesn't apply it automatically...

[Inspector.Gadget]

@LoRd_MuldeR - I never knew about that feature. Thanks.

[LoRd_MuldeR]

libx264 SVN-r1019 + Gruntster's Alignment-Fix:
http://www.mediafire.com/file/5q5ha5ynzyg/libx264-r1019-force_align-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-1 (fprofiled). Tested with Avidemux 2.4.3 r4494.

[LoRd_MuldeR]

libx264 SVN-r1024 + Gruntster's Alignment-Fix:
http://www.mediafire.com/file/uhgvuylfvqg/libx264-r1024-force_align-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-1 (fprofiled). Tested with Avidemux 2.4.3 r4494.

[LoRd_MuldeR]

libx264 SVN-r1026 + Gruntster's Alignment-Fix:
http://www.mediafire.com/file/n0mz2mf2mgt/libx264-r1026-force_align-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-1 (fprofiled). Tested with Avidemux 2.4.3 r4494.

[LoRd_MuldeR]

libx264 SVN-r1029 + Gruntster's Alignment-Fix:
http://www.mediafire.com/file/ijymygioy25/libx264-r1029-force_align-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-1 (fprofiled). Tested with Avidemux 2.4.3 r4494.

[LoRd_MuldeR]

libx264 SVN-r1034 + Gruntster's Alignment-Fix:
http://www.mediafire.com/file/e5jnnzmfyn3/libx264-r1034-force_align-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-1 (fprofiled). Tested with Avidemux 2.4.3 r4494.

[LoRd_MuldeR]

libx264 SVN-r1038 + Gruntster's Alignment-Fix:
http://www.mediafire.com/file/wjodygmjigz/libx264-r1038-force_align-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-1 (fprofiled). Tested with Avidemux 2.4.3 r4494.

[roozhou]

Since there is no OpenSource HE-AAC encoder available yet, it is not possible to add HE-AAC support to Avidemux at the moment!


3GPP Reference aasPlus Encoder is open-source. Can you consider adding it to avidemux?

[LoRd_MuldeR]

3GPP Reference aasPlus Encoder is open-source. Can you consider adding it to avidemux?

File a feature request and hope the devs will hear you:
http://bugs.avidemux.org/

I got zero idea how suitable that 3GPP encoder is for integration into Avidemux, nor di I know how it performs quality-wise...

[roozhou]

File a feature request and hope the devs will hear you:
http://bugs.avidemux.org/

I got zero idea how suitable that 3GPP encoder is for integration into Avidemux, nor di I know how it performs quality-wise...

The quality and encoding speed(compiled by VS2005) is very close to Real's RACP. However it only supports stereo and up to 52kbps.

[LoRd_MuldeR]

The quality and encoding speed(compiled by VS2005) is very close to Real's RACP. However it only supports stereo and up to 52kbps.

Sounds pretty low, even for HE-AAC (AAC + SBR) aka "aacPlus v1". I think ~52 kbps is more the range for aacPlus v2 (AAC + SBR + PS).

Is Parametric Stereo (PS) supported by that encoder?

And most important: Is that encoder only working as a CLI encoder or can it be compiled as a library?

[roozhou]

It supports both SBR and PS. It is written in floating-point ANSI-C and of course can be compiled as a library.

IMHO SBR+PS can never be better than SBR even at <32 kbps.

[LoRd_MuldeR]

of course can be compiled as a library.

That's not so obvious :p

But this way there is at least a chance that somebody will integrate it into Avidemux...

[LoRd_MuldeR]

libx264 SVN-r1041 + Gruntster's Alignment-Fix:
http://www.mediafire.com/file/mtz4znv4imm/libx264-r1041-force_align-fprofiled.7z

Broken! See: http://forum.doom9.org/showthread.php?p=1218039

[LoRd_MuldeR]

libx264 SVN-r1042 + Gruntster's Alignment-Fix:
http://www.mediafire.com/file/3nzzijdty0m/libx264-r1042-force_align-fprofiled.7z

Compiled with MinGW GCC 4.3.2-tdm-1 (fprofiled). Tested with Avidemux 2.4.3 r4494.

[LoRd_MuldeR]

Avidemux 2.4.3 SVN-r4499 (2008-12-03)
http://www.avidemux.org/

Revision 4499 (03 Dec 2008)
# Packaged using NSIS 2.41.
# Updated Avisynth Proxy GUI to version 2.06.
# Updated GLib to version 2.18.3-1.
# Updated GTK+ to version 2.14.5-1.
# Updated Libxml2 to version 2.7.2.
# Updated Pango to version 1.22.2-1.
# Updated Qt to version 4.4.3.
# Updated win_iconv to version 20080403.
# Updated x264 to r1046 (patched).
# Updated Xvid to 1.2.0.

4499 - [Win32] add Czech Qt translation to installer
4498 - [I18N] Czech update by Jakub Misak
4497 - [I18N] Czech update and new Qt translation by Jakub Misak
4496 - [I18N] update Qt project file
4495 - [Qt] more UTF-8 fixes
4494 - [I18N] 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.4)

[LoRd_MuldeR]

libx264 SVN-r1051 + Gruntster's Alignment-Fix:
http://www.mediafire.com/file/yyhrgwdnazn/libx264-r1051-force_align-fprofiled.7z

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

[LoRd_MuldeR]

libx264 SVN-r1056 + Gruntster's Alignment-Fix:
http://www.mediafire.com/file/twzao3dncmz/libx264-r1056-force_align-fprofiled.7z

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

[LoRd_MuldeR]

libx264 SVN-r1057 + Gruntster's Alignment-Fix:
http://www.mediafire.com/file/3nff0mmxw2y/libx264-r1057-force_align-fprofiled.7z

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

[LoRd_MuldeR]

libx264 SVN-r1060 + ESA Crash Fix + Gruntster's Alignment-Fix:
http://www.mediafire.com/file/flzzjdzmmqd/libx264-r1060-force_align-esa_fix-fprofiled.7z

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

[LoRd_MuldeR]

Avidemux 2.4.3 SVN-r4502 (2008-12-27)
http://www.avidemux.org/

Revision 4502 (27 Dec 2008)
# Updated GTK+ to version 2.14.6-1.
# Updated Libxml2 to version 2.7.2+.
# Updated x264 to r1062 (patched).
# Updated Xvid to 1.2.1.

4502 - [mp4] correctly generate extra data for esds atom (fixes regression in r4375)
4501 - [mkv] Properly identify DTS audio inside mkv
4500 - [dca] Try also linking libdca if libdts fails
4499 - [Win32] add Czech Qt translation 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.4)

[LoRd_MuldeR]

libx264 SVN-r1063 + Gruntster's Alignment-Fix:
http://www.mediafire.com/file/ylhmotnjo0g/libx264-r1063-force_align-fprofiled.7z

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

[LoRd_MuldeR]

libx264 SVN-r1065 + Gruntster's Alignment-Fix:
http://www.mediafire.com/file/oziknwyjzmm/libx264-r1065-force_align-fprofiled.7z

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

[Dark Shikari]

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