Avidemux (with emphasis on x264/h264 GUI)

[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