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

LoRd_MuldeR

15th September 2009, 01:51

libx264 SVN-r1259:

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

libx264 SVN-r1259 using four slices:

libx264-r1259, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-slices-gcc433-core2-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-slices-gcc433-amdfam10-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.3, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-slices-gcc433-pentium3-fprofiled.7z)

libx264 SVN-r1259 with AutoVAQ enabled:

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

libx264 SVN-r1259 with MB-Tree disabled:

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

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

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

This build fixes the crash that occured when the encode was aborted prematurely. It turns out that was a x264 bug. Fixed in r1253.

Chikuzen

15th September 2009, 15:42

I am using mulder 's latest buid(r5327) on Windows7RC_x64(build7100).
When I tried to use the Audio->MainTrack->AudioSource-External MP3,I got an message.
"Cannnot load The selected audio file does not exist."
I investigated this for about ten minutes, and found an answer.
The cause of this error was to have used Japanese(multibyte) characters for the filename.
I hope to come to be able to use multibyte characters also for the audio file as well as the video file:)

LoRd_MuldeR

15th September 2009, 15:49

Chikuzen

15th September 2009, 16:25

You should report this at the Avidemux forum. So the devs may possibly fix it ;)

http://avidemux.org/admForum/

okay.
I reported on this to Avidemux forum. :thanks:

LoRd_MuldeR

15th September 2009, 20:40

I reported on this to Avidemux forum. :thanks:

Fixed r5329.

That was quick :)

LoRd_MuldeR

17th September 2009, 19:41

Avidemux 2.5 SVN-r5341 (2009-09-17)
http://www.avidemux.org/

Revision 5341 (17 Sep 2009)
# Updated x264 to r1259.

5341 - [win32] include new colour curve editor filter in Windows installer
5340 - [ffmpeg] update FFmpeg to r19894 & libswscale r29686
5338 - [MKV] Add another alias for AAC
5333 - [plugin] Curve editor, by janec
5332 - [mkv] Derive frame type while indexing (merge from 2.6)
5331 - [mkv] Derive frame type while indexing (merge from 2.6)
5330 - [win32] fix mpeg muxer to handle unicode file names (fixes #38)
5329 - [win32] handle unicode names when checking for file existence
5328 - [Po] Polish translation by Aleksander Łukasiewicz
5327 - [xvid] destroy xvid context after each pass

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

lansing

19th September 2009, 17:39

could there be a 3 way color wheel like the one in sony vegas for tuning color? It's a very good tool for color correction on old anime.

http://img132.imageshack.us/img132/4517/colorwheelu.png

TheImperial2004

20th September 2009, 00:13

could there be a 3 way color wheel like the one in sony vegas for tuning color? It's a very good tool for color correction on old anime.

I guess that you should make a "feature request" at AviDemux's official forums (http://avidemux.org/admForum/viewforum.php?id=18) ;)

Brazil2

23rd September 2009, 11:59

libx264 SVN-r1259: libx264-r1259, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1259M-gcc433-core2-fprofiled.7z)
This build fixes the crash that occured when the encode was aborted prematurely. It turns out that was a x264 bug. Fixed in r1253.
Unfortunately it still crashes Avidemux if I abort the encoding (H264 + AAC in MP4).
Using Avidemux SVN Build 5341 on Windows XP Pro 32 bits.

Dark Shikari

23rd September 2009, 12:01

Fixed in r1267 (http://git.videolan.org/?p=x264.git;a=commit;h=c62060d242879d8271c22a486b286b91147d2ebf).

LoRd_MuldeR

23rd September 2009, 12:37

Fixed in r1267 (http://git.videolan.org/?p=x264.git;a=commit;h=c62060d242879d8271c22a486b286b91147d2ebf).

Too bad this was fixed after the major API change :D

LoRd_MuldeR

24th September 2009, 12:29

libx264 SVN-r1259:

libx264-r1259, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1259M-gcc434-core2-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1259M-gcc434-amdfam10-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1259M-gcc434-pentium3-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.4, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1259M-gcc434-noasm-fprofiled.7z)

libx264 SVN-r1259 using four slices:

libx264-r1259, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-slices-gcc434-core2-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-slices-gcc434-amdfam10-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-slices-gcc434-pentium3-fprofiled.7z)

libx264 SVN-r1259 with AutoVAQ enabled:

libx264-r1259, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-autovaq-gcc434-core2-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-autovaq-gcc434-amdfam10-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-autovaq-gcc434-pentium3-fprofiled.7z)

libx264 SVN-r1259 with MB-Tree disabled:

libx264-r1259, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-nombtree-gcc434-core2-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-nombtree-gcc434-amdfam10-fprofiled.7z)
libx264-r1259, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-nombtree-gcc434-pentium3-fprofiled.7z)

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

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

