Avidemux (with emphasis on x264/h264 GUI)

[TheImperial2004]

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

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

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

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

???

[LoRd_MuldeR]

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

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

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

[TheImperial2004]

Sorry see my edited post ^^

[LoRd_MuldeR]

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

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

If your material is "true" interlaced (not Telecined), then you should consider using YADIF (preferably in "bob" mode) or TDeint. But for Telecined material stick with Decomb Telecide!

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

That's right. IMHO it doesn't make sense to print out "scan order" for progressive video. But maybe that's the scan order that would be used for psF (progressive with segmented frames).

[TheImperial2004]

not Telecined

How to find that out ?

[LoRd_MuldeR]

By looking at it. For example if you apply YADIF (in "Bob" mode!) and in the result there's actual motion between each pair of consecutive frames, then it was "true" interlaced.

But if the original was 24 fps progressive and had been telecined to 29.97 fps interlaced, there will still be only motion for 24 fps after you bobbed it 60 fps ;)

Also a plain IVTC (Inverese Telecine) filter would simply fail to deinterlace a "true" interlaced video. But Decomb Telecide probably wouldn't fail, because it has additional post-processing.

Anyway, you can also post a short sample of your unprocessed(!) source and I'll tell you whether it's Telecined or not...

[TheImperial2004]

I used AviDemux to "Copy" 10MB of the video stream into a nice MPG container ^^ Everyday I love AviDemux even more ^^

Here (http://theimperial2004.googlepages.com/FFX7.mpg)

I used YADIF on this specific clip and I noticed that annoying scanning lines are gone and I saved around half the file size using the same x264 settings compared to encoding without deinterlacing ^^

BTW : Can't we just use YADIF to Deinterlace both types of streams ?

[LoRd_MuldeR]

BTW : Can't we just use YADIF to Deinterlace both types of streams ?

That would be the "dumb" method. If the video is Telecined, then the original(!) progressive frames can be reconstructed by an IVTC filter, just by putting together the fields in the proper way.

Since a deinterlacer like YADIF unavoidably interpolates, you'd be throwing away a lot of quality for no benefit! However if the video is "true" interlaced, then IVTC cannot be used and a dinterlacer is needed.

Your video appears to be interlaced. And it's full of ugly aliasing by the way! I bobbed it with YADIF:
http://www.mediafire.com/?nx43kztknrm

[TheImperial2004]

I bobbed it with YADIF and I got rid of the "scanning lines" and saved half the space .. That means YADIF got rid of the "useless" frames . No ?

What will happen if I just encoded the video using x264 without Deinterlacing it (In a tech. point of view) ?

P.S. : I didn't create this video , so blame S.E. ;)

[LoRd_MuldeR]

I bobbed it with YADIF and I got rid of the "scanning lines" and saved half the space .. That means YADIF got rid of the "useless" frames . No ?

No! Yadif will take each field and interpolate the "missing" lines to get a full frame.

This way we get from 29.97 interlaced frames per second (actually 59.940 fields per second) to 59.940 progressive frames per second.

Details: http://trac.handbrake.fr/wiki/yadif

What will happen if I just encoded the video using x264 without Deinterlacing it (In a tech. point of view) ?

If you encode interlaced video in progressive mode, the fields will be weaved together and treated as progressive, which actually destroys the content!

So if you want to retain the interlacing, you must encode in "interlaced" mode.

x264 does support interlaced encoding, but it's less efficient and it requires deinterlacing at playback time (given you are using an LCD screen or projector).

P.S. : I didn't create this video , so blame S.E. ;)

Okay, I do ;)

[LoRd_MuldeR]

libx264 SVN-r1239:

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


libx264 SVN-r1239 without MB-Tree Ratecontrol:

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


libx264 SVN-r1239 with AutoVAQ enabled:

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


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

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

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

[LoRd_MuldeR]

Avidemux 2.5 SVN-r5281 (2009-08-29)
http://www.avidemux.org/

Revision 5281 (29 Aug 2009)
# Updated x264 r1240.

5281 - [cli] modify behaviour of save-jpg parameter to recognise selection (fixes #14)
5280 - [cli] signal that progress dialog is always alive for CLI since it isn't displayed and can't be aborted
5279 - [flux] correctly initialise fluxsmooth filter (regression introduced in 2.5.0; fixes #23)
5278 - [qt] add responder for cancel button on progress dialog (fixes #24)
5277 - [misc] remove dead code
5276 - [filter] reinstate partial filter support (fixes #28)
5275 - [Flv] Fix extraheader + offset in audio, fix #26
5274 - [Flv] Backport some code from 2.6 to allow new codecs in flv, refs #26
5273 - [ffmpeg] update FFmpeg to r19733 & libswscale r29569

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

[TheImperial2004]

Updated x264 r1240.

What ??!! It is not available here (http://mplayer.somestuff.org/misc/libx264/) ! @_@

[LoRd_MuldeR]

What ??!! It is not available here (http://mplayer.somestuff.org/misc/libx264/) ! @_@

If you look at the x264 changelog (http://mirror01.x264.nl/x264/changelog.txt), you will see that there is no relevant difference between r1239 and r1240 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=35627b63c31bcd143413c10dce1ead8015448f7b) for us ;)

So the libx264 binary of r1240 probably would be bit-identical to r1239. Of course I'll make fresh builds as soon as there's a relevant change...

(Anyway, I can't make fresh builds day and night - only at night when I'm awake. So you may need to be patient sometimes ^^)

[LoRd_MuldeR]

libx264 SVN-r1243:

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


libx264 SVN-r1243 using four slices:

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


libx264 SVN-r1243 with AutoVAQ enabled:

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


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

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

Now with support for slices (http://img525.imageshack.us/img525/3856/slices.jpg), for details have a look at this (http://forum.doom9.org/showthread.php?p=1320574#post1320574) thread! Patched back to core 72 to make it work with current (http://forum.doom9.org/showpost.php?p=1319838&postcount=1262) Avidemux.

[LoRd_MuldeR]

Updated the builds in my previous post (http://forum.doom9.org/showpost.php?p=1320672&postcount=1265) with a more "safe" patch, I hope ;)

[TheImperial2004]

I understand that Slices is a feature for stand-alone players only , No ?

[LoRd_MuldeR]

I understand that Slices is a feature for stand-alone players only , No ?

Well, it's not only for standalone players. Multi-sliced streams allow slice-bases multithreading (instead of frame-based multithreading), which may be used by software decoders too.
Remember, there was a time not too long ago when libavcodec (this includes ffdshow and friends) only supported multithreaded decoding for multi-sliced H.264 streams.
However the most important reason why people need multi-sliced encoding nowadays is BluRay support. The BluRay specs require that 4+ slices must be used (at least for Level 4.1).

Anyway, the rule of thumb says: Don't use slices, unless you have a very good reason to do so. That's because slices hurt coding efficiency!

[Dark Shikari]

Well, it's not only for standalone players. Multi-sliced streams allow slice-bases multithreadingNot with x264's streams, which have deblocking on between slices. At least it won't work with ffmpeg.

[LoRd_MuldeR]

Not with x264's streams, which have deblocking on between slices. At least it won't work with ffmpeg.

I thought BluRay requires multiple slices in order to allow slice-based multithreading in the playback device. So now you are saying this won't work? Problem for the BD guys? :scared:

Or it just doesn't work with ffmpeg's implementation of slice-based multithreading? And what happens if I turn off deblocking ???

[Dark Shikari]

I thought BluRay requires multiple slices in order to allow slice-based multithreading in the playback device. So now you are saying this won't work? Problem for the BD guys?The BD specification does not require that the deblocking filter control be set to "2" (deblocking off between slices).

[TheImperial2004]

there was a time not too long ago when libavcodec (this includes ffdshow and friends) only supported multithreaded decoding for multi-sliced H.264 streams.

So , I can now rely on Libavcodec to decode 1080p-sliced contect with the same performance of FFMpeg-mt or CoreAVC ?

[LoRd_MuldeR]

So , I can now rely on Libavcodec to decode 1080p-sliced contect with the same performance of FFMpeg-mt or CoreAVC ?

Neither ffmpeg-MT nor CoreAVC need slices to enable multi-threaded decoding. You can safely turn off slices, if these are your decoders :)

Of course they would deal with slices just fine. But why use slices (and sacrifice some compression efficiency) when you have no valid reason to do so?

BluRay compliance would be a valid reason to encode with slices, but only if you are targeting for BluRay authoring...

The BD specification does not require that the deblocking filter control be set to "2" (deblocking off between slices).

But what are slices good for, if they can't be used for slice-based multithreading? Maybe the BD specs just missed that part? :confused:

[TheImperial2004]

Perhaps I didn't use the right words >_< Sorry ;)

Rephrase :

I use FFMpeg-mt to decode 1080p contect right now , because Libavcodec can't utilize both cores . You said that Libavcodec does support multi-threaded decoding for Sliced-Encoded contect . So , If I used Libx264 to create a-four-sliced-1080p-video , will Libavcodec decode that using both cores ?

[LoRd_MuldeR]

You said that Libavcodec does support multi-threaded decoding for Sliced-Encoded contect . So , If I used Libx264 to create a-four-sliced-1080p-video , will Libavcodec decode that using both cores ?

In theory yes. But it seems this won't work with x264-encoded streams, even if they are multi-sliced. See what Dark Shikari just explained...

http://forum.doom9.org/showpost.php?p=1321100&postcount=1269

[TheImperial2004]

In theory yes. But it seems this won't work with x264-encoded streams, even if they are multi-sliced. See what Dark Shikari just explained...

Is that an x264 restriction or Libavcodec's ?

[LoRd_MuldeR]

Is that an x264 restriction or Libavcode's ?

Ha, good question :D

Should x264 create sliced streams that don't have deblocking on between slices -or- should libavcodec be able to use slice-based multithreading even if deblocking is on between slices?

I assume a ffmpeg/libavcodec developer and a x264 developer would give different answer to this question ^^

[TheImperial2004]

Should x264 create sliced streams that don't have deblocking on between slices -or- should libavcodec be able to use slice-based multithreading even if deblocking is on between slices?


Let's wait and see how is this gonna unfold http://forum.doom9.org/images/smilies/biggrin.gif

[LoRd_MuldeR]

Let's wait and see how is this gonna unfold http://forum.doom9.org/images/smilies/biggrin.gif

Well, I assume nobody will care about this, because ffmpeg/libavcodec does support frame-based multithreading for quite some time now (in the ffmpeg-MT branch) and hence doesn't need slice-based multithreading any longer. Also the way x264 creates sliced steams seems to be sufficient for BD compliance. So actually there's no need to change anything right now...

[Guest]

Any 4-slice samples from x264 available? I'd like to test the Nvidia GPU decoder with it.

I know, wrong thread. Strike me. :)

[LoRd_MuldeR]

Any 4-slice samples from x264 available? I'd like to test the Nvidia GPU decoder with it.

I know, wrong thread. Strike me. :)

I can upload one, please wait a moment...

[LoRd_MuldeR]

Any 4-slice samples from x264 available? I'd like to test the Nvidia GPU decoder with it.

I know, wrong thread. Strike me. :)
I can upload one, please wait a moment...

Here we go:
http://www.mediafire.com/file/nlz11di0d3m/black_new_sliced.rar

[TheImperial2004]

in the ffmpeg-MT branch

I just wanted to use multi-threaded decoding with MPlayer SVN on Ubuntu . As it comes with FFMpeg not FFMpeg-MT . Since I mentioned that , I tried every procedure to compile MPlayer to use FFMpeg-MT to decode H.264 1080p , But I failed every time (Ubuntu) . It still uses only one core !

[LoRd_MuldeR]

I just wanted to use multi-threaded decoding with MPlayer SVN on Ubuntu . As it comes with FFMpeg not FFMpeg-MT . Since I mentioned that , I tried every procedure to compile MPlayer to use FFMpeg-MT to decode H.264 1080p , But I failed every time (Ubuntu) . It still uses only one core !

I can't really help you with compiling MPlayer on Ubuntu, but the MPlayer Mailing List (https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users) may be the appropriate place to ask for help with compilation problems.

MPlayer with FFmpeg-MT for Win32 is available here:
http://kovensky.project357.com/

[BigDid]

...
MPlayer with FFmpeg-MT for Win32 is available here:
http://kovensky.project357.com/
Hi,

And I confirm there are viewing problems for mpeg2 sources (only) with this MT build.

...
I know, wrong thread. Strike me. :)

Oh boy, already had a storm and rain yesterday, please no snow :D

did

[TheImperial2004]

I reverted back to Windows 7 just because of this very issue . They said that VLC has similar features to FFDShow , Multi-threading is not one of them though ... Nothing wants to work . I spent hours in checking and building from source , just to realize that it doesn't want to work !

MPlayer with FFmpeg-MT for Win32 is available here

I use FFDShow with MT under Windows and that is pretty good ^_^ I was woundering about Linux .. We've got an excellent Video Editing / Encoding program that can run "natively" under Linux which is AviDemux ;) Too shame that we don't have a fast decoder like FFDShow !

[LoRd_MuldeR]

Too shame that we don't have a fast decoder like FFDShow !

FFdshow basically is a wrapper to make ffmpeg/libavcodec available for DirectShow applications under Windows. However be aware that FFmpeg(-MT) originates from the Linux world ;)

I agree that the Linux distributions available nowadays make it very easy to get a running Linux system and ship with a lot of useful software (and software that isn't included can be obtained easily through the package manger). BUT: As soon as you want some software or driver (or even some "development" version) that is Non-standard for your current Linux distribution, things become very nasty again. You need to compile the stuff yourself, which means that you must be willing to do a lot of experimenting, read through more or less up-to-date guides, ask for help in forums and so on...

[Poutnik]

Is possible in Avidemux 2.5.1 to add a job to process queue in already running joblist ?
E.g. from other Avidemux instance ?

[LoRd_MuldeR]

Is possible in Avidemux 2.5.1 to add a job to process queue in already running joblist ?
E.g. from other Avidemux instance ?

I don't think so...

[TheImperial2004]

Its been quite a while since the last Windows build came out , I hope that gruntster is fine :)

[Poutnik]

I don't think so...

What a pity... :) it would be handy.

[LoRd_MuldeR]

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

Revision 5327 (09 Sep 2009)
# Updated x264 to r1251.

5327 - [xvid] destroy xvid context after each pass
5295 - [FLV] inverted check in audioEncoder, made flv output crash
5294 - [cmake] fix x264 detection
5293 - [cmake] detect new x264 api
5292 - [cmake] add pthread include directory where required
5283 - [Plugins] Build patch from D. Kapusta, cleanup the lib/lib32/lib64 mess
5282 - [Build] Patch from D. Kapusta that fixes a couple of loose ends + enable plugin build with the need to install main by symlinking the libs into the lib dir
5281 - [cli] modify behaviour of save-jpg parameter to recognise selection (fixes #14)

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

[TheImperial2004]

Wow Thanks ! Will we expect new customized x264 builds soon ?

[LoRd_MuldeR]

Wow Thanks ! Will we expect new customized x264 builds soon ?

In progress...

[LoRd_MuldeR]

libx264 SVN-r1251:

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


libx264 SVN-r1251 using four slices:

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


libx264 SVN-r1251 with AutoVAQ enabled:

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


libx264 SVN-r1251 with MB-Tree disabled:

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


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

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

Now with Threaded Lookahead (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=5b3c89c592e412fc02fd8001ee361ea50c249153) which greatly increases performance with lookahead-intensive settings. This is enabled by default.

[TheImperial2004]

Thanks Mulder !

BTW , I have a question !

Is AutoVAQ always enabled (Now that its officially commited) ? And how to revert to normal VAQ ?

In these builds :

libx264 SVN-r1251:
libx264-r1251, MinGW GCC 4.3.3, optimized for Core 2
libx264-r1251, MinGW GCC 4.3.3, optimized for K10
libx264-r1251, MinGW GCC 4.3.3, optimized for Pentium III
libx264-r1251, MinGW GCC 4.3.3, without ASM (slow!)

[lych_necross]

Thanks Mulder !

BTW , I have a question !

Is AutoVAQ always enabled (Now that its officially commited) ? And how to revert to normal VAQ ?

In these builds :
No. AutoVAQ is only enabled on Avidemux using Mulder's patched x264 build. I guess you could enable AutoVAQ using Avidemux's scripting capabilities, but thats OT. All other builds of x264 do not enable AutoVAQ by default.

[LoRd_MuldeR]

No. AutoVAQ is only enabled on Avidemux using Mulder's patched x264 build.

Correct. Since Avidemux doesn't offer any option to enable AutoVAQ currently the only way to get AutoVAQ in Avidemux is using the patched build.

But even with the AutoVAQ patched build, AutoVAQ will only be used (instead of "normal" VAQ), if AQ is enabled in the GUI.

So you can still disable AQ entirely, which of course would not a very good idea :eek:

(Also note that AutoVAQ has been offically committed, but is not the new default. x264's default AQ mode still is the "normal" VAQ algorithm)

I guess you could enable AutoVAQ using Avidemux's scripting capabilities, but thats OT.

I don't think so. Avidemux scripting engine uses XML syntax to load or save encoder configuration.

But there's just no option for AutoVAQ in the Schema (http://en.wikipedia.org/wiki/XML_Schema_(W3C)) yet. The "adaptiveQuantiserMode" element only allows "none" or "variance" ;)

We'll have to wait for Gruntster to update Avimdeux and include all the new x264 options. This will be some work, I guess...

<xs:element name="adaptiveQuantiserMode" minOccurs="0">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="variance"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

[lych_necross]

I don't think so. Avidemux scripting engine uses XML syntax to load or save encoder configuration.

But there's just no option for AutoVAQ in the Schema (http://en.wikipedia.org/wiki/XML_Schema_(W3C)) yet. The "adaptiveQuantiserMode" element only allows "none" or "variance" ;)

We'll have to wait for Gruntster to update Avimdeux and include all the new x264 options. This will be some work, I guess...

Darn it. I take it one just can't modify the schema to allow for this.

[LoRd_MuldeR]

Darn it. I take it one just can't modify the schema to allow for this.

Well, you could probably hack the XML Schema file to make the XML Parser accept additional values for the "adaptiveQuantiserMode" element (e.g. "autoVariance"), but this doesn't mean that the application can actually interpret those values correctly and pass the corresponding parameters to x264. Unless Avidemux (or at least the x264 Plugin) is updated, there's no way around a patched x264 library...