x264 Release 745 problem!

[Rodger]

Sorry to bother you, but I really don´t get it.

I use MeGui to encode with x264.
Since the last realease within MeGui (736-2 Jarod patched...)
a lot happened in the developement of x264.

I expect some speed-improvements for encoding with my Core2Duo with the current build 745!

I exchanged the x264.exe, started an encoding session and it crashed...well only the the Worker of MeGui, but so I don´t get to do the encode.
As soon as I get back to the old release for MeGui encoding works.

So the main of my interest is...are the builds especially made for MeGui or is there anything wrong with MeGui or even my System here (what I don´t think). Are official build unusuable for me?

[Dark Shikari]

r745 crashes because of a bug in one of the speed improvements. This is why r747 came so soon after to fix that.

[Rodger]

Where can I get a useable build of rel.747?

[Dark Shikari]

Where can I get a useable build of rel.747?This is one of the big problems--the bug came at the same time x264 switched from svn to git, so most of the people making builds don't have git set up yet.

[Rodger]

So which release is the last working one? :confused::confused::confused:

DAMN IT! :p

[Dark Shikari]

So which release is the last working one? :confused::confused::confused:

DAMN IT! :pAnything before 742 or after 746 will work.

[Rodger]

Since the newest Version available @h264.nl is rel.745
the best alternative Version will be rel.742
http://mirror01.x264.nl/x264/

I still think this will be quite a lot faster than that rel.736-2 that comes with MeGui
Thanks for your help.

[trex]

Any Builds of 747 out there yet ?

:confused:

cheers, trex

[Dark Shikari]

I still think this will be quite a lot faster than that rel.736-2 that comes with MeGui
Thanks for your help.Doubtful, all the speed improvements are incremental.

[J_Darnley]

I can post a quick build of the git source but it will be without the MP4 Muxer and with the VAQ patch.
http://users.telenet.be/darnley/x264_r747.7z
Please remember that it is your fault if this melts your PC.

[trex]

Thanks for posting that link.

I'll post if it melting away my PC :)

:thanks:

Looking forward for the next patched AQ version.

:cool:

[burfadel]

Thats interesting, I've encoded using r745 without any problem on my Core2duo, but it would be good to be able to use a working r747 or >, just in case! Dark Shikari, how is the consensus of the latest VAQ patch, in terms of it being submitted to svn? I think thats the main feature people get from patched builds. Or is it the case that there's still some tweaking to do to it? :) either way, keep up the great work!

I'm also curious as the motive behind the move from svn to git, I probably missed reading something somewhere did I? lol

[akupenguin]

Thats interesting, I've encoded using r745 without any problem on my Core2duo.
If you have a 64bit build, that's probably why. The offending code was in svn since r520, but it never crashed on x86_64 since the variable happened to be aligned anyway. Only the x86_32 port in r745 brought it out.

[burfadel]

Ah ok! I've using the 32 bit version of x264, but am running on an x64 system if that would affect anything?...

I have a core 2 duo e6600.

It could have also been I was using the patched build of r745 from www.x264.tk

[Henrikx]

This is one of the big problems--the bug came at the same time x264 switched from svn to git, so most of the people making builds don't have git set up yet.

@Dark Shikari
Can you explain, how to handle git

On Linux (Ubuntu) I installed
git-core
git-gui
gitk

git clone git://git.videolan.org/x264.git = Ok

and now and carrying on normally like svn

/configure, make, make install (For Ubuntu Checkinstall make install)
or is a git-step missing here

How to update, like svn update

[Gabriel_Bouvigne]

"git pull"

[Henrikx]

@Gabriel_Bouvigne
THX!

[techouse]

I'll compile a fully patched r747 and upload it to www.x264.tk in a few minutes.

EDIT: Done. :)

[Henrikx]

To compile is no problem, but x264 --help

x264 core:58 svn-exportiert (exported)

don't shows the Version (Linux).

??

[techouse]

To compile is no problem, but x264 --help

x264 core:58 svn-exportiert (exported)

don't shows the Version (Linux).

??

I just compiled it for windows and it doesn't show the SVN either. My guess is that it doesn't show it cause it isn't SVN.

[Henrikx]

I dont know

take a look at version.sh

#!/bin/sh
VER=`svnversion .`
if [ "x$VER" != x -a "$VER" != exported ]
then
echo "#define X264_VERSION \" svn-$VER\"" >> config.h
VER=`echo $VER | sed -e 's/[^0-9].*//'`
else
echo "#define X264_VERSION \"\"" >> config.h
VER="x"
fi
API=`grep '#define X264_BUILD' < x264.h | sed -e 's/.* \([1-9][0-9]*\).*/\1/'`
echo "#define X264_POINTVER \"0.$API.$VER\"" >> config.h


svn?

[Sharktooth]

I just compiled it for windows and it doesn't show the SVN either. My guess is that it doesn't show it cause it isn't SVN.
exactly. try this (was on the ML):
diff --git a/version.sh b/version.sh
index a91c48b..cbdf140 100755
--- a/version.sh
+++ b/version.sh
@@ -1,8 +1,8 @@
#!/bin/sh
-VER=`svnversion .`
+VER=`git-rev-list HEAD | wc | awk '{print substr($1,0,3)}'`
if [ "x$VER" != x -a "$VER" != exported ]
then
- echo "#define X264_VERSION \" svn-$VER\"" >> config.h
+ echo "#define X264_VERSION \" git-$VER\"" >> config.h
VER=`echo $VER | sed -e 's/[^0-9].*//'`
else
echo "#define X264_VERSION \"\"" >> config.h
but Loren replied:
An ideal script would:
Still work with svn (I don't think people will stop using the svn mirror soon).
Count the number of revisions shared between the local tree and upstream (local commits don't increment the version number, nor do upstream commits that haven't been fetched).
Check wether there are local commits or non-committed modifications.
Add part of the hash just to be sure.
also there is an updated vbv patch (v6):
Index: encoder/ratecontrol.c
===================================================================
--- encoder/ratecontrol.c (revision 736)
+++ encoder/ratecontrol.c (working copy)
@@ -43,6 +43,7 @@
int p_tex_bits;
int misc_bits;
uint64_t expected_bits;
+ double expected_vbv;
float new_qscale;
int new_qp;
int i_count;
@@ -1149,7 +1150,7 @@
return;

rct->buffer_fill_final += rct->buffer_rate - bits;
- if( rct->buffer_fill_final < 0 && !rct->b_2pass )
+ if( rct->buffer_fill_final < 0 )
x264_log( h, X264_LOG_WARNING, "VBV underflow (%.0f bits)\n", rct->buffer_fill_final );
rct->buffer_fill_final = x264_clip3f( rct->buffer_fill_final, 0, rct->buffer_size );
}
@@ -1325,6 +1326,22 @@
double w = x264_clip3f( time*100, 0.0, 1.0 );
q *= pow( (double)total_bits / rcc->expected_bits_sum, w );
}
+ if( rcc->b_vbv )
+ {
+ double expected_size = qscale2bits(&rce, q);
+ double expected_vbv = rcc->buffer_fill + rcc->buffer_rate - expected_size;
+ if( (expected_vbv < rcc->buffer_size*.4) && (expected_vbv < rce.expected_vbv) )
+ {
+ double qmax = (expected_vbv < rcc->buffer_size*.15) ? lmax : q*1.5;
+ double size_constraint = 1 + rce.expected_vbv/rcc->buffer_size;
+ while( (expected_vbv < rce.expected_vbv/size_constraint) && (q < qmax) )
+ {
+ q *= 1.05;
+ expected_size = qscale2bits(&rce, q);
+ expected_vbv = rcc->buffer_fill + rcc->buffer_rate - expected_size;
+ }
+ }
+ }
q = x264_clip3f( q, lmin, lmax );
}
else /* 1pass ABR */
@@ -1455,6 +1472,137 @@
/* the rest of the variables are either constant or thread-local */
}

+FILE *fh_vbv;
+
+static int find_underflow( x264_t *h, double *fills, int *t0, int *t1, int over )
+{
+ /* find an interval ending on an overflow or underflow (depending on whether
+ * we're adding or removing bits), and starting on the earliest frame that
+ * can influence the buffer fill of that end frame. */
+ x264_ratecontrol_t *rcc = h->rc;
+ const double buffer_min = (over ? .1 : .1) * rcc->buffer_size;
+ const double buffer_max = .9 * rcc->buffer_size;
+ double fill = fills[*t0-1];
+ double parity = over ? 1. : -1.;
+ int i, start=-1, end=-1;
+ for(i=*t0; i<rcc->num_entries; i++)
+ {
+ fill += (rcc->buffer_rate - qscale2bits(&rcc->entry[i], rcc->entry[i].new_qscale)) * parity;
+ fill = x264_clip3f(fill, 0, rcc->buffer_size);
+ fills[i] = fill;
+ if(fill <= buffer_min || i == 0)
+ {
+ if(end >= 0)
+ break;
+ start = i;
+ }
+ else if(fill >= buffer_max && start >= 0)
+ end = i;
+ }
+ *t0 = start;
+ *t1 = end;
+ return start>=0 && end>=0;
+}
+
+static void fix_underflow( x264_t *h, int t0, int t1, double adjustment, double qscale_min, double qscale_max)
+{
+ x264_ratecontrol_t *rcc = h->rc;
+ double qscale_new;
+ int i;
+ if(t0 > 0)
+ t0++;
+ for(i=t0; i<=t1; i++) {
+ qscale_new = rcc->entry[i].new_qscale *= adjustment;
+ rcc->entry[i].new_qscale = x264_clip3f(qscale_new, qscale_min, qscale_max);
+ }
+}
+
+static double count_expected_bits( x264_t *h )
+{
+ x264_ratecontrol_t *rcc = h->rc;
+ double expected_bits = 0;
+ int i;
+ for(i=0; i<rcc->num_entries; i++)
+ {
+ ratecontrol_entry_t *rce = &rcc->entry[i];
+ rce->expected_bits = expected_bits;
+ expected_bits += qscale2bits(rce, rce->new_qscale);
+ }
+ return expected_bits;
+}
+
+static void debug_dump_vbv( x264_t *h )
+{
+ x264_ratecontrol_t *rcc = h->rc;
+ double fill = rcc->buffer_size * h->param.rc.f_vbv_buffer_init;
+ int i;
+ for(i=0; i<rcc->num_entries; i++)
+ {
+ fill += rcc->buffer_rate - qscale2bits(&rcc->entry[i], rcc->entry[i].new_qscale);
+ fill = x264_clip3f(fill, rcc->buffer_size*-.5, rcc->buffer_size);
+ fprintf(fh_vbv, "%d %.0f\n", i, fill);
+ }
+}
+
+static void vbv_pass2( x264_t *h )
+{
+ /* foreach interval of buffer_full .. underflow
+ * uniformly increase the qp of all frames in the interval until either
+ * buffer is full at some intermediate frame
+ * or the last frame in the interval no longer underflows
+ * recompute intervals and repeat
+ * then do the converse to put bits back into overflow areas until target size is met */
+
+ x264_ratecontrol_t *rcc = h->rc;
+ double *fills = x264_malloc((rcc->num_entries+1)*sizeof(double));
+ double all_available_bits = h->param.rc.i_bitrate * 1000. * rcc->num_entries / rcc->fps;
+ double expected_bits = 0;
+ double adjustment;
+ double prev_bits = 0;
+ int i, t0, t1;
+ double qscale_min = qp2qscale(h->param.rc.i_qp_min);
+ double qscale_max = qp2qscale(h->param.rc.i_qp_max);
+ int iterations = 0;
+
+ fills++;
+
+ //adjust overall stream size
+ do {
+ iterations++;
+ prev_bits = expected_bits;
+
+ if (expected_bits != 0) { //not first iteration
+ adjustment = X264_MAX(X264_MIN(expected_bits / all_available_bits, 0.999), 0.9);
+ fills[-1] = rcc->buffer_size * h->param.rc.f_vbv_buffer_init;
+ t0 = 0;
+ //fix overflows
+ while(find_underflow(h, fills, &t0, &t1, 1))
+ {
+ fix_underflow(h, t0, t1, adjustment, qscale_min, qscale_max);
+ t0 = t1;
+ }
+ }
+
+ fills[-1] = rcc->buffer_size * (1. - h->param.rc.f_vbv_buffer_init);
+ t0 = 0;
+ //fix underflows - should be done after overflow, as we'd better undersize target than underflowing VBV
+ while(find_underflow(h, fills, &t0, &t1, 0))
+ {
+ fix_underflow(h, t0, t1, 1.001, qscale_min, qscale_max);
+ }
+
+ expected_bits = count_expected_bits(h);
+ } while(expected_bits < .995*all_available_bits && expected_bits > prev_bits);
+
+ //store expected vbv filling values for tracking when encoding
+ for(i=0; i<rcc->num_entries; i++)
+ rcc->entry[i].expected_vbv = rcc->buffer_size - fills[i];
+
+// x264_log( h, X264_LOG_INFO, "VBV RC initial iterations: %d \n", iterations);
+
+ x264_free(fills-1);
+}
+
static int init_pass2( x264_t *h )
{
x264_ratecontrol_t *rcc = h->rc;
@@ -1543,7 +1691,6 @@
rcc->last_non_b_pict_type = -1;
rcc->last_accum_p_norm = 1;
rcc->accum_p_norm = 0;
- rcc->buffer_fill = rcc->buffer_size * h->param.rc.f_vbv_buffer_init;

/* find qscale */
for(i=0; i<rcc->num_entries; i++){
@@ -1580,18 +1727,11 @@
/* find expected bits */
for(i=0; i<rcc->num_entries; i++){
ratecontrol_entry_t *rce = &rcc->entry[i];
- double bits;
rce->new_qscale = clip_qscale(h, rce->pict_type, blurred_qscale[i]);
assert(rce->new_qscale >= 0);
- bits = qscale2bits(rce, rce->new_qscale);
-
- rce->expected_bits = expected_bits;
- expected_bits += bits;
- update_vbv(h, bits);
- rcc->buffer_fill = rcc->buffer_fill_final;
+ expected_bits += qscale2bits(rce, rce->new_qscale);
}

-//printf("expected:%llu available:%llu factor:%lf avgQ:%lf\n", (uint64_t)expected_bits, all_available_bits, rate_factor);
if(expected_bits > all_available_bits) rate_factor -= step;
}

@@ -1599,6 +1739,10 @@
if(filter_size > 1)
x264_free(blurred_qscale);

+ if(rcc->b_vbv)
+ vbv_pass2(h);
+ expected_bits = count_expected_bits(h);
+
if(fabs(expected_bits/all_available_bits - 1.0) > 0.01)
{
double avgq = 0;
@@ -1606,7 +1750,8 @@
avgq += rcc->entry[i].new_qscale;
avgq = qscale2qp(avgq / rcc->num_entries);

- x264_log(h, X264_LOG_WARNING, "Error: 2pass curve failed to converge\n");
+ if ((expected_bits > all_available_bits) || (!rcc->b_vbv))
+ x264_log(h, X264_LOG_WARNING, "Error: 2pass curve failed to converge\n");
x264_log(h, X264_LOG_WARNING, "target: %.2f kbit/s, expected: %.2f kbit/s, avg QP: %.4f\n",
(float)h->param.rc.i_bitrate,
expected_bits * rcc->fps / (rcc->num_entries * 1000.),
@@ -1625,7 +1770,7 @@
else
x264_log(h, X264_LOG_WARNING, "try increasing target bitrate\n");
}
- else
+ else if(!(rcc->b_2pass && rcc->b_vbv))
x264_log(h, X264_LOG_WARNING, "internal error\n");
}

[Henrikx]

@Sharktooth

BIG THX!

X264 --help Ubuntu 7.10

x264 core:58 git-748
Syntax: x264 [options] -o outfile infile [widthxheight]

Infile can be raw YUV 4:2:0 (in which case resolution is required),
or YUV4MPEG 4:2:0 (*.y4m),
or AVI or Avisynth if compiled with AVIS support (no).
Outfile type is selected by filename:
.264 -> Raw bytestream
.mkv -> Matroska
.mp4 -> MP4 if compiled with GPAC support (yes)

[techouse]

I managed to get the version patch working in Linux but not in Windows :P In Windows I just get git-0

[canTsTop]

i tried 747 version to check compressibility of my video with crf 23, size was 47.4 mb, but with 745 version with same settings size was 30.3 mb. its very big difference, what have changed in this new x264 version?

[Dark Shikari]

i tried 747 version to check compressibility of my video with crf 23, size was 47.4 mb, but with 745 version with same settings size was 30.3 mb. its very big difference, what have changed in this new x264 version?Is one of those AQ patched and the other not?

[canTsTop]

i both downloaded from http://x264.nl/

notes:
05-03-08: 747: recommended revision
05-03-08: 747: also includes experimental, but stable patches
05-03-08: 745 is unstable so "747" has been put online
05-03-08: 745 is last svn version, x264 now uses git

it seems 747 with patches, and 745 was without patches.

[Terranigma]

it seems 747 with patches

That's because by default, the 747 build has AQ enabled, so you might want to jump up 2 crf's.

[valgor]

What is the profit of switching from svn to git for x264 developers? I accustomed to update x24 from svn...

[Dark Shikari]

What is the profit of switching from svn to git for x264 developers? I accustomed to update x24 from svn...It wasn't us who decided to switch; it was Videolan, IIRC.

[Sharktooth]

it will be a problem for versions... git doesnt support version numbering.

[bob0r]

@techouse:

git-rev-list HEAD | wc -l | sed -e 's/^ *//'

Gives a nice output for a revision number (c) pengvado.

So the patch i assume should be:


diff --git a/version.sh b/version.sh
index a91c48b..cbdf140 100755
--- a/version.sh
+++ b/version.sh
@@ -1,8 +1,8 @@
#!/bin/sh
-VER=`svnversion .`
+VER=`git-rev-list HEAD | wc -l | sed -e 's/^ *//'`
if [ "x$VER" != x -a "$VER" != exported ]
then
- echo "#define X264_VERSION \" svn-$VER\"" >> config.h
+ echo "#define X264_VERSION \" git-$VER\"" >> config.h
VER=`echo $VER | sed -e 's/[^0-9].*//'`
else
echo "#define X264_VERSION \"\"" >> config.h


The sed -e 's/^ *//' part is to remove extra spaces, needed for mingw at least.

Edit:
Not sure if this is still needed then: VER=`echo $VER | sed -e 's/[^0-9].*//'`
The first VER= already should give a nice clean number.

[cacepi]

@techouse:git-rev-list HEAD | wc -l | sed -e 's/^ *//'
I tried pretty much the exact same thing and was shot down. (See Sharktooth's reply (http://forum.doom9.org/showthread.php?p=1108827#post1108827) above for details.) An interim solution is to tag the commits with git-tag(1) and use git-describe(1) to manage versioning:

svnversion-patch.zip (http://www.filesend.net/download.php?f=6479d42dbab5d3d9d4cb45ac6e996bda)

Run "tagit.sh" in your x264 directory and then apply the patch with git-apply(1).

Note this has not been commited to the x264 repo, so it only works for the current HEAD. I don't know how versioning will work for x264 in the future, but the above patch at least preserves the old "svn-###" behavior.

[bob0r]

git-rev-list HEAD | wc -l | sed -e 's/^ *//', works fine in mingw (windows xp)
All it does is calculate how many hashes there are + removed unneeded spaces, pengvado suggested it for x264.nl when he updated my script.

How were you shot down?

[cacepi]

How were you shot down?
It's all in Sharktooth's reply (http://forum.doom9.org/showpost.php?p=1108827&postcount=22). I wrote that patch that was on the mailing list, but it doesn't do all the things that pengvado wanted. (The first patch couldn't track uncommited changes, local commits, mixed-revisions, etc.) If all you need for your build script is to calculate a version number, what you wrote will do the trick.

P.S. - Like you suspected, the VER=`echo $VER | sed -e 's/[^0-9].*//'` isn't needed: sed is searching for anything that doesn't begin with 0-9, which will never match because your first $VER only returns numbers. You can kill it.

[hajj_3]

748 jarods patched is available in megui through update now, using that now:)

[Henrikx]

Update to x264 core:58 r749

x264 -- help (Ubuntu)
x264 core:58 r749 096b390

What should mean 096b390 ?

[Sharktooth]

http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff

[Henrikx]

Ok!
THX!

[Sharktooth]

more explicit: http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=096b39036aad8d363b81e520ad13cee412b0e568
look at the commit field.

[Henrikx]

more explicit: http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=096b39036aad8d363b81e520ad13cee412b0e568
look at the commit field.

I was only slightly surprised
5th March 2008 i take the Version.sh that you have written here.
All ok, very good, I create a Ubuntu deb.
http://www.movie2digital.de/thread.php?postid=472546#post472546
Today git pull - Update , and new version.sh

And then this Code in output.
I thought I had made a mistake.

But itś ok.
THX again.

[bob0r]

me to pengvado: why 096b390 ? why not all of the hash or 6 chars?

[17:31] (pengvado): 7 is what git uses as an abbreviation
[17:31] (pengvado): e.g. "397d1bf..096b390"

Cool, the version script works, ill stick to just revision on x264.nl

Revision 749 online :)

x264.nl fully automated again, thanks akupengvado! :D

[gruntster]

x264 r749 is still crashing in predict_8x8_ddl_sse2 for me on Win32. Only the DLL seems to cause the issue. The EXE was also crashing in r745 but is now working again in r749.

I get the following backtrace using a debug build:

#0 0x024ca138 in predict_8x8_ddl_sse2 ()
from c:\dev\avidemux_2.4_build\libx264.dll
#1 0x024cc87a in x264_slicetype_mb_cost (h=0x71cf030, a=0x22b5b8,
frames=0x22b570, p0=0, p1=0, b=0, dist_scale_factor=128)
at encoder/slicetype.c:226
#2 0x024ccbfc in x264_slicetype_frame_cost (h=0x71cf030, a=0x22b5b8,
frames=0x22b570, p0=0, p1=0, b=0, b_intra_penalty=0)
at encoder/slicetype.c:304
#3 0x024d2641 in x264_rc_analyse_slice (h=0x71cf030)
at encoder/slicetype.c:530
#4 0x024fa992 in rate_estimate_qscale (h=<incomplete type>)
at encoder/ratecontrol.c:1344
#5 0x024fb06b in x264_ratecontrol_start (h=<incomplete type>, i_force_qp=0)
at encoder/ratecontrol.c:691
#6 0x024ea4a5 in x264_encoder_encode (h=<incomplete type>, pp_nal=0x22e12c,
pi_nal=0x22e128, pic_in=0x75c8fd0, pic_out=0x22e0e8)
at encoder/encoder.c:1412

Is anyone else able to reproduce the problem?

[MasterNobody]

gruntster
Do you compile libx264.dll yourself? If yes, than what compiler do you use? Because, for example, GCC 3.4.5 from MinGW official package have problems with "__attribute__((aligned(n)))" so I suggest you update GCC to 4.2.3 or 4.3.0 (you can binaries from here (http://www.tdragon.net/recentgcc/)). Also I recommend you to set "__attribute__((force_align_arg_pointer))" for functions exported from DLL (before I do this I have problems with my builds of x264vfw).

[akupenguin]

Also I recommend you to set "__attribute__((force_align_arg_pointer))" for functions exported from DLL (before I do this I have problems with my builds of x264vfw).
That really shouldn't be necessary. x264 aligns the stack in asm before calling any functions that need alignment, so the compiler need only preserve alignment, not realign.

[gruntster]

gruntster
Do you compile libx264.dll yourself? If yes, than what compiler do you use? Because, for example, GCC 3.4.5 from MinGW official package have problems with "__attribute__((aligned(n)))" so I suggest you update GCC to 4.2.3 or 4.3.0 (you can binaries from here (http://www.tdragon.net/recentgcc/)). Also I recommend you to set "__attribute__((force_align_arg_pointer))" for functions exported from DLL (before I do this I have problems with my builds of x264vfw).

I compile libx264.dll myself for the Avidemux Windows builds. The last build I did that worked was r735. I've also tried r745 and r749 and neither work. I use GCC 4.2.1. As I mentioned previously, x264.exe works with r749 just not libx264.dll.

[MasterNobody]

That really shouldn't be necessary. x264 aligns the stack in asm before calling any functions that need alignment, so the compiler need only preserve alignment, not realign.
IMHO you are wrong. It only aligns stack for x264_slice_write function and in ADS_START macros of i386\pixel-a.asm but stack alignment also needed for x264_slicetype_mb_cost (crash when call x264_predict_8x8_filter) which is called during x264_ratecontrol_start which is called outside of x264_slice_write.

[audyovydeo]

C:\temp>x264_0.58.745 --version
x264 0.58.745

C:\temp>x264_0.58.748 --version
x264 0.58.x

C:\temp>x264_0.58.749 --version
x264 0.58.749 096b390

C:\temp>x264_0.58.752 --version
x264 0.58.751 dafc72c

C:\temp>x264_0.58.754 --version
x264 0.58.751 dafc72c

C:\temp>x264_0.58.756 --version
x264 0.58.751 dafc72c

C:\temp>x264_0.58.757 --version
x264 0.58.751 dafc72c


951,826 x264_0.58.745.exe
951,826 x264_0.58.748.exe
951,826 x264_0.58.749.exe
955,410 x264_0.58.752.exe
955,410 x264_0.58.754.exe
952,338 x264_0.58.756.exe
952,338 x264_0.58.757.exe



???
Not sure what is what anymore.

More worryingly, 749 is measureably slower than 745 (which worked fine on my machine) with my test videoclip.
Upto 5% slower, across different encoding settings. Anyone else measured this ?
Havent tried speed of any 75x yet.

cheers
audyovydeo

[Sharktooth]

from 749 on the versioning is correct.
different size in bytes means they are not the same builds.

[LoRd_MuldeR]

Is anyone else able to reproduce the problem?
Get the same problem/crash with Gruntster's latest build...