I re-compiled r1259, this time with the "real" fix for the encoder_close crash. Cannot provide builds of r1260 or later for Avidemux yet.

Brazil2

24th September 2009, 13:24

libx264 SVN-r1259:
libx264-r1259, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-75-r1259M-gcc434-core2-fprofiled.7z)
libx264 SVN-r1259 with MB-Tree disabled:
libx264-r1259, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-75-r1259M-nombtree-gcc434-core2-fprofiled.7z)

I re-compiled r1259, this time with the "real" fix for the encoder_close crash. Cannot provide builds of r1260 or later for Avidemux yet.
I've done some quick tests with the above builds, still with Avidemux SVN Build 5341 on Windows XP 32 bits and a Core2Duo, and the patch seems to work so far, no crashes anymore on abort.

Thanks :)

wata

29th September 2009, 11:08

using libx264 SVN-r1259 with MB-Tree disabled, why is the result file psy_rd=1.00:0.15 instead of psy_rd=1.0:0.0

LoRd_MuldeR

29th September 2009, 11:39

using libx264 SVN-r1259 with MB-Tree disabled, why is the result file psy_rd=1.00:0.15 instead of psy_rd=1.0:0.0

Because that's what the "--tune film" option does in the x264 command-line encoder. It should help to preserve more detail!

Unfortunately in Avidemux there are no GUI options to control Psy-Trellis, so I use a simple patch (http://mplayer.somestuff.org/misc/libx264/patches/psy_trellis.diff) for libx264 that changes the default Psy-Trellis from 0.0 to 0.15 ;)

(Note: You can still disable Psy-Trellis by setting Trellis to "0" in the Avidemx configuration dialog)

Also you shouldn't use the "MB-Tree disabled" build, except for testing purposes. The new MB-Tree RC greatly improves the overall quality in many situations...

wata

29th September 2009, 12:44

i am not ready to test/try new stuff yet
anyway i go back to avidemux_2.5_r5104_full_win32.zip, which use the same version of x264 as current megui (r1183)
i grab your compile of r1183 for core2 cpu, again Psy-Trellis increase from 0.0 to 0.15
it may help to preserve more detail but at the same time filesize increase too (5-6%) with the same crf.

LoRd_MuldeR

29th September 2009, 13:51

anyway i go back to avidemux_2.5_r5104_full_win32.zip, which use the same version of x264 as current megui (r1183)

You shouldn't use that outdated version! Get Avidemux r5341, it ships with an unpatched and (almost) up-to-date libx264 build ;)

Also MeGUI uses x264 r1259 now. If your MeGUI doesn't update via auto-update you probably didn't adjust the update URL to the new server.

http://kurtnoise.free.fr/MeGUI/

i grab your compile of r1183 for core2 cpu, again Psy-Trellis increase from 0.0 to 0.15

Yes, that's exactly how it is supposed to be. However you should grab the r1259 build now!

it may help to preserve more detail but at the same time filesize increase too (5-6%) with the same crf.

It has been explained about one million times why CRF can not be used as a "quality -vs- size" measure :rolleyes:

If you get a bigger file and better quality, how do you want to decided whether the increase in file size was worth the increase in quality or not ???

Yes, you can't :eek:

So if you want to compare setting A against setting B (e.g. Psy-Trellis 0.15 -vs- 0.0), you must visually compare files of identical size. So use 2-Pass mode for this kind of test!

And if it turns out that Psy-Trellis gives better quality at same size (which it probably will!), then that means Psy-Trellis will improve your encode in CRF mode as well.

However you may need to adjust your CRF value. But that's perfectly normal! CRF did always change when you change other settings ;)

In other words: With Psy-Trellis enabled and your CRF value properly re-adjusted, you should be able to get better quality at same size -or- same quality at an even lower size.

This applies to "filmic" content (and similar) at least. Psy-Trellis seems to be less suitable for "animated" content...

w0rd™

30th September 2009, 19:43

I've got 2.51 installed, just downloaded 2.51r5341, before I run it, just wondering about a few quick things, thought I might ask here.

If I have some xvid avi files, and I cut them in avidemux, and leave vid/audio same, but change container to .mkv, does that do anything, or just basically changes the extension to mkv, like one could do within windows?

Also, is there another way to create a job list, does one always have to fill out the file name, file extension and save location manually, for every file added?
It's just usually with other programs that have batch processing, it usually automatically inputs the same file name+extension, and remembers last save folder, but avidemux doesn't seem to do this. It could take a while to do this for many files.

Thanks.

LoRd_MuldeR

30th September 2009, 20:20

If I have some xvid avi files, and I cut them in avidemux, and leave vid/audio same, but change container to .mkv, does that do anything, or just basically changes the extension to mkv, like one could do within windows?

Of course it does do something! And nope, it does not just change the extension!

Changing the extension can be done in Explorer using the "rename" function. But renaming an AVI file to "foo.mkv" doesn't make it an MKV file. It's still an AVI file, only with "wrong" extension :sly:

However if you open an existing AVI file in Avidemux and then save it to an MKV file (that means "Format" is set to "MKV" in the left side menu), then it will be properly re-muxed to a MKV container.

Re-muxing doesn't change the video (it won't re-encode!), but will change the container. In this case from AVI to Matroska (MKV).

