Current Patches, Where to get them, How they affect speed/output

[Ranguvar]

./configure --enable-mp4-output --extra-cflags="-march=athlon -pipe"

If you need to use --enable-mp4-output, gpac isn't installed correctly. mp4 output should be on by default, unless gpac is not found.

[Audionut]

This build is a little faster on my core2.

Link removed.
Downloaded latest revisions.

Appears not to work as well on AMD procs.

[komisar]

Small patch to fix crash in --qp XX --vbv-maxrate XXX --vbv-bufsize XXXk.57.x264_fix_vbv_crash.01k.diff (http://komisar.gin.by/x.patch/last.used/k.57.x264_fix_vbv_crash.01k.diff)

[komisar]

New patch for tuning encoding thread priority.

k.58.x264_thread_priority.01.diff (http://komisar.gin.by/x.patch/last.used/k.58.x264_thread_priority.01.diff)
k.59.x264_thread_priority_with_pool.01.diff (http://komisar.gin.by/x.patch/last.used/k.59.x264_thread_priority_with_pool.01.diff) (for x264_thread_pool patch)
k.60.x264_restore_console_title.diff (http://komisar.gin.by/x.patch/last.used/k.60.x264_restore_console_title.diff)

x264.987kHRD.k8.tboost.exe (http://komisar.gin.by/test/x264.987kHRD.k8.tboost.exe)
x264.987kMod.k8.tboost.exe (http://komisar.gin.by/test/x264.987kMod.k8.tboost.exe)
--threads-boost <integer> Tune priority for encoding threads [0]
-2: LOWEST
-1: BELOW_NORMAL
0: NORMAL
1: ABOVE_NORMAL
2: HIGHESTSpeed comparsion on buttom of my page.

[komisar]

Another variant for "playing" with threads priority:

k.61.x264_thread_priority.02.diff (http://komisar.gin.by/x.patch/last.used/k.61.x264_thread_priority.02.diff)
k.62.x264_thread_priority_with_pool.02.diff (http://komisar.gin.by/x.patch/last.used/k.62.x264_thread_priority_with_pool.02.diff) (for x264_thread_pool patch)

x264.987kHRD.k8.tboost2.exe (http://komisar.gin.by/test/x264.987kHRD.k8.tboost2.exe)
x264.987kMod.k8.tboost2.exe (http://komisar.gin.by/test/x264.987kMod.k8.tboost2.exe)
--threads-boost <integer> Tune priority for encoding threads [0]
-2: LOWEST
-1: BELOW_NORMAL
0: NORMAL
1: ABOVE_NORMAL
2: HIGHEST
--thread-input-boost <integer> Tune priority for input thread (Values as in 'threads-boost') [0]

[Sagekilla]

Very interesting komisar. I personally use Prio to make x264 be permenantly at "lowest" priority. Otherwise if it's at normal, everything crawls to a slow, even stuff browsing through folders on my HD.

[skystrife]

You can change process priority in the task manager...

[LoRd_MuldeR]

You can change process priority in the task manager...

But not the thread-priority of individual threads in a process, or am I mistaken?

(the priority of a thread is Process Priority Class plus Thread Priority)

[skystrife]

Ah, good point. I didn't read into this enough.

[LoRd_MuldeR]

Ah, good point. I didn't read into this enough.

It's explained in detail here:
http://msdn.microsoft.com/en-us/library/ms685100(VS.85).aspx

However I doubt that x264 can get additional speed-up from messing with priorities.
All priorities do is controlling the CPU time distribution across several applications running concurrently.
If you want x264 to run fast, don't do any other CPU-hungry tasks at the same time...

[Sharktooth]

the thread-input priority is interesting though and may be helpfull...

[Quark.Fusion]

However I doubt that x264 can get additional speed-up from messing with priorities.
All priorities do is controlling the CPU time distribution across several applications running concurrently.
If you want x264 to run fast, don't do any other CPU-hungry tasks at the same time...

Imagine that single-threaded task like b-adapt thread get interrupted by encoding threads and can't provide new frames in time — you will get loaded only one core until enough frames will be processed.
Task becomes more complicated if you have another processes running during encoding.

Didn't test source decoding threading as source decoder can produce threads on it own and don't know what priority they will have (based on parent thread or on process priority).
If priority of those threads can't be controlled then it's better to adjust main thread priority instead of --thread-input. Then priorities can be fully controlled with addition of process priority.

[roozhou]

Sometimes I use mencoder+x264 and mplayer+neroAacEnc to encode video+audio on a dual core. There are four processes running at the same time. If I set mencoder and mplayer to a lower priority and x264 and neroAacEnc to normal priority, it gives me 100% CPU usage and A/V encoding progress remain the same, thus giving best disk cache hits.

[skystrife]

x264.988.modified.exe (http://www.mediafire.com/?wyjtgqrv3uz) - Alternate Download (http://skystrife.com/x264/x264.988.modified.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[Audionut]

Revision 988.

Make x264 progress indicator more concise

Now the % indicator should be readable on the header of a minimized window on Windows systems.


x264-988-generic.rar (http://rapidshare.com/files/148768060/x264-988-generic.rar)

This build favors Intel cpu
x264-988 (http://rapidshare.com/files/148763428/x264-988.rar)

[Atak_Snajpera]

Small request: Can you change kb/s info to kbps. kb/s reminds me KB/s to much :)

[LoRd_MuldeR]

BTW: Isn't "eta:" wrong and shouldn't "ete:" be used?

ETA (http://en.wikipedia.org/wiki/Estimated_time_of_arrival) (estimated time of arrival) is the point in time when something will be done; ETE (http://www.encyclo.co.uk/define/Estimated%20Time%20Enroute%20(ETE)) (estimated time enroute) is the time remaining until something will be done.

[Atak_Snajpera]

another question: Do we really need kbps info with decimal symbol???

Small request: Can you change kb/s info to kbps. kb/s reminds me KB/s to much
Ok. I used hex editor and now I have kbps instead of kb/s :)

[techouse]

BTW: Isn't "eta:" wrong and shouldn't "ete:" be used?

ETA (http://en.wikipedia.org/wiki/Estimated_time_of_arrival) (estimated time of arrival) is the point in time when something will be done; ETE (http://www.encyclo.co.uk/define/Estimated%20Time%20Enroute%20(ETE)) (estimated time enroute) is the time remaining until something will be done.

It has many meanings, out of which one is Estimated Time for Accomplishment - http://acronyms.thefreedictionary.com/Estimated+Time+for+Accomplishment

[LoRd_MuldeR]

Estimated Time for Accomplishment

Wouldn't that mean the total time, instead of the remaining time?

[akupenguin]

BTW: Isn't "eta:" wrong and shouldn't "ete:" be used?
I see nothing in that definition that says "time" has to be absolute and not relative to "now". If I weren't abbreviating it I'd write "estimated time remaining", but I wouldn't recognize the acronyms "ETE" or "ETR".

[LoRd_MuldeR]

I think ETA commonly refers to "estimated time of arrival", not "estimated time until arrival". So I'd expect an absolute value.

However this is just a cosmetic thing, not very important. If you think "eta:" is good, I'm fine with that and there's no need to further discuss it.

[Shinigami-Sama]

I think ETA commonly refers to "estimated time of arrival", not "estimated time until arrival". So I'd expect an absolute value.

However this is just a cosmetic thing, not very important. If you think "eta:" is good, I'm fine with that and there's no need to further discuss it.

well once it finishes your file has arrived(finished)...

[Audionut]

Revision 992

*more diagnostics when configure finds an unsuitable assembler

*remove authors whose code no longer exists

*fix bitstream writer on bigendian 64bit (regression in r903)

*avg_weight_ssse3

Intel build (http://rapidshare.com/files/149022130/x264-992.rar)

Generic build (http://rapidshare.com/files/149022979/x264-992-generic.rar)

[burfadel]

Estimated time of arrival, or variations of the term thereof, is not absolute. If it were an absolute value is wouldn't be an estimate would it? but rather just a 'time of arrival'. If you are driving your car, you don't know what the traffic situation is like, whether you will get all green lights or red lights, among many other traffic situations. In this case, its hard to say you will arrive at a place at an exact time, so you use an ETA. A train on the other hand free of the traffic lights etc will be a 'time of arrival', as the path is clear and the time can be easily calculated based on past experiences which are all almost the same.

That analogy isn't perfect, but it does have relevance to the video encoder. The ETA of the encoder can only be based on the past experiences of that particular encode. Since the speed of encoding motion, changing frames etc is different for each encode and each part of the same encode (analogy of the car and the traffic lights), then the finish time can never be guaranteed as an absolute value.

ETA is a time such as 5:40pm, not the remaining encode time. There should be a estimated encode time remaining (EETA), ETA as a time, which is just the current time (hh:mm:ss) with the addition of the eta in hh:mm:ss

[LoRd_MuldeR]

"Absolute" simply means that you say the time when it will be done (e.g. "9:21 am"), not the time that is left until it will be done.
Both can be estimated, of course. If you only have got the "estimated time left", you can easily calculate the "estimated time of arrival" by:
<estimated time of arrival> = <estimated time left> + <current time>

But I already said it's not important (just a cosmetic) and Akupenguin said he doesn't see any need to change it.
No need to further discuss it. Let's move on to some important stuff...

[komisar]

what happened to the indicator?
fprintf( stderr, "%s \r", buf+5 );
SetConsoleTitle( buf );
It may mean that:fprintf( stderr, "%s \r", buf );
SetConsoleTitle( buf+5 );

[J_Darnley]

what happened to the indicator?
fprintf( stderr, "%s \r", buf+5 );
SetConsoleTitle( buf );
It may mean that:fprintf( stderr, "%s \r", buf );
SetConsoleTitle( buf+5 );
Read the change again. The title will have "x264 " but the progress wont. It was changed at the request of some people who don't have enough cmd windows open.

[techouse]

x264_x86_r994_techouse (http://techouse.project357.com/builds/x264_x86_r994_techouse.7z)
Source: x264 r994 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):

x264_hrd_pulldown.09_interlace.diff

k.61.x264_thread_priority.02.diff


Please check http://forum.doom9.org/showthread.php?t=130364 and http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog for more info

Compiled by techouse on September 28th 2008, 16:20:54 CEST with GCC-4.3.2 on Windows Vista Ultimate SP-1 32-bit.

Commandline used: ./configure --extra-cflags="-march=core2 -pipe" && make fprofiled

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

[skystrife]

x264.994.modified.exe (http://www.mediafire.com/?z5wr3jt0zjm) - Alternate Download (http://skystrife.com/x264/x264.994.modified.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[Tarutaru]

http://www.mediafire.com/?mzndmzziw5y

x264 0.64.994M b35a044

patches used:
x264_hrd_pulldown.09_interlace.diff
k.61.x264_thread_priority.02.diff

thread priority usage:
--threads-boost <integer> Tune priority for encoding threads [0]
-2: LOWEST
-1: BELOW_NORMAL
0: NORMAL
1: ABOVE_NORMAL
2: HIGHEST

built with gcc 3.4.5 fprofiled, march=k8

[komisar]

And my 994 builds also... :) (profiled, WITHOUT vaq-mod, vfw, tuned)

http://komisar.gin.by/

[LoRd_MuldeR]

??-??-08: 1000: revision 1000 party at pengvado's villa

I'll bring a barrel of beer, but somebody needs to tell me the location first :D

[Atak_Snajpera]

??-??-08: 1000: donate 1 million euro to make revision 1000 version 1.0
That was even better :)

[LoRd_MuldeR]

That was even better :)

I don't have the money for that, but I'm always ready for a nice party :)

[Audionut]

Revision 995

* Fix typo in progress indicator when using piped input

*Replace High 4:4:4 profile lossless with High 4:4:4 Predictive.

This improves lossless compression by about 4-25% depending on source.
The benefit is generally higher for intra-only compression.
Also add support for 8x8dct and i8x8 blocks in lossless mode; this improves compression very slightly.
In some rare cases 8x8dct can hurt compression in lossless mode, but its usually helpful, albeit marginally.
Note that 8x8dct is only available with CABAC as it is never useful with CAVLC.
High 4:4:4 Predictive replaced the previous profile in a 2007 revision to the H.264 standard.
The only known compliant decoder for this profile is the latest version of CoreAVC.
As I write this, JM does not actually correctly decode this profile.
Hopefully this lack of support will soon change with this commit, as x264 will be (to my knowledge) the first compliant encoder.

*Fix potential miscompilation of some inline asm
Caused problems under some gcc 4.x versions with predictive lossless

Intel build (http://rapidshare.com/files/149557452/x264-995.rar)

Generic (http://rapidshare.com/files/149558326/x264-995-generic.rar)

[G_M_C]

x264_x86_r994_techouse (http://techouse.project357.com/builds/x264_x86_r994_techouse.7z)
Source: x264 r994 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):

x264_hrd_pulldown.09_interlace.diff

k.61.x264_thread_priority.02.diff


Please check http://forum.doom9.org/showthread.php?t=130364 and http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog for more info

Compiled by techouse on September 28th 2008, 16:20:54 CEST with GCC-4.3.2 on Windows Vista Ultimate SP-1 32-bit.

Commandline used: ./configure --extra-cflags="-march=core2 -pipe" && make fprofiled

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

Techouse, I tried your build yesterday with MeGUI. But i noticed MeGUI's progress-indicator didn't show the actual progress; I looked like it was printed to the log instead. Is that intentional, or just a flaw ?

I ask cause i'd like to use your builds, cause they seem to be somewhat faster on my C2D.

EDIT:
Oops, I saw in the post a fix for the progress-indicator; Was that the problem ?

[Kurtnoise]

Techouse, I tried your build yesterday with MeGUI. But i noticed MeGUI's progress-indicator didn't show the actual progress; I looked like it was printed to the log instead. Is that intentional, or just a flaw ?
http://forum.doom9.org/showthread.php?p=1189818#post1189818

[juGGaKNot]

Small off-topic :

If i would want to make my own builds where can i get information about compiling.

[stanjr]

If you're compiling on Linux, read here (http://ubuntuforums.org/showthread.php?t=558538).

[J_Darnley]

The x264 compilation thread here: http://forum.doom9.org/showthread.php?t=92726
The link in my signature points to a post that I found very helpful. A large change is that you need git now and then use: git clone git://git.videolan.org/x264.git

[stanjr]

Codec shoot-off time?

[Rodger]

Guys???

Is it just me, or is anybody other experiencing MASSIVE Problems with the new release?

MeGui 0.3.0.2017 + x264 rel.987 OK!
MeGui 0.3.0.2018 + x264 rel.994 Crashing!

Vista64 if that important. I get the message "x264 is not responding anymore...blablabla".
It crashed after a few minutes...the old releases made it all the way to the end.

[burfadel]

Does it do that with every encode? I'm running Vista x64, and using Staxrip with no problems with rel 995 (which is pretty much the same when compiled as 994). Have you tried different settings and see whether its related to one particular function? If there is an issue with it, it would help the developers greatly to know exactly where the issue is. Also stating the machine type would also help.

[Sagekilla]

Rodger, it would help if you post your settings ;)

[skystrife]

1) What are your settings?

2) What is your source material? (if it's an avs script, you could be running out of memory).

[skystrife]

x264.996.modified.exe (http://www.mediafire.com/?inurozd54qm) - Alternate Download (http://skystrife.com/x264/x264.996.modified.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[Audionut]

Revision 996

Rework subme system, add RD refinement in B-frames

The new system is as follows: subme6 is RD in I/P frames, subme7 is RD in all frames, subme8 is RD refinement in I/P frames, and subme9 is RD refinement in all frames.

subme6 == old subme6, subme7 == old subme6+brdo, subme8 == old subme7+brdo, subme9 == no equivalent

--b-rdo has, accordingly, been removed. --bime has also been removed, and instead enabled automatically at subme >= 5.

RD refinement in B-frames (subme9) includes both qpel-RD and an RD version of bime.

x264-996.rar (http://rapidshare.com/files/150248294/x264-996.rar)

[techouse]

Casino Royale; encode's bitrate is 9500 kbps

Source vs Subme8 vs Subme9
http://shrani.si/t/20/7r/BRTZhpp/source.jpg (http://shrani.si/f/20/7r/BRTZhpp/source.png) vs http://shrani.si/t/2M/a7/4y8mjqdL/subme8.jpg (http://shrani.si/f/2M/a7/4y8mjqdL/subme8.png) vs http://shrani.si/t/N/g/28SwfMo4/subme9.jpg (http://shrani.si/f/N/g/28SwfMo4/subme9.png)

Subme9 is 5.26% slower on my PC than Subme8.

[LoRd_MuldeR]

Casino Royale; encode's bitrate is 9500 kbps

Source vs Subme8 vs Subme9
http://shrani.si/t/20/7r/BRTZhpp/source.jpg (http://shrani.si/f/20/7r/BRTZhpp/source.png) vs http://shrani.si/t/2M/a7/4y8mjqdL/subme8.jpg (http://shrani.si/f/2M/a7/4y8mjqdL/subme8.png) vs http://shrani.si/t/N/g/28SwfMo4/subme9.jpg (http://shrani.si/f/N/g/28SwfMo4/subme9.png)

Subme9 is 5.26% slower on my PC than Subme8.

Hard to say ... :confused: