Avidemux (with emphasis on x264/h264 GUI) [Archive] - Page 25

LoRd_MuldeR

3rd August 2009, 21:00

libx264 SVN-r1195:

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

libx264 SVN-r1195 with AutoVAQ enabled:

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

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

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

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

LoRd_MuldeR

3rd August 2009, 21:58

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

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

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

ffmpeg

4th August 2009, 02:25

Hi, LoRd_MuldeR

Where do you get gcc 4.4.1 for mingw?

Thanks

LoRd_MuldeR

4th August 2009, 02:27

Hi, LoRd_MuldeR

Where do you get gcc 4.4.1 for mingw?

Thanks

The link is in the post :p

TheImperial2004

4th August 2009, 11:07

Any news when will the x264 dialog will be updated ?

That will be the most exciting revision ever ^_^

LoRd_MuldeR

4th August 2009, 13:08

Any news when will the x264 dialog will be updated ?

That will be the most exciting revision ever ^_^

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

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

TheImperial2004

4th August 2009, 16:21

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

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

akiza

7th August 2009, 10:26

LoRd_MuldeR

7th August 2009, 10:48

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

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

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

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

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

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

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

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

LoRd_MuldeR

12th August 2009, 19:45

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

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

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

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

LoRd_MuldeR

12th August 2009, 21:33

libx264 SVN-r1206 with MB-Tree Ratecontrol:

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

libx264 SVN-r1206 without MB-Tree Ratecontrol:

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

libx264 SVN-r1206 with AutoVAQ enabled:

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

libx264 SVN-r1206 legacy compiler builds:

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

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

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

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

Schrade

13th August 2009, 07:38

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

nakTT

13th August 2009, 07:44

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

:thanks:

LoRd_MuldeR

13th August 2009, 12:21

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

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

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

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

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

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

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

LoRd_MuldeR

14th August 2009, 00:49

libx264 SVN-r1210 with MB-Tree Ratecontrol:

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

libx264 SVN-r1210 without MB-Tree Ratecontrol:

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

libx264 SVN-r1210 with AutoVAQ enabled:

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

libx264 SVN-r1210 legacy compiler builds:

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

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

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

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

LoRd_MuldeR

17th August 2009, 11:21

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

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

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

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

TheImperial2004

17th August 2009, 12:22

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

Betsy25

17th August 2009, 14:05

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

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

Congrats Lord on this fantastic tool !:)

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

LoRd_MuldeR

17th August 2009, 16:15

Congrats Lord on this fantastic tool !:)

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

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

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

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

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

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

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

LoRd_MuldeR

17th August 2009, 22:22

libx264 SVN-r1214 with MB-Tree Ratecontrol:

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

libx264 SVN-r1214 without MB-Tree Ratecontrol:

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

libx264 SVN-r1214 with AutoVAQ enabled:

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

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

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

LoRd_MuldeR

19th August 2009, 17:53

libx264 SVN-r1217 with MB-Tree Ratecontrol:

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

libx264 SVN-r1217 without MB-Tree Ratecontrol:

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

libx264 SVN-r1217 with AutoVAQ enabled:

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

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

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

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

TheImperial2004

20th August 2009, 08:07

Hi Mulder ,,

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

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

LoRd_MuldeR

20th August 2009, 12:04

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

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

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

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

DarkZell666

20th August 2009, 12:04

Hi Mulder ,,

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

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

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

TheImperial2004

20th August 2009, 14:30

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

LoRd_MuldeR

20th August 2009, 22:29

libx264 SVN-r1222 with MB-Tree Ratecontrol:

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

libx264 SVN-r1222 without MB-Tree Ratecontrol:

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

libx264 SVN-r1222 with AutoVAQ enabled:

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

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

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

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

Poutnik

22nd August 2009, 08:47

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

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

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

LoRd_MuldeR

22nd August 2009, 12:41

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

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

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

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

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

Poutnik

22nd August 2009, 16:16

The first 2 paragraphs are obvious to me.

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

LoRd_MuldeR

23rd August 2009, 02:22

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

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

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

TheImperial2004

23rd August 2009, 21:42

5268 is out :)

If Lord_Mulder won't mind :

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

Change Log :

[win32] bump installer version

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

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

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

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

[Codec] WMVA==VC1 video codec

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

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

Windows Package Notes :

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

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

LoRd_MuldeR

23rd August 2009, 22:32

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

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

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

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

TheImperial2004

23rd August 2009, 22:40

Sorry for the wrong analysis :)

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

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

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

LoRd_MuldeR

24th August 2009, 00:12

libx264 SVN-r1222:

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

libx264 SVN-r1222 without MB-Tree Ratecontrol:

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

libx264 SVN-r1222 with AutoVAQ enabled:

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

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

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

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

Poutnik

24th August 2009, 05:09

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

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

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

LoRd_MuldeR

24th August 2009, 16:50

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

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

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

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

Dark Shikari

24th August 2009, 19:20

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

Poutnik

25th August 2009, 05:14

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

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

Thank you for your answers.

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

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

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

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

LoRd_MuldeR

25th August 2009, 14:48

<EDIT>

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

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

</EDIT>

libx264 SVN-r1232:

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

libx264 SVN-r1232 without MB-Tree Ratecontrol:

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

libx264 SVN-r1232 with AutoVAQ enabled:

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

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

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

TheImperial2004

25th August 2009, 17:18

(broken!?)

Did it crash with a specific clip or all clips ?

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

LoRd_MuldeR

25th August 2009, 17:21

Did it crash with a specific clip or all clips ?

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

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

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

LoRd_MuldeR

25th August 2009, 18:27

libx264 SVN-r1232:

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

libx264 SVN-r1232 without MB-Tree Ratecontrol:

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

libx264 SVN-r1232 with AutoVAQ enabled:

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

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

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

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

TheImperial2004

25th August 2009, 20:43

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

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

LoRd_MuldeR

27th August 2009, 15:15

libx264 SVN-r1235:

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

libx264 SVN-r1235 without MB-Tree Ratecontrol:

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

libx264 SVN-r1235 with AutoVAQ enabled:

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

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

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

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

LoRd_MuldeR

28th August 2009, 01:08

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

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

LoRd_MuldeR

28th August 2009, 13:19

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

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

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

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

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

TheImperial2004

28th August 2009, 16:18

LoRd_MuldeR

28th August 2009, 16:23

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

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

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

TheImperial2004

28th August 2009, 17:12

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

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

LoRd_MuldeR

28th August 2009, 17:21

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

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

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

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

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

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

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