Also, is there another way to create a job list, does one always have to fill out the file name, file extension and save location manually, for every file added?
It's just usually with other programs that have batch processing, it usually automatically inputs the same file name+extension, and remembers last save folder, but avidemux doesn't seem to do this. It could take a while to do this for many files.

Avidemux does offer powerful scripting capabilities. See the Avidemux Wiki for details please!

Command-Line usage:
http://avidemux.org/admWiki/index.php?title=Command_line_usage

Scripting:
http://avidemux.org/admWiki/index.php?title=Scripting

Scripting Tutorial:
http://avidemux.org/admWiki/index.php?title=Scripting_tutorial

w0rd™

2nd October 2009, 07:53

Thanks LM.

I knew that changing extension in Explorer just changes the name and not the actual type, that's why I was curious about Ademux if it remuxed into an actual mkv.
I read that it's better to use mkv instead of avi for xvid/mp3, so that why I want to remux them all at the same time as I have to cut out bits of each video anyway, so I'm hoping its true.

About the scripting, that really is out of my depth, that's why I use the GUI. Even though I don't really understand it, I couldn't tell where it mentions auto filling a job control, or maybe that's just because I couldn't understand much :o

I'm basically really wanting it to act like the VDub job control.
That is, I open clip1.avi, edit out the cuts, choose save, and it automatically adds "clip1.avi" as the filename(or mkv if chosen) and opens the last folder, so basically one just have to press the save button (adding it to the job list).

If there's a simple method using scripts, that maybe I could follow, specifically to autofill the filenames of the clip opened, and the destination, from within the GUI, then it would be great.

Would be even better if something like the vdub method could be added to the gui, just as the basic method, but then again, I wouldn't know how software works behind the scenes :cool:

LoRd_MuldeR

2nd October 2009, 12:56

I knew that changing extension in Explorer just changes the name and not the actual type, that's why I was curious about Ademux if it remuxed into an actual mkv.
I read that it's better to use mkv instead of avi for xvid/mp3, so that why I want to remux them all at the same time as I have to cut out bits of each video anyway, so I'm hoping its true.

MPEG-4 ASP (Xvid, DivX, etc) video and MP3 audio in an AVI container is perferctly fine. In fact it's the preferred combination, even for hardware playback!
Older standalone players often support the AVI container, but do not support the MKV or MP4 container!

H.264/AVC (e.g. x264) is a different story. It can be stored in AVI and with software players there usually is no problem at all.
However for hardware players H.264 must be stored in MP4, M2TS or MKV container. Support for MKV in standalones is getting more widespread now...

Anyway, for re-muxing AVI files to MKV I would use MKVToolnix (http://www.videohelp.com/tools/MKVtoolnix) instead of Avidemux ;)

LoRd_MuldeR

5th October 2009, 13:38

Avidemux 2.5 SVN-r5369 (2009-10-05)
http://www.avidemux.org/

Revision 5369 (05 Oct 2009)
# Updated ATK to version 1.28.0-1.
# Updated Fontconfig to version 2.7.3-1.
# Updated GLib to version 2.22.1-1.
# Updated GTK+ to version 2.18.1-1.
# Updated libpng to version 1.2.39-1.
# Updated Libxml2 to version 2.7.4-1.
# Updated NSPR to version 4.8.
# Updated opencore-amr to version 0.1.2.
# Updated Qt to version 4.5.3.
# Updated x264 to r1271.

5369 - [win32] update installer to support latest dependencies
5362 - [macosx] build script tweaks by surfer
5361 - [x264] compilation fix for older API
5360 - [x264] support API version 76
5359 - [PO] SR translation by popac
5358 - [macosx] keep original ffmpeg library names on Mac
5350 - [backtrace] Better backtrace using glibc functions (backport from 2.6)
5349 - [Video/Filters] Move convolution filter to the sharpness category, closes #10
5348 - [Filter/Field] Cleanup/rename filters, ref #10
5347 - [macosx] fix reference to icon file
5341 - [win32] include new colour curve editor filter in Windows installer

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

LoRd_MuldeR

5th October 2009, 15:13

libx264 SVN-r1271:

libx264-r1271, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1271M-gcc434-core2-fprofiled.7z)
libx264-r1271, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1271M-gcc434-amdfam10-fprofiled.7z)
libx264-r1271, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1271M-gcc434-pentium3-fprofiled.7z)
libx264-r1271, MinGW GCC 4.3.4, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1271M-gcc434-noasm-fprofiled.7z)

libx264 SVN-r1271 using four slices:

libx264-r1271, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1271M-slices-gcc434-core2-fprofiled.7z)
libx264-r1271, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1271M-slices-gcc434-amdfam10-fprofiled.7z)
libx264-r1271, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1271M-slices-gcc434-pentium3-fprofiled.7z)

libx264 SVN-r1271 with AutoVAQ enabled:

libx264-r1271, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1271M-autovaq-gcc434-core2-fprofiled.7z)
libx264-r1271, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1271M-autovaq-gcc434-amdfam10-fprofiled.7z)
libx264-r1271, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1271M-autovaq-gcc434-pentium3-fprofiled.7z)

libx264 SVN-r1271 with MB-Tree disabled:

libx264-r1271, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1271M-nombtree-gcc434-core2-fprofiled.7z)
libx264-r1271, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1271M-nombtree-gcc434-amdfam10-fprofiled.7z)
libx264-r1271, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1271M-nombtree-gcc434-pentium3-fprofiled.7z)

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

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

Avidemux has been updated for the new x264 API (http://forum.doom9.org/showthread.php?t=149593), finally. Please update Avidemux before installing the core-76 builds of libx264!

boyumeow

6th October 2009, 05:25

LoRd_MuldeR

6th October 2009, 14:48

Hi LRMR, I have a small little question for U... I think I understand that ur compiled libx264 (the 2nd, 3rd and 4th) is with some added modification, how about the first 1 listed, what does or does it not contains? I'm not sure U might have explain it before but I think I missed it. Sorry about my english if U do not understand, I believe sometimes or most of the time I have problem in explaining to people in written words. Thanks.

Each download (7z file) contains a "patches.tar" file that contains all the patches I used for the individual build. Just have a look ;)

Anyway, these patches are used in all of my builds:
fast_firstpass.diff: Do exactly what x264.exe does, if the "--slow-firstpass" param isn't specify. Speeds up the first pass of a 2-Pass encode significantly.
print_params.diff: Make x264 be more verbose on the Avidemux log. This is especially useful if people are submitting Avidemux crash log files and ask for help.
psy_trellis.diff: Raise the default Psy-Trellis strength from 0.0 to 0.15. This is the same that will happen if you use x264.exe's "--tune film" parameter.

These patches are only used in some of my builds and only when explicitly stated:
no_mbtree.diff: Disable the MB-Tree Rate Control. Enabled by default.
four slices.diff: Encode with four slices. Default is one (multi-slices disabled).
auto_vaq.diff: Use AutoVAQ instead of "normal" VAQ, iff AQ is enabled.

I recommend going with one of the builds from the first list (hint: pick the one that suits your CPU best). The other builds are intended for testing purposes.

Multiple slices are mainly interesting for BD authoring, AutoVAQ is an alternative (but not always better) AQ algorithm and disabling MB-Tree RC will use the "old" RC algorithm.

Please note: If Avidemux did offer all those options at run-time, we wouldn't need various builds. But it does not do so yet, so we need those patches...

Brazil2

7th October 2009, 13:12

Multiple slices are mainly interesting for BD authoring
But in this specific case isn't NAL_HRD required as well ?

LoRd_MuldeR

7th October 2009, 13:19

But in this specific case isn't NAL_HRD required as well ?

Yes, NAL_HRD would be required for full BD compatibility too, but x264 can not do it yet. So let's wait for the commit ;)

I know there's an experimental NAL_HRD patch floating around, but according to the devs, 100% correct NAL_HRD is only possible after the latest x264 API change.

As far as I know, the "old" patch was not updated for the "new" API yet, although some people made a working build somehow. Good? Well, I will simply wait...

LoRd_MuldeR

7th October 2009, 15:10

libx264 SVN-r1278:

libx264-r1278, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc434-core2-fprofiled.7z)
libx264-r1278, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc434-amdfam10-fprofiled.7z)
libx264-r1278, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc434-pentium3-fprofiled.7z)
libx264-r1278, MinGW GCC 4.3.4, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc434-noasm-fprofiled.7z)

libx264 SVN-r1278 using four slices:

libx264-r1278, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-slices-gcc434-core2-fprofiled.7z)
libx264-r1278, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-slices-gcc434-amdfam10-fprofiled.7z)
libx264-r1278, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-slices-gcc434-pentium3-fprofiled.7z)

libx264 SVN-r1278 with AutoVAQ enabled:

libx264-r1278, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-autovaq-gcc434-core2-fprofiled.7z)
libx264-r1278, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-autovaq-gcc434-amdfam10-fprofiled.7z)
libx264-r1278, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-autovaq-gcc434-pentium3-fprofiled.7z)

libx264 SVN-r1278 with MB-Tree disabled:

libx264-r1278, MinGW GCC 4.3.4, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-nombtree-gcc434-core2-fprofiled.7z)
libx264-r1278, MinGW GCC 4.3.4, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-nombtree-gcc434-amdfam10-fprofiled.7z)
libx264-r1278, MinGW GCC 4.3.4, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-nombtree-gcc434-pentium3-fprofiled.7z)

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

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

Brazil2

8th October 2009, 17:14

Are there any BT.709 <-> BT.601 conversion filters available for Avidemux ? And if so where can I find them ?

LoRd_MuldeR

8th October 2009, 17:17

The "Avisynth ColorYUV" filter should be able to do that, I think ;)

Brazil2

8th October 2009, 18:43

The "Avisynth ColorYUV" filter should be able to do that, I think ;)
That looks nice but I can't figure how to make a simple BT.709 -> BT.601 conversion with this filter. And yes, I've read the documentation about ColorYUV.
Any tips are welcome :)

LoRd_MuldeR

9th October 2009, 19:04

libx264 SVN-r1278:

libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc441-core2-fprofiled.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc441-amdfam10-fprofiled.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc441-pentium3-fprofiled.7z)
libx264-r1278, MinGW GCC 4.4.1, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc441-noasm-fprofiled.7z)

libx264 SVN-r1278 using four slices:

libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-slices-gcc441-core2-fprofiled.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-slices-gcc441-amdfam10-fprofiled.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-slices-gcc441-pentium3-fprofiled.7z)

libx264 SVN-r1278 with AutoVAQ enabled:

libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-autovaq-gcc441-core2-fprofiled.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-autovaq-gcc441-amdfam10-fprofiled.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-autovaq-gcc441-pentium3-fprofiled.7z)

libx264 SVN-r1278 with MB-Tree disabled:

libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-nombtree-gcc441-core2-fprofiled.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-nombtree-gcc441-amdfam10-fprofiled.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-nombtree-gcc441-pentium3-fprofiled.7z)

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

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

Re-compiled r1278 with GCC 4.4.1 TDM-2 (http://www.tdragon.net/recentgcc/), which is supposed to fix the "increased CPU usage" bug in TDM's previous GCC 4.4.1 release.

Brazil2

9th October 2009, 22:27

Are there any advantages with these new builds compiled with GCC 4.4.1 compared to the previous ones that you have compiled with GCC 4.3.4 since it's the same version of x264 ?

LoRd_MuldeR

9th October 2009, 23:31

Well, newer compiler versions hopefully produce (slightly) faster code and/or fix bugs of earlier compiler versions. But ideally there's no noteworthy difference for the user ;)

Unfortunately there is always the risk of regressions/miscompilation, so use the "new" builds with care and report any problems you may encounter...

LoRd_MuldeR

11th October 2009, 16:33

libx264 SVN-r1278:

libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc441-core2-fprofiled.try-2.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc441-amdfam10-fprofiled.try-2.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc441-pentium3-fprofiled.try-2.7z)
libx264-r1278, MinGW GCC 4.4.1, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1278M-gcc441-noasm-fprofiled.try-2.7z)

libx264 SVN-r1278 using four slices:

libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-slices-gcc441-core2-fprofiled.try-2.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-slices-gcc441-amdfam10-fprofiled.try-2.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-slices-gcc441-pentium3-fprofiled.try-2.7z)

libx264 SVN-r1278 with AutoVAQ enabled:

libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-autovaq-gcc441-core2-fprofiled.try-2.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-autovaq-gcc441-amdfam10-fprofiled.try-2.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-autovaq-gcc441-pentium3-fprofiled.try-2.7z)

libx264 SVN-r1278 with MB-Tree disabled:

libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-nombtree-gcc441-core2-fprofiled.try-2.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-nombtree-gcc441-amdfam10-fprofiled.try-2.7z)
libx264-r1278, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1278M-nombtree-gcc441-pentium3-fprofiled.try-2.7z)

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

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

Re-compiled r1278 with GCC 4.4.1, again. This time I included a patch (http://pastebin.ca/1612400) to avoid miscompilation with GCC 4.4.x, as suggested here (http://forum.doom9.org/showthread.php?p=1333035#post1333035).
So if you used one of the previous GCC 4.4.1 builds, then you are urged to update now!
I'm not sure whether the GCC 4.3.4 or GCC 4.3.3 builds were effected too, as the visual difference is generally unnoticeable...

Brazil2

12th October 2009, 10:24

Well, newer compiler versions hopefully produce (slightly) faster code and/or fix bugs of earlier compiler versions. But ideally there's no noteworthy difference for the user ;)
I've done some tests and I can't notice any speed difference between "libx264-r1278, MinGW GCC 4.3.4, optimized for Core 2 (http://forum.doom9.org/showpost.php?p=1332340&postcount=1329)" and "libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://forum.doom9.org/showpost.php?p=1333497&postcount=1336)".

There is however a huge speed difference between Avidemux 2.5 using "libx264-r1173, MinGW GCC 4.4.0, optimized for Core 2 (http://forum.doom9.org/showpost.php?p=1300329&postcount=1162)" and Avidemux 2.5.1 SVN-r5369 using any of your libx264 SVN-r1278 optimized for Core 2 builds with MB-Tree disabled.
For instance, with the same given source and the exact same settings Avidemux 2.5 is encoding at about 14 fps average while Avidemux 2.5.1 is encoding at about 10 fps average. Although I've noticed a short delay at the beginning of the encoding with v2.5.1 before the counters start to run while it's instant with v2.5. Maybe because of the lookahead ? But I thought this feature was related to MB-Tree only, I might be wrong though.

And I have some improvement suggestions for future versions of Avidemux:
Port ColorMatrix to Avidemux filters
Accept MP2 as an allowed format for external audio track
Allow AC3 to be muxed in MP4

LoRd_MuldeR

12th October 2009, 10:30

I've done some tests and I can't notice any speed difference between "libx264-r1278, MinGW GCC 4.3.4, optimized for Core 2 (http://forum.doom9.org/showpost.php?p=1332340&postcount=1329)" and "libx264-r1278, MinGW GCC 4.4.1, optimized for Core 2 (http://forum.doom9.org/showpost.php?p=1333497&postcount=1336)".

Not surprising!

Or did you really expect an enormous speed-up between GCC 4.3.4 and 4.4.1? If at all, we can expect a very subtle speed-up from compiler optimizations ;)

All the performance-critical code in x264 is hand-optimized ASM anyway...

There is however a huge speed difference between Avidemux 2.5 using "libx264-r1173, MinGW GCC 4.4.0, optimized for Core 2 (http://forum.doom9.org/showpost.php?p=1300329&postcount=1162)" and Avidemux 2.5.1 SVN-r5369 using any of your libx264 SVN-r1278 optimized for Core 2 builds with MB-Tree disabled.
For instance, with the same given source and the exact same settings Avidemux 2.5 is encoding at about 14 fps average while Avidemux 2.5.1 is encoding at about 10 fps average. Although I've noticed a short delay at the beginning of the encoding with v2.5.1 before the counters start to run while it's instant with v2.5. Maybe because of the lookahead ? But I thought this feature was related to MB-Tree only, I might be wrong though.

Are you sure you are really using identical settings ???

In my latest builds there are workarounds to use even "slower" settings than those available in Avidemux. Those are triggered by certain combinations ;)

Please use Avinaptic or MediaInfo to read out the actual x264 settings from the encoded file!

BTW: The startup delay is caused by MB-Tree and/or Threaded Look-ahead. That's perfectly normal. It just didn't exist in older x264 builds.

And I have some improvement suggestions for future versions of Avidemux:
Port ColorMatrix to Avidemux filters
Accept MP2 as an allowed format for external audio track
Allow AC3 to be muxed in MP4

You better put feature requests to the official Avidemux board. The developers won't hear you here...

Brazil2

12th October 2009, 11:11

Are you sure you are really using identical settings ???
I've made a profile that I'm using with both versions.

In my latest builds there are workarounds to use even "slower" settings than those available in Avidemux. Those are triggered by certain combinations ;)

Please use Avinaptic or MediaInfo to read out the actual x264 settings from the encoded file!
Ah yep, subme=9 with r1173 and subme=10 with r1278. I guess that's one of your workarounds since the GUI doesn't allow to select subme=10 yet :)

BTW: The startup delay is caused by MB-Tree and/or Threaded Look-ahead. That's perfectly normal. It just didn't exist in older x264 builds.
As I've said I've used the NON MB-Tree build for the comparison because there was no MB-Tree in older builds, obviously.
The subme might explain the speed difference but where the short delay comes from ?
mbtree=0 and there is no rc_lookahead shown in the encoding settings.

You better put feature requests to the official Avidemux board. The developers won't hear you here...
No offense but these forums look like a no man's land to me so maybe I'll have more luck talking to one of the saints who can talk to God himself ;)

DarkZell666

12th October 2009, 11:15

No offense but these forums look like a no man's land to me so maybe I'll have more luck talking to one of the saints who can talk to God himself ;)

Not having 1000's of posts per day doesn't mean it's dead :rolleyes:. There are new topics and answers every day :)

LoRd_MuldeR

12th October 2009, 11:18

Ah yep, subme=9 with r1173 and subme=10 with r1278. I guess that's one of your workarounds since the GUI doesn't allow to select subme=10 yet :)

SubME=9 + Trellis=2 + ME=UMH (or higher) will trigger SubME=10 in my builds. That explains the speed-difference indeed.

As I've said I've used the NON MB-Tree build for the comparison because there was no MB-Tree in older builds, obviously.
The subme might explain the speed difference but where the short delay comes from ?
mbtree=0 and there is no rc_lookahead shown in the encoding settings.

Threaded Lookahead (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=5b3c89c592e412fc02fd8001ee361ea50c249153) is enabled, even with MB-Tree RC disabled. Right?

No offense but these forums look like a no man's land to me so maybe I'll have more luck talking to one of the saints who can talk to God himself ;)

Both, Mean and Gruntster, are visiting the Avidemux board regularly. So that's your best chance to get any feature requests done ;)

There also is a non-public bug tracker that is maintained!

LoRd_MuldeR

12th October 2009, 11:46

libx264 SVN-r1286:

libx264-r1286, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1286M-gcc441-core2-fprofiled.7z)
libx264-r1286, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1286M-gcc441-amdfam10-fprofiled.7z)
libx264-r1286, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1286M-gcc441-pentium3-fprofiled.7z)
libx264-r1286, MinGW GCC 4.4.1, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1286M-gcc441-noasm-fprofiled.7z)

libx264 SVN-r1286 using four slices:

libx264-r1286, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1286M-slices-gcc441-core2-fprofiled.7z)
libx264-r1286, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1286M-slices-gcc441-amdfam10-fprofiled.7z)
libx264-r1286, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1286M-slices-gcc441-pentium3-fprofiled.7z)

libx264 SVN-r1286 with AutoVAQ enabled:

libx264-r1286, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1286M-autovaq-gcc441-core2-fprofiled.7z)
libx264-r1286, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1286M-autovaq-gcc441-amdfam10-fprofiled.7z)
libx264-r1286, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1286M-autovaq-gcc441-pentium3-fprofiled.7z)

libx264 SVN-r1286 with MB-Tree disabled:

libx264-r1286, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1286M-nombtree-gcc441-core2-fprofiled.7z)
libx264-r1286, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1286M-nombtree-gcc441-amdfam10-fprofiled.7z)
libx264-r1286, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1286M-nombtree-gcc441-pentium3-fprofiled.7z)

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

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

There still is a potential miscompilation with GCC 4.4.x, use those builds with care and report any problems you may encounter...

Brazil2

12th October 2009, 12:28

SubME=9 + Trellis=2 + ME=UMH (or higher) will trigger SubME=10 in my builds.
That's the settings I'm using :)
I'll try another comparison with trellis=1 then to force subme=9 in both cases.

Threaded Lookahead (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=5b3c89c592e412fc02fd8001ee361ea50c249153) is enabled, even with MB-Tree RC disabled. Right?
OK then. But still rc_lookahead parameter is not shown at all in the encoding settings when MB-Tree is disabled. I don't know if it's a x264 kind of 'bug' or if it's related to your builds only.

Both, Mean and Gruntster, are visiting the Avidemux board regularly. So that's your best chance to get any feature requests done ;)
Done (http://avidemux.org/admForum/viewtopic.php?id=6767).
And you already solved one of my requests about MP2, bah stupid me I should have thought that MP2 or MP3 is still MPEG audio pfff...

Until we eliminate all such uses of 2D arrays, I don't trust GCC 4.4 to produce valid output.
I see. Thanks for info. Awaiting official commit :)
Or still compile your builds with GCC 4.3.4 in the meanwhile since they seem to work pretty fine ;)

LoRd_MuldeR

12th October 2009, 14:31

Or still compile your builds with GCC 4.3.4 in the meanwhile since they seem to work pretty fine ;)

Not really. We had broken GCC 4.3.4 builds too:

1281 builds:
x264.nl gcc 3.4.6 -- OK
BugMaster gcc 4.3.3 TDM -- OK
BugMaster gcc 4.3.4 20090220 (prerelease) (x32.generic.Komisar) (not profiled) -- OK
Komisar gcc 4.3.4 (x86_64.core2.Komisar) -- OK
Komisar gcc 4.3.4 (x86.generic.Komisar) -- OK
Komisar gcc 4.4.1 (x86.core2.Komisar) -- FAILURE
JEEB gcc 4.3.4 20090220 (prerelease) (x64.generic.Komisar) -- FAILURE
techouse gcc 4.4.1 (x86_64.core2.Komisar) -- FAILURE
rack04 (patched build) gcc 4.3.4 (x86.core2.Komisar) -- FAILURE

gcc sucks again... :eek:

Anyway, the fix for the miscompilation problem has now been committed officially:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=3cb2d8b8be36badcbef37b336b9e06867c9ab91d

So I will make new builds as soon as I return back home. But this won't happen before tomorrow...

LoRd_MuldeR

13th October 2009, 08:58

libx264 SVN-r1292:

libx264-r1292, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1292M-gcc441-core2-fprofiled.7z)
libx264-r1292, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1292M-gcc441-amdfam10-fprofiled.7z)
libx264-r1292, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1292M-gcc441-pentium3-fprofiled.7z)
libx264-r1292, MinGW GCC 4.4.1, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1292M-gcc441-noasm-fprofiled.7z)

libx264 SVN-r1292 using four slices:

libx264-r1292, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1292M-slices-gcc441-core2-fprofiled.7z)
libx264-r1292, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1292M-slices-gcc441-amdfam10-fprofiled.7z)
libx264-r1292, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1292M-slices-gcc441-pentium3-fprofiled.7z)

libx264 SVN-r1292 with AutoVAQ enabled:

libx264-r1292, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1292M-autovaq-gcc441-core2-fprofiled.7z)
libx264-r1292, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1292M-autovaq-gcc441-amdfam10-fprofiled.7z)
libx264-r1292, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1292M-autovaq-gcc441-pentium3-fprofiled.7z)

libx264 SVN-r1292 with MB-Tree disabled:

libx264-r1292, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1292M-nombtree-gcc441-core2-fprofiled.7z)
libx264-r1292, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1292M-nombtree-gcc441-amdfam10-fprofiled.7z)
libx264-r1292, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1292M-nombtree-gcc441-pentium3-fprofiled.7z)

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

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

Miscompilation with GCC 4.4.x should be fixed (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=287641a7c54d525e0eb74925431541ffb5f9471d) now, finally. So if you used one of the previous builds, you are urged to update now!

LoRd_MuldeR

19th October 2009, 23:04

libx264 SVN-r1301:

libx264-r1301, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc441-core2-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc441-amdfam10-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc441-pentium3-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc441-noasm-fprofiled.7z)

libx264 SVN-r1301 using four slices:

libx264-r1301, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1301M-slices-gcc441-core2-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1301M-slices-gcc441-amdfam10-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1301M-slices-gcc441-pentium3-fprofiled.7z)

libx264 SVN-r1301 with AutoVAQ enabled:

libx264-r1301, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1301M-autovaq-gcc441-core2-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1301M-autovaq-gcc441-amdfam10-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1301M-autovaq-gcc441-pentium3-fprofiled.7z)

libx264 SVN-r1301 with MB-Tree disabled:

libx264-r1301, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1301M-nombtree-gcc441-core2-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1301M-nombtree-gcc441-amdfam10-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-76-r1301M-nombtree-gcc441-pentium3-fprofiled.7z)

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

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

These builds were patched from core-78 to core-76 in order to make them work with the latest Avidemux build! Hope I didn't break it ^^

LoRd_MuldeR

19th October 2009, 23:48

libx264 SVN-r1301:

libx264-r1301, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc442-core2-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc442-amdfam10-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc442-pentium3-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc442-noasm-fprofiled.7z)

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

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

New experimental builds using Komisar's MinGW/GCC 4.4.2 compiler. Use with care any report any problem you may encounter...

lych_necross

23rd October 2009, 07:31

@LoRd_MuldeR: Aside from this forum, I also browse the Avidemux for and I have a question for you about your libx264 svn-r1301 builds. On this thread, you have posted:
libx264 SVN-r1301:

libx264-r1301, MinGW GCC 4.4.2, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc442-core2-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.2, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc442-amdfam10-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.2, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc442-pentium3-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.2, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc442-noasm-fprofiled.7z)

But on the other forum you posted:
libx264 SVN-r1301:

libx264-r1301, MinGW GCC 4.4.1, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc441-core2-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc441-amdfam10-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, optimized for Pentium III (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc441-pentium3-fprofiled.7z)
libx264-r1301, MinGW GCC 4.4.1, without ASM (slow!) (http://mplayer.somestuff.org/misc/libx264/libx264-76-r1301M-gcc441-noasm-fprofiled.7z)

Which one should we/I be testing? The GCC 4.4.1 or 4.4.2?