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

[Dark Shikari]

--badapt 2 patch breaks API compatibility. To fix, s/b_bframe_adaptive/i_bframe_adaptive in mplayer code.

[stanjr]

DS, what do you mean by that (I'm a noob when it comes to altering code)? Do you mean to search and replace instances of code with something? In which files?

[kemuri-_9]

yes, the variable was called b_bframe_adaptive (b for bool type),
and is now called i_frame_adaptive (i for int type) in the new bframe decision patch.

that's why DS has stated to do a simple search and replace
(that's what s/x/y means - search for x and replace with y)

[stanjr]

Okay, that is easy enough. I do this in every single mplayer code file? To save time, would you know which ones specifically by chance?

[nm]

Okay, that is easy enough. I do this in every single mplayer code file? To save time, would you know which ones specifically by chance?
The error message already told you which one: libx264.c, which is actually in libavcodec, not MPlayer itself (but you'll find the file in libavcodec subdirectory of the MPlayer source tree :) ).

[stanjr]

The error message already told you which one: libx264.c, which is actually in libavcodec, not MPlayer itself (but you'll find the file in libavcodec subdirectory of the MPlayer source tree :) ).

Duh! :stupid:

Thanks for your help. I'll try it out when I get home!

Edit: s/b_bframe_adaptive/i_bframe_adaptive in libx264.c in libavcodec folder of mplayer source allowed it to compile correctly.

[MasterNobody]

The 32x32 fix seems really strange, especially the "pmb = -imb;" line. Did you intended to have a negative number of P MB ?
It is OK because pmb is only used for x264_log. Also I think imb in this situation would be always equal zero and so pmb would be also zero (also negative value in log would indicate that something is going strange). By the way without the patch the result of int pmb = (h->sps->i_mb_width - 2) * (h->sps->i_mb_height - 2) - imb;would be even less predictable. If h->sps->i_mb_width==2 or h->sps->i_mb_height==2 then the result would be again -imb. But if the h->sps->i_mb_width==1 and h->sps->i_mb_height>2 then the result would be 2-h->sps->i_mb_height-imb (and so pmb would be negative 100%)
Thanks very much, BugMaster - that may be what I'm looking for. I'll test ASAP.

Will all your updated patches be here always? http://komisar.gin.by/x.patch/BugMaster/
No. Only when komisar update them (it is his host, not my). Sometimes I give new versions to him directly (or post on the another forum), and sometimes post them here (as today) or in x264dev mailing list.

[Ranguvar]

Okay new build. Fixes the pthreads problem and updates gpac (Thanks, techouse!), as well as using a whole new set of patches. Now my builds seem like a copy of komisar's :p Sorry, komisar. Obviously credit for patches goes to you and BugMaster, and any others. I just build with whatever patches I deem useful, and after I did some VAQ2mod tests, and learned more about the others you use, that happens to be those (yeah, for all others viewing, I tried VAQ2mod and now prefer 4ver0 and 4ver1 (can't really decide between them). It's not a huge difference, and this patch is, like psy optimizations, very open to interpretation. Some may find its effects displeasing, but I do highly recommend giving it a shot).

EDIT: Went over patches with DS... gonna change things up again next time xD

Home (http://sites.google.com/site/ranguvar13/x264-builds)

Direct download (http://sites.google.com/site/ranguvar13/x264-builds/rang_x264_r0965-2.7z?attredirects=0), Mirrors (http://www.rapidspread.com/file.jsp?id=efo1t5sy54)

x264 r965 from Git (patched, fprofiled).
Thanks to the x264 devs, including those who made the patches I use.
Compiled by Ranguvar on September 8th, 2008, with GCC 4.3.2.
This build has the pthreads issue fixed, and the gpac libs updated.
DON'T think that because I used march=athlon it restricts the CPUs you can use.
It seems to improve performance (VERY slightly) for all CPUs.

Open this archive with the free, multi-platform tools 7-Zip or p7zip. Compressed with LZMA.
The src folder contains the patched source code.
The bin folder contains a binary executable, and a DLL for those apps that use it
(May not work in AviDemux. Get those DLLs from LoRd_MuldeR).

Git: git://git.videolan.org/x264.git
Info, and source tarballs: http://www.videolan.org/developers/x264.html
Changelog: http://git.videolan.org/gitweb.cgi?p=x264.git
Vanilla builds: http://x264.nl/
Discussion: http://forum.doom9.org/forumdisplay.php?f=77
http://forum.doom9.org/showthread.php?t=130364


Applied patches, in the order applied (included, unchanged, in the patches folder):

patch -p1 -i ../x264diffs/rang_x264_version.diff
patch -p1 -i ../x264diffs/x264_dll_alignment_fix.01.diff
patch -p1 -i ../x264diffs/k.38.cosmetic.diff
patch -p1 -i ../x264diffs/999.log_param.diff
patch -p1 -i ../x264diffs/x264_progress.indication_r957.diff
patch -p1 -i ../x264diffs/x264_32x32samples_crash.r965.diff
patch -p1 -i ../x264diffs/k.20.x264_fix_stats_file_work.r877.diff
patch -p1 -i ../x264diffs/x264_multithreading_Nth_pass_ratecontrol.r965.diff
patch -p1 -i ../x264diffs/x264_thread_pool.r965.diff
patch -p1 -i ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p1 -i ../x264diffs/999.profiled.01.diff
patch -p1 -i ../x264diffs/k.41.x264_log_file.01k.r928.diff
patch -p1 -i ../x264diffs/k.47.002.VAQmod.diff
patch -p1 -i ../x264diffs/k.52.PsyRD_0.6.r955.diff
patch -p1 -i ../x264diffs/k.53.x264_new_bframe_decision_04.7.diff


CLI used for build: ./configure --enable-shared --extra-cflags="-march=athlon -pipe"
make fprofiled VIDS="../enctests/deadline_cif.y4m"

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

[burfadel]

Thread pool results in a higher frame rate encoding and better cpu utilisation, as tested earlier (just confirming it works well with its latest revision). Knowing the number for the queue is the hard part, maybe for a default it could be double the number of available simultaneous threads or something? (or related to the number of threads set if not auto). VAQ2 is a hard one though, I can understand why it hasn't been added yet. I'm surprised part of it hasn't been added, and thats aq mode 3 (hybrid mode).

[Dark Shikari]

Thread pool results in a higher frame rate encoding and better cpu utilisation, as tested earlier (just confirming it works well with its latest revision). Knowing the number for the queue is the hard part, maybe for a default it could be double the number of available simultaneous threads or something? (or related to the number of threads set if not auto). VAQ2 is a hard one though, I can understand why it hasn't been added yet. I'm surprised part of it hasn't been added, and thats aq mode 3 (hybrid mode).AQ mode 1 will eventually be removed completely once I modify VBV to take advantage of AQ. The patch is mostly ready but needs some bugfixes and tweaks.

--aq-mode 1 will then become VAQ, and other AQs will be insertable rather simply.

[Ranguvar]

What CPU did you test with? According to DS, it should improve utilization with 8 cores and beyond, possibly with 4, and decrease utilization of less CPUs. But tests mean most. On my quad, with --threads auto, there's no difference.

[skystrife]

Ranguvar:
I guess you got GCC-4.3.2 from TDM's website and have overwritten all your old files with the new ones from TDM's zip/tar.gz packages. The problem is that the gcc-4.3.2-tdm-1-core.tar.gz package includes pthreadGC2.dll and pthreadGCE2.dll in its /bin folder, libpthreadGCE2.a, libpthreadGC2-static.a and libpthread.a in its /lib folder and pthread.h, sched.h and semaphore.h in its /include folder. You probably copied over those files to your MinGW /bin, your MinGW /include and your MinGW /lib folder folder.
I suggest you remove all these files, get the latest pthread cvs (cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/pthreads-win32 checkout pthreads), compile (make clean GC-static) and install it (copy libpthreadGC2.a to your MinGW /lib folder and copy pthread.h, sched.h and semaphore.h to your MinGW /iclude folder). That way you will eliminate the need of x264.exe for an extra pthreadGC2.dll in C:\Windows\System32.
Trust me on this one, I had the same problem.

I also suggest you people update your GPAC libraries. Many have reported errors building it from CVS, however I have found a nasty trick that actually works:
1. download the old stable tarball from here http://downloads.sourceforge.net/gpac/gpac-0.4.4-rc2.tar.gz
2. once it is downloaded, extract it to your MSYS /home/username folder and cd into it (i.e. cd /home/username/gpac)
3. while inside the gpac folder get the latest GPAC CVS using the command cvs -z3 -d:pserver:anonymous@gpac.cvs.sourceforge.net:/cvsroot/gpac co -P gpac
4. run ./configure && make lib
5. copy /home/username/gpac/include/gpac to your MinGW /include folder

P.S.: If this doesn't work for you try it in your /home folder (i.e. /home/gpac).


This, as far as I can tell, does not build the new library (for GPAC).

Look at it this way: if you extract the old library source to ~/gpac, and then cd to ~/gpac, checking out from cvs using that command will put the NEW GPAC source in ~/gpac/gpac.

So, when you configure and make in ~/gpac, you're building the old libraries that you extracted, and not the ones you checked out. If you cd to ~/gpac/gpac, you'll find the new library there with its own configure. If you try to make the new library, it will fail.

tl;dr: making GPAC in mingw still doesn't work, unless I misunderstand your method.

EDIT: also, lol @ the massive amounts of patches circulating. More patches != better; a lot of this stuff hasn't been comitted for a reason. I'm fine with playing with the patches, but some of these (as explained by DS on #x264) make changes that don't make sense or changes that only apply to VfW.

[burfadel]

There's a slight different on dual core, but then again its possibly related to filters being used etc! it wasn't a very thorough test. Its possibly related to the sharing of one core of the cpu for the avisynth filters and x264. I think avisynth filters should run at a higher priority than x264 so x264 doesn't take processing time away from the avisynth filters, which could potentially improve performance (this could be the case even with a multithreaded avisynth). That way there is an improved flow of data to x264, and in the case where there isn't an avisynth filter bottleneck x264 can still utilise that processing capability. Besides the basic 'realtime, abovenormal, normal, below normal, low, and idle priorities, isn't there a more thorough scale that can be utilised? such that even if the priority of x264 is set to low, the avisynth filters runs at a priority of between low and below normal and hence you end up with potentially faster processing...

(I'm guessing threal pool has an effect such as this, in a way)

[Sagekilla]

I remember the thread pool patch from a very long time ago --- It was back when someone had access to dual quad cores (What a dream..) or something to that effect, and the thread pool patch increased encoding speed and CPU utilization a good deal.

[komisar]

Ranguvar
Check you build for --log-file... (k.41.x264_log_file.01k.r928.diff) This patch should be applied as soon as possible.

P.S. See encoder/encoder.c. File close earlier than shown recent data in "void x264_encoder_close ( x264_t *h )"

New version of this patch without depending on applying order: k.54.x264_log_file.02k.r928.diff (http://komisar.gin.by/x.patch/last.used/k.54.x264_log_file.02k.r928.diff)

[DarkZell666]

I remember the thread pool patch from a very long time ago --- It was back when someone had access to dual quad cores (What a dream..) or something to that effect, and the thread pool patch increased encoding speed and CPU utilization a good deal.

Here it is (thread started by morph166955) : http://forum.doom9.org/showthread.php?t=124557

:cool:

[komisar]

skystrife, this is my working script for build GPAC from CVS (static lib, static mp4box) for specified platform:#!/bin/sh

g_cvs=~/gpac
g_bld=~/gpac.bld

# Update GPAC from CVS
cd ${g_cvs}
export CVSROOT=:pserver:anonymous@gpac.cvs.sourceforge.net:/cvsroot/gpac
#cvs login
#....for initial grab source
#cvs checkout gpac
#....for update
cvs update

# Make building environment
mkdir -p ${g_bld}
rm -rf ${g_bld}/*
cp -rf ${g_cvs}/* ${g_bld}/

cd ${g_bld}/gpac

#o_arch=generic ; cf_ar="-mtune=generic"
#o_arch=i686 ; cf_ar="-march=i686 -mtune=i686"
o_arch=nocona ; cf_ar="-march=nocona -mtune=nocona"
#o_arch=k8 ; cf_ar="-march=k8 -mtune=k8"
#o_arch=k8-sse3 ; cf_ar="-march=k8-sse3 -mtune=k8-sse3"
#o_arch=amdfam10 ; cf_ar="-march=amdfam10 -mtune=amdfam10"
#o_arch=core2 ; cf_ar="-march=core2 -mtune=core2"

o_cmn="-O4 -finline-functions -mno-cygwin -mwin32 -m32 -fno-strict-aliasing -Wno-pointer-sign"

cf="${o_cmn} ${cf_ar}"

mkdir -p "/arch/${o_arch}"

o1="--prefix=/arch/${o_arch}"
o2="--strip \
--disable-ipv6 \
--disable-wx \
--disable-oss-audio \
--disable-x11-shm \
--disable-x11-xv \
--disable-opengl \
--disable-ssl \
--use-js=no \
--use-ft=no \
--use-jpeg=no \
--use-png=no \
--use-faad=no \
--use-mad=no \
--use-xvid=no \
--use-ffmpeg=no \
--use-ogg=no \
--use-vorbis=no \
--use-theora=no \
--use-openjpeg=no \
--disable-shared \
--enable-static \
--extra-ldflags=-s"

./configure $o1 $o2
cp -f ./config.h include/gpac/internal/
cp config.mak config.mak2
sed -e "s/OPTFLAGS.*/& ${o_cmn} ${cf_ar}/; s/CPPFLAGS.*/& ${o_cmn} ${cf_ar}/" config.mak2 > config.mak

#... Make LIB (static)
make lib
make install-lib

#... Make mp4box.exe
cd applications/mp4box
mv -f Makefile Makefile.orig
sed -e "s/^LINKFLAGS+=/#.LINKFLAGS+=/; s/#LINKFLAGS+=/LINKFLAGS+=/" Makefile.orig > Makefile
make
cd ../../
mkdir -p /arch/${o_arch}/bin
cp -f bin/gcc/MP4Box.exe /arch/${o_arch}/bin/

[kemuri-_9]

doing mtune with march is redundant: march calls mtune as well
Moreover, specifying -march=cpu-type implies -mtune=cpu-type.

and all of those disable and use no's on the libraries are redundant as they are defaulted off in the configure as is as well.

[komisar]

This is only work example to compile GPAC. Modify this as you wish...
And I usually use full line/options, that there was no misunderstanding ...

[skystrife]

new_bframe_decision patch breaks with the new revision.

And as I was going through the patch, there are still really stupid lines in it (for example, removing a line and replacing it with the same exact line). I'm going to wait and see if there's another "official" patch made for it before making my build.

[kemuri-_9]

r967:
@@ -414,9 +426,14 @@ no_b_frames:
{
int pthresh = X264_MAX(INTER_THRESH - P_SENS_BIAS * (j-1), INTER_THRESH/10);
int pcost = x264_slicetype_frame_cost( h, &a, frames, 0, j+1, j+1, 1 );
-// fprintf( stderr, "frm%d+%d: %d <=> %d, I:%d/%d \n",
-// frames[0]->i_frame, j-1, pthresh, pcost/i_mb_count,
-// frames[j+1]->i_intra_mbs[j+1], i_mb_count );
+/* if( i_mb_count )
+ fprintf( stderr, "frm%d+%d: %d <=> %d, I:%d/%d \n",
+ frames[0]->i_frame, j-1, pthresh, pcost/i_mb_count,
+ frames[j+1]->i_intra_mbs[j+1], i_mb_count );
+ else
+ fprintf( stderr, "frm%d+%d: %d <=> %d, I:%d/%d \n",
+ frames[0]->i_frame, j-1, pthresh, pcost,
+ frames[j+1]->i_intra_mbs[j+1], i_mb_count ); */
if( pcost > pthresh*i_mb_count || frames[j+1]->i_intra_mbs[j+1] > i_mb_count/3 )
{
frames[j]->i_type = X264_TYPE_P;

change in commented out fprintf()s for (assuming) debugging purposes causes the patch rejection
fix: x264_new_bframe_decision_04.7_r967.diff (http://kemuri9.net/dev/x264/patches/x264_new_bframe_decision_04.7_r967.diff)
just removes the newly commented out section, since that's what it's always done.

[J_Darnley]

new_bframe_decision patch breaks with the new revision.

And as I was going through the patch, there are still really stupid lines in it (for example, removing a line and replacing it with the same exact line). I'm going to wait and see if there's another "official" patch made for it before making my build.
If Dark Shikari doesn't: http://users.telenet.be/darnley/x264_newbframe_0.33.diff
It wasn't that hard to patch manually and those 'stupid lines' that are removed and re-added have different indentation because they are (in the patch) in if else sections.

[skystrife]

If Dark Shikari doesn't: http://users.telenet.be/darnley/x264_newbframe_0.33.diff
It wasn't that hard to patch manually and those 'stupid lines' that are removed and re-added have different indentation because they are (in the patch) in if else sections.

Ah, that explains most of them then.

@@ -337,8 +447,8 @@ static int scenecut( x264_t *h, x264_frame_t *frame, int pdist )
{
f_bias = f_thresh_min
+ ( f_thresh_max - f_thresh_min )
- * ( i_gop_size - h->param.i_keyint_min )
- / ( h->param.i_keyint_max - h->param.i_keyint_min );
+ * ( i_gop_size - h->param.i_keyint_min )
+ / ( h->param.i_keyint_max - h->param.i_keyint_min ) ;
}

res = pcost >= (1.0 - f_bias) * icost;

This one still seems asinine though. A space? lol.

Thanks for the work on the patches you two. =)

[kemuri-_9]

This one still seems asinine though. A space? lol.

patches and diffs are natively whitespace sensitive, so any changes in whitespace will cause a flag to occur saying 'this is different code'
that is unless diff -b or patch -l is used, which causes them to ignore whitespace changes

[skystrife]

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

Patches used:

x264_psy_rdo_0.6_r956.diff
x264_new_bframe_decision_04.7_r967.diff
x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

Updated GPAC (on my machine, I had to manually add #define GPAC_DISABLE_3D and #undef GPAC_HAS_SPIDERMONKEY to certain files; it seems that by default gpac wasn't respecting --disable-opengl and was not properly setting that my machine lacks spidermonkey, despite it showing no spidermonkey in configure. PITA.)

Progress indication was comitted, though I would have liked to have seen the percent from the taskbar, but that's a fairly minor thing. I didn't feel like tampering with it because I wasn't sure how to achieve that without adding another sprintf or a bunch of unnecessary lines or screwing up the order of things in the stderr.

[Quark.Fusion]

x264 [debug]: frame=8128 QP=22.37 NAL=0 Slice:B Poc:70 I:0 P:759 SKIP:1869 size=2165 bytes SSIM Y:0.97253
x264 [debug]: scene cut at 8135 Icost:776180 Pcost:769355 ratio:0.0088 bias:0.0429 gop:44 (imb:2351 pmb:67)
x264 [debug]: frame=8129 QP=20.27 NAL=2 Slice:P Poc:78 I:20 P:2398 SKIP:222 size=24045 bytes SSIM Y:0.97514
x264 [debug]: scene cut at 8135 Icost:776180 Pcost:773055 ratio:0.0040 bias:0.0429 gop:44 (imb:2389 pmb:29)Using «x264 - core 61 r957kVAQmod.PsyRDO 7ce0f2c» with --aud --nal-hrd --b-adapt 2 --threads 6
Any thoughts why scene cut shown 2 times (and with different p-costs)?


Added:x264 [debug]: scene cut at 62081 Icost:775381 Pcost:584246 ratio:0.2465 bias:0.2527 gop:165 (imb:1358 pmb:1060)
x264 [debug]: frame=62075 QP=25.73 NAL=0 Slice:B Poc:316 I:102 P:1389 SKIP:951 size=10770 bytes SSIM Y:0.97702
x264 [debug]: scene cut at 62082 Icost:784761 Pcost:627207 ratio:0.2008 bias:0.2544 gop:166 (imb:1446 pmb:972)
x264 [debug]: frame=62076 QP=22.95 NAL=2 Slice:P Poc:322 I:525 P:2011 SKIP:104 size=21414 bytes SSIM Y:0.98128
x264 [debug]: scene cut at 62083 Icost:759009 Pcost:582593 ratio:0.2324 bias:0.2561 gop:167 (imb:1376 pmb:1042)
x264 [debug]: frame=62077 QP=25.26 NAL=0 Slice:B Poc:320 I:102 P:1449 SKIP:903 size=11029 bytes SSIM Y:0.97672
x264 [debug]: scene cut at 62084 Icost:781821 Pcost:593818 ratio:0.2405 bias:0.2579 gop:168 (imb:1347 pmb:1071)
x264 [debug]: frame=62078 QP=21.45 NAL=2 Slice:P Poc:326 I:471 P:2089 SKIP:80 size=22330 bytes SSIM Y:0.98282
x264 [debug]: scene cut at 62085 Icost:787604 Pcost:600338 ratio:0.2378 bias:0.2596 gop:169 (imb:1406 pmb:1012)
x264 [debug]: frame=62079 QP=25.06 NAL=0 Slice:B Poc:324 I:86 P:1516 SKIP:826 size=10467 bytes SSIM Y:0.97706
x264 [debug]: scene cut at 62086 Icost:775613 Pcost:581677 ratio:0.2500 bias:0.2613 gop:170 (imb:1370 pmb:1048)
x264 [debug]: frame=62080 QP=21.41 NAL=2 Slice:P Poc:328 I:279 P:2253 SKIP:108 size=19776 bytes SSIM Y:0.98263
x264 [debug]: scene cut at 62087 Icost:747724 Pcost:571572 ratio:0.2356 bias:0.2631 gop:171 (imb:1350 pmb:1068)
x264 [debug]: frame=62081 QP=21.42 NAL=2 Slice:P Poc:330 I:324 P:2179 SKIP:137 size=20348 bytes SSIM Y:0.98221
x264 [debug]: scene cut at 62088 Icost:740382 Pcost:570234 ratio:0.2298 bias:0.2648 gop:172 (imb:1348 pmb:1070)
x264 [debug]: frame=62082 QP=21.41 NAL=2 Slice:P Poc:332 I:333 P:2190 SKIP:117 size=20823 bytes SSIM Y:0.98232
x264 [debug]: scene cut at 62089 Icost:731569 Pcost:553133 ratio:0.2439 bias:0.2665 gop:173 (imb:1357 pmb:1061)
x264 [debug]: frame=62083 QP=20.63 NAL=2 Slice:P Poc:334 I:277 P:2274 SKIP:89 size=23119 bytes SSIM Y:0.98292
x264 [debug]: frame=62084 QP=20.72 NAL=2 Slice:P Poc:336 I:302 P:2297 SKIP:41 size=25569 bytes SSIM Y:0.98253
x264 [debug]: frame=62085 QP=20.68 NAL=2 Slice:P Poc:338 I:307 P:2289 SKIP:44 size=24237 bytes SSIM Y:0.98330
x264 [debug]: scene cut at 62092 Icost:753690 Pcost:550045 ratio:0.2702 bias:0.2717 gop:176 (imb:1321 pmb:1097)
x264 [debug]: frame=62086 QP=20.79 NAL=2 Slice:P Poc:340 I:305 P:2268 SKIP:67 size=23533 bytes SSIM Y:0.98343
x264 [debug]: scene cut at 62093 Icost:771156 Pcost:570861 ratio:0.2597 bias:0.2735 gop:177 (imb:1265 pmb:1153)
x264 [debug]: frame=62087 QP=20.80 NAL=2 Slice:P Poc:342 I:301 P:2273 SKIP:66 size=23362 bytes SSIM Y:0.98339
x264 [debug]: frame=62088 QP=20.81 NAL=2 Slice:P Poc:344 I:300 P:2249 SKIP:91 size=22705 bytes SSIM Y:0.98349
x264 [debug]: frame=62089 QP=20.80 NAL=2 Slice:P Poc:348 I:490 P:2088 SKIP:62 size=25018 bytes SSIM Y:0.98341
x264 [debug]: frame=62090 QP=23.01 NAL=0 Slice:B Poc:346 I:92 P:1583 SKIP:744 size=13038 bytes SSIM Y:0.98046
x264 [debug]: scene cut at 62097 Icost:784023 Pcost:581129 ratio:0.2588 bias:0.2804 gop:181 (imb:1333 pmb:1085)
x264 [debug]: frame=62091 QP=20.76 NAL=2 Slice:P Poc:350 I:275 P:2259 SKIP:106 size=21681 bytes SSIM Y:0.98394
x264 [debug]: scene cut at 62098 Icost:801081 Pcost:599438 ratio:0.2517 bias:0.2821 gop:182 (imb:1324 pmb:1094)
x264 [debug]: frame=62092 QP=20.82 NAL=2 Slice:P Poc:352 I:305 P:2254 SKIP:81 size=22144 bytes SSIM Y:0.98398
x264 [debug]: scene cut at 62099 Icost:780568 Pcost:585357 ratio:0.2501 bias:0.2839 gop:183 (imb:1392 pmb:1026)
x264 [debug]: frame=62093 QP=20.90 NAL=2 Slice:P Poc:354 I:258 P:2263 SKIP:119 size=22081 bytes SSIM Y:0.98386
x264 [debug]: scene cut at 62100 Icost:777155 Pcost:593260 ratio:0.2366 bias:0.2856 gop:184 (imb:1424 pmb:994)
x264 [debug]: frame=62094 QP=21.01 NAL=2 Slice:P Poc:358 I:497 P:2065 SKIP:78 size=26679 bytes SSIM Y:0.98346
x264 [debug]: scene cut at 62101 Icost:801314 Pcost:622039 ratio:0.2237 bias:0.2873 gop:185 (imb:1419 pmb:999)
x264 [debug]: frame=62095 QP=22.89 NAL=0 Slice:B Poc:356 I:79 P:1535 SKIP:788 size=13664 bytes SSIM Y:0.98121
x264 [debug]: scene cut at 62102 Icost:875597 Pcost:681520 ratio:0.2217 bias:0.2891 gop:186 (imb:1384 pmb:1034)
x264 [debug]: frame=62096 QP=20.99 NAL=2 Slice:P Poc:360 I:340 P:2171 SKIP:129 size=23042 bytes SSIM Y:0.98359
x264 [debug]: scene cut at 62103 Icost:914066 Pcost:698227 ratio:0.2361 bias:0.2908 gop:187 (imb:1367 pmb:1051)
x264 [debug]: frame=62097 QP=20.91 NAL=2 Slice:P Poc:362 I:340 P:2205 SKIP:95 size=24079 bytes SSIM Y:0.98288
x264 [debug]: scene cut at 62104 Icost:960403 Pcost:706591 ratio:0.2643 bias:0.2925 gop:188 (imb:1333 pmb:1085)
x264 [debug]: frame=62098 QP=21.00 NAL=2 Slice:P Poc:364 I:328 P:2255 SKIP:57 size=26337 bytes SSIM Y:0.98224
x264 [debug]: scene cut at 62105 Icost:986340 Pcost:723324 ratio:0.2667 bias:0.2943 gop:189 (imb:1283 pmb:1135)
x264 [debug]: frame=62099 QP=20.93 NAL=2 Slice:P Poc:366 I:332 P:2227 SKIP:81 size=25912 bytes SSIM Y:0.98242
x264 [debug]: scene cut at 62106 Icost:999890 Pcost:756780 ratio:0.2431 bias:0.2960 gop:190 (imb:1335 pmb:1083)
x264 [debug]: frame=62100 QP=20.98 NAL=2 Slice:P Poc:368 I:402 P:2159 SKIP:79 size=26087 bytes SSIM Y:0.98231
x264 [debug]: scene cut at 62107 Icost:1001275 Pcost:751955 ratio:0.2490 bias:0.2977 gop:191 (imb:1318 pmb:1100)
x264 [debug]: frame=62101 QP=21.05 NAL=2 Slice:P Poc:370 I:359 P:2197 SKIP:84 size=27019 bytes SSIM Y:0.98198
x264 [debug]: scene cut at 62108 Icost:1051536 Pcost:798628 ratio:0.2405 bias:0.2995 gop:192 (imb:1273 pmb:1145)
x264 [debug]: frame=62102 QP=21.94 NAL=2 Slice:P Poc:372 I:352 P:2195 SKIP:93 size=24730 bytes SSIM Y:0.98094
x264 [debug]: scene cut at 62109 Icost:1023935 Pcost:770708 ratio:0.2473 bias:0.3012 gop:193 (imb:1305 pmb:1113)
x264 [debug]: frame=62103 QP=21.93 NAL=2 Slice:P Poc:374 I:377 P:2147 SKIP:116 size=24586 bytes SSIM Y:0.98114
x264 [debug]: scene cut at 62110 Icost:1013837 Pcost:772997 ratio:0.2376 bias:0.3029 gop:194 (imb:1272 pmb:1146)
x264 [debug]: frame=62104 QP=21.97 NAL=2 Slice:P Poc:376 I:381 P:2158 SKIP:101 size=25221 bytes SSIM Y:0.98097
x264 [debug]: scene cut at 62111 Icost:1025942 Pcost:772067 ratio:0.2475 bias:0.3047 gop:195 (imb:1292 pmb:1126)
x264 [debug]: frame=62105 QP=22.15 NAL=2 Slice:P Poc:378 I:384 P:2151 SKIP:105 size=25589 bytes SSIM Y:0.98051
x264 [debug]: scene cut at 62112 Icost:1048089 Pcost:757517 ratio:0.2772 bias:0.3064 gop:196 (imb:1140 pmb:1278)
x264 [debug]: frame=62106 QP=22.11 NAL=2 Slice:P Poc:380 I:338 P:2184 SKIP:118 size=25473 bytes SSIM Y:0.98052
x264 [debug]: scene cut at 62113 Icost:1068835 Pcost:755185 ratio:0.2935 bias:0.3081 gop:197 (imb:1123 pmb:1295)
x264 [debug]: frame=62107 QP=22.12 NAL=2 Slice:P Poc:382 I:345 P:2169 SKIP:126 size=25229 bytes SSIM Y:0.98029
x264 [debug]: scene cut at 62114 Icost:1077272 Pcost:757739 ratio:0.2966 bias:0.3099 gop:198 (imb:1122 pmb:1296)
x264 [debug]: frame=62108 QP=22.34 NAL=2 Slice:P Poc:384 I:317 P:2202 SKIP:121 size=26331 bytes SSIM Y:0.97957
x264 [debug]: scene cut at 62115 Icost:1133533 Pcost:792976 ratio:0.3004 bias:0.3116 gop:199 (imb:1064 pmb:1354)
x264 [debug]: frame=62109 QP=22.38 NAL=2 Slice:P Poc:386 I:382 P:2167 SKIP:91 size=27195 bytes SSIM Y:0.97852
x264 [debug]: scene cut at 62117 Icost:1249817 Pcost:932280 ratio:0.2541 bias:0.3151 gop:201 (imb:1192 pmb:1226)
x264 [debug]: frame=62110 QP=22.34 NAL=2 Slice:P Poc:388 I:361 P:2157 SKIP:122 size=25733 bytes SSIM Y:0.97858
x264 [debug]: frame=62111 QP=22.39 NAL=2 Slice:P Poc:390 I:350 P:2178 SKIP:112 size=25675 bytes SSIM Y:0.97854
x264 [debug]: frame=62112 QP=22.49 NAL=2 Slice:P Poc:392 I:316 P:2229 SKIP:95 size=26869 bytes SSIM Y:0.97737
x264 [debug]: frame=62113 QP=22.65 NAL=2 Slice:P Poc:394 I:326 P:2217 SKIP:97 size=26006 bytes SSIM Y:0.97802
x264 [debug]: frame=62114 QP=22.62 NAL=2 Slice:P Poc:396 I:290 P:2251 SKIP:99 size=25943 bytes SSIM Y:0.97820
x264 [debug]: frame=62115 QP=23.71 NAL=2 Slice:P Poc:400 I:472 P:2077 SKIP:91 size=25940 bytes SSIM Y:0.97627
x264 [debug]: scene cut at 62123 Icost:1482702 Pcost:1053841 ratio:0.2892 bias:0.3255 gop:207 (imb:1049 pmb:1369)
x264 [debug]: frame=62116 QP=26.04 NAL=0 Slice:B Poc:398 I:86 P:1629 SKIP:689 size=12852 bytes SSIM Y:0.97023
x264 [debug]: frame=62117 QP=24.07 NAL=2 Slice:P Poc:404 I:413 P:2148 SKIP:79 size=27551 bytes SSIM Y:0.97534
x264 [debug]: scene cut at 62125 Icost:1502386 Pcost:1033815 ratio:0.3119 bias:0.3289 gop:209 (imb:1152 pmb:1266)
x264 [debug]: frame=62118 QP=26.62 NAL=0 Slice:B Poc:402 I:85 P:1527 SKIP:704 size=13106 bytes SSIM Y:0.97026
x264 [debug]: frame=62119 QP=24.19 NAL=2 Slice:P Poc:408 I:525 P:2048 SKIP:67 size=28224 bytes SSIM Y:0.97525
x264 [debug]: frame=62120 QP=26.58 NAL=0 Slice:B Poc:406 I:101 P:1577 SKIP:681 size=13842 bytes SSIM Y:0.96989
x264 [debug]: frame=62121 QP=24.32 NAL=2 Slice:P Poc:412 I:486 P:2105 SKIP:49 size=29239 bytes SSIM Y:0.97464
x264 [debug]: frame=62122 QP=26.70 NAL=0 Slice:B Poc:410 I:89 P:1640 SKIP:625 size=14296 bytes SSIM Y:0.96888
x264 [debug]: frame=62123 QP=25.59 NAL=2 Slice:P Poc:416 I:576 P:2027 SKIP:37 size=28605 bytes SSIM Y:0.97183
x264 [debug]: scene cut at 62131 Icost:1519014 Pcost:1012988 ratio:0.3331 bias:0.3393 gop:215 (imb:1024 pmb:1394)
x264 [debug]: frame=62124 QP=27.73 NAL=0 Slice:B Poc:414 I:118 P:1603 SKIP:638 size=13116 bytes SSIM Y:0.96424
x264 [debug]: frame=62125 QP=25.69 NAL=2 Slice:P Poc:420 I:435 P:2154 SKIP:51 size=27880 bytes SSIM Y:0.96905
x264 [debug]: scene cut at 62133 Icost:1543733 Pcost:1044587 ratio:0.3233 bias:0.3428 gop:217 (imb:1024 pmb:1394)
x264 [debug]: frame=62126 QP=28.07 NAL=0 Slice:B Poc:418 I:91 P:1771 SKIP:503 size=13408 bytes SSIM Y:0.96416
x264 [debug]: frame=62127 QP=25.52 NAL=2 Slice:P Poc:424 I:461 P:2162 SKIP:17 size=28555 bytes SSIM Y:0.97092
x264 [debug]: frame=62128 QP=28.46 NAL=0 Slice:B Poc:422 I:87 P:1533 SKIP:676 size=13170 bytes SSIM Y:0.96311
x264 [debug]: frame=62129 QP=25.44 NAL=2 Slice:P Poc:428 I:356 P:2210 SKIP:74 size=24827 bytes SSIM Y:0.97111
x264 [debug]: frame=62130 QP=27.75 NAL=0 Slice:B Poc:426 I:59 P:1799 SKIP:510 size=12462 bytes SSIM Y:0.96297
x264 [debug]: frame=62131 QP=25.70 NAL=2 Slice:P Poc:432 I:390 P:2209 SKIP:41 size=27379 bytes SSIM Y:0.97032
x264 [debug]: frame=62132 QP=28.18 NAL=0 Slice:B Poc:430 I:54 P:1521 SKIP:760 size=11716 bytes SSIM Y:0.96462
x264 [debug]: frame=62133 QP=24.53 NAL=2 Slice:P Poc:436 I:341 P:2275 SKIP:24 size=28655 bytes SSIM Y:0.97418
x264 [debug]: frame=62134 QP=28.14 NAL=0 Slice:B Poc:434 I:58 P:1536 SKIP:759 size=11845 bytes SSIM Y:0.96668
x264 [debug]: frame=62135 QP=24.52 NAL=2 Slice:P Poc:440 I:338 P:2273 SKIP:29 size=28248 bytes SSIM Y:0.97365
x264 [debug]: frame=62136 QP=26.72 NAL=0 Slice:B Poc:438 I:41 P:1649 SKIP:630 size=13027 bytes SSIM Y:0.96786
x264 [debug]: frame=62137 QP=24.39 NAL=2 Slice:P Poc:446 I:407 P:2202 SKIP:31 size=28728 bytes SSIM Y:0.97354
x264 [debug]: frame=62138 QP=25.75 NAL=2 Slice:B Poc:444 I:77 P:1519 SKIP:711 size=15115 bytes SSIM Y:0.97197
x264 [debug]: frame=62139 QP=27.85 NAL=0 Slice:B Poc:442 I:59 P:1644 SKIP:674 size=11099 bytes SSIM Y:0.96723
x264 [debug]: frame=62140 QP=24.30 NAL=2 Slice:P Poc:450 I:264 P:2344 SKIP:32 size=25233 bytes SSIM Y:0.97473
x264 [debug]: frame=62141 QP=26.75 NAL=0 Slice:B Poc:448 I:50 P:1637 SKIP:680 size=11791 bytes SSIM Y:0.96765
x264 [debug]: frame=62142 QP=24.33 NAL=2 Slice:P Poc:454 I:280 P:2295 SKIP:65 size=26005 bytes SSIM Y:0.97355
x264 [debug]: frame=62143 QP=26.77 NAL=0 Slice:B Poc:452 I:30 P:1550 SKIP:791 size=10880 bytes SSIM Y:0.97024
x264 [debug]: scene cut at 62151 Icost:1606787 Pcost:1035006 ratio:0.3559 bias:0.3740 gop:235 (imb:807 pmb:1611)
x264 [debug]: frame=62144 QP=24.33 NAL=2 Slice:P Poc:458 I:262 P:2313 SKIP:65 size=26133 bytes SSIM Y:0.97441
x264 [debug]: frame=62145 QP=26.80 NAL=0 Slice:B Poc:456 I:38 P:1475 SKIP:839 size=10691 bytes SSIM Y:0.97035
x264 [debug]: frame=62146 QP=24.46 NAL=2 Slice:P Poc:464 I:357 P:2237 SKIP:46 size=28281 bytes SSIM Y:0.97418
x264 [debug]: frame=62147 QP=25.69 NAL=2 Slice:B Poc:462 I:57 P:1526 SKIP:702 size=14972 bytes SSIM Y:0.97267
x264 [debug]: frame=62148 QP=27.84 NAL=0 Slice:B Poc:460 I:29 P:1621 SKIP:765 size=9674 bytes SSIM Y:0.96795
x264 [debug]: frame=62149 QP=24.55 NAL=2 Slice:P Poc:468 I:319 P:2278 SKIP:43 size=26664 bytes SSIM Y:0.97406
x264 [debug]: frame=62150 QP=26.72 NAL=0 Slice:B Poc:466 I:34 P:1631 SKIP:704 size=12208 bytes SSIM Y:0.96914
x264 [debug]: frame=62151 QP=25.55 NAL=2 Slice:P Poc:472 I:265 P:2271 SKIP:104 size=23896 bytes SSIM Y:0.97264
x264 [debug]: frame=62152 QP=27.82 NAL=0 Slice:B Poc:470 I:25 P:1635 SKIP:732 size=10261 bytes SSIM Y:0.96771
x264 [debug]: scene cut at 62160 Icost:1569636 Pcost:965797 ratio:0.3847 bias:0.3896 gop:244 (imb:835 pmb:1583)
x264 [debug]: frame=62153 QP=25.55 NAL=2 Slice:P Poc:476 I:225 P:2321 SKIP:94 size=23795 bytes SSIM Y:0.97040
x264 [debug]: frame=62154 QP=27.85 NAL=0 Slice:B Poc:474 I:26 P:1537 SKIP:814 size=9639 bytes SSIM Y:0.96746
x264 [debug]: frame=62155 QP=25.55 NAL=2 Slice:P Poc:482 I:303 P:2275 SKIP:62 size=25300 bytes SSIM Y:0.97150
x264 [debug]: frame=62156 QP=26.98 NAL=2 Slice:B Poc:480 I:45 P:1462 SKIP:770 size=11967 bytes SSIM Y:0.97105
x264 [debug]: frame=62157 QP=28.94 NAL=0 Slice:B Poc:478 I:26 P:1576 SKIP:820 size=8271 bytes SSIM Y:0.96661
x264 [debug]: frame=62158 QP=25.56 NAL=2 Slice:P Poc:486 I:221 P:2374 SKIP:45 size=22860 bytes SSIM Y:0.97338
x264 [debug]: frame=62159 QP=28.29 NAL=0 Slice:B Poc:484 I:26 P:1514 SKIP:855 size=9540 bytes SSIM Y:0.96882
x264 [debug]: frame=62160 QP=24.37 NAL=2 Slice:P Poc:490 I:298 P:2319 SKIP:23 size=25384 bytes SSIM Y:0.97617
x264 [debug]: frame=62161 QP=27.90 NAL=0 Slice:B Poc:488 I:33 P:1531 SKIP:796 size=9639 bytes SSIM Y:0.96847
x264 [debug]: frame=62162 QP=24.31 NAL=2 Slice:P Poc:494 I:211 P:2357 SKIP:72 size=23749 bytes SSIM Y:0.97614
x264 [debug]: frame=62163 QP=26.86 NAL=0 Slice:B Poc:492 I:39 P:1511 SKIP:837 size=9830 bytes SSIM Y:0.97301
x264 [debug]: frame=62164 QP=24.32 NAL=2 Slice:P Poc:496 I:88 P:2419 SKIP:133 size=19245 bytes SSIM Y:0.97699
x264 [debug]: frame=62165 QP=23.30 NAL=2 Slice:P Poc:498 I:125 P:2468 SKIP:47 size=22525 bytes SSIM Y:0.97848
x264 [debug]: frame=62166 QP=22.33 NAL=3 Slice:I Poc:0 I:2640 P:0 SKIP:0 size=44493 bytes SSIM Y:0.98053

Note where first I-frame is.

[Audionut]

The latest commit sounds good.

"This change improves VBV accuracy and improves bit distribution in CRF and 2pass."

This will help with blu-ray rips I do in CRF.

[Dark Shikari]

x264 [debug]: frame=8128 QP=22.37 NAL=0 Slice:B Poc:70 I:0 P:759 SKIP:1869 size=2165 bytes SSIM Y:0.97253
x264 [debug]: scene cut at 8135 Icost:776180 Pcost:769355 ratio:0.0088 bias:0.0429 gop:44 (imb:2351 pmb:67)
x264 [debug]: frame=8129 QP=20.27 NAL=2 Slice:P Poc:78 I:20 P:2398 SKIP:222 size=24045 bytes SSIM Y:0.97514
x264 [debug]: scene cut at 8135 Icost:776180 Pcost:773055 ratio:0.0040 bias:0.0429 gop:44 (imb:2389 pmb:29)Using «x264 - core 61 r957kVAQmod.PsyRDO 7ce0f2c» with --aud --nal-hrd --b-adapt 2 --threads 6
Any thoughts why scene cut shown 2 times (and with different p-costs)?Probably because b-adapt 2 calls scenecut repeatedly in order to avoid having its B-frames cross a potential scenecut. Since it calls scenecut in many different possible combinations of B-frames, it'll have different costs each time.

[kemuri-_9]

currently rebasing patches for the rejections, will be editing this as they come along:

x264_psy_rdo_0.6_r968.diff (http://kemuri9.net/dev/x264/patches/x264_psy_rdo_0.6_r968.diff)
x264_new_bframe_decision_04.7_r968.diff (http://kemuri9.net/dev/x264/patches/x264_new_bframe_decision_04.7_r968.diff)

that should do it.

[bob0r]

Some blocking bugs reports in x264 encodes and bluray H.264 streams let me to believe CoreAVC is at fault and this reported it here: coreavc marvel bug (http://forum.doom9.org/showthread.php?p=1183272#post1183272)

I will no longer be patching with psy_rdo or new_bframe_decision as if no changes are made to the actual code, it should be added to GIT or not used at all.

[Avenger007]

I will no longer be patching with psy_rdo or new_bframe_decision as if no changes are made to the actual code, it should be added to GIT or not used at all.
FINALLY!!! someone is taking a stand and forcing the devs to commit these overdue patches!
:thanks:

[techouse]

The things are waaay too experimental to commit, imho. But it's the developers' words that count.

[gigah72]

imo LHC@CERN is far more experimental ... ;)
but i'd also, ehm, vote (?!) for commiting to main, as i use both patches all the time and my pc still didn't explode. it's more dangerous, that someone would introduce a bug by trying to fix rejections, though commiters are also human, making mistakes, sometimes.

[Sharktooth]

Some blocking bugs reports in x264 encodes and bluray H.264 streams let me to believe CoreAVC is at fault and this reported it here: coreavc marvel bug (http://forum.doom9.org/showthread.php?p=1183272#post1183272)

I will no longer be patching with psy_rdo or new_bframe_decision as if no changes are made to the actual code, it should be added to GIT or not used at all.
if the fault is coreavc then there are no reasons to not use those patches.
corecodec should fix their decoder...

[bob0r]

Yes but some people thought the patches (psy rdo/trellis) could cause the errors, obviously it does not, hence my statement, enough tested now, time to make up their minds. :D

[buzzqw]

yes, going to snv would be a lot better.. at least for linux users, since no one are building latest snapshot+patch for *nix :(

BHH

[Sharktooth]

@bobor: if the problem is coreavc not decoding standard compliant streams, they should fix it or ppl have to use other decoding softwares.
i dont see the reason to cripple something to fix a problem related to another software...
that said, screw coreavc until it gets fixed. they get paid to do that...

request: fprofiled r968 (generic) + psy-rdo/psy-trellis + hrd & pulldown + new bframe decision (optional)

[kemuri-_9]

(currently r968)
x264_notes.txt (http://kemuri9.net/dev/x264/x264_notes.txt)
x264_longhelp.txt (http://kemuri9.net/dev/x264/x264_longhelp.txt)

AMD:
x264_athlon-xp.exe (http://kemuri9.net/dev/x264/x264_athlon-xp.exe)
x264_profile.i686.gcc-3.4.5.athlon-xp.log (http://kemuri9.net/dev/x264/x264_profile.i686.gcc-3.4.5.athlon-xp.log)

Intel:
x264_pentium2.exe (http://kemuri9.net/dev/x264/x264_pentium2.exe)
x264_profile.i686.gcc-3.4.5.pentium2.log (http://kemuri9.net/dev/x264/x264_profile.i686.gcc-3.4.5.pentium2.log)

i had the build up since last night when i was working to fix the rejecting patches, i don't like spamming this thread with new revisions every time there is one.
people may not like my build since i personally have psy-rd default to off, to maintain vanilla build results unless it's turned on.

[skystrife]

x264.968.modified.exe (http://rapidshare.com/files/145223899/x264.968.modified.exe.html) (Rapidshare, Mediafire is having issues for me atm) - Alternate Download (http://skystrife.com/x264/x264.968.modified.exe)

Patches used:

x264_psy_rdo_0.6_r968.diff
x264_new_bframe_decision_04.7_r968.diff
x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

This one has psyrd defaulted to on as usual.

[gav1577]

x264.968.modified.exe (http://rapidshare.com/files/145223899/x264.968.modified.exe.html) (Rapidshare, Mediafire is having issues for me atm) - Alternate Download (http://skystrife.com/x264/x264.968.modified.exe)

Patches used:

x264_psy_rdo_0.6_r968.diff
x264_new_bframe_decision_04.7_r968.diff
x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

This one has psyrd defaulted to on as usual.

Thanks skystrife and others new builds are always appreciated :)

[bob0r]

@bobor: if the problem is coreavc not decoding standard compliant streams, they should fix it or ppl have to use other decoding softwares.
i dont see the reason to cripple something to fix a problem related to another software...
that said, screw coreavc until it gets fixed. they get paid to do that...

request: fprofiled r968 (generic) + psy-rdo/psy-trellis + hrd & pulldown + new bframe decision (optional)

I am sorry you don't understand me.
The whole reason for NOT compiling with patches anymore is because the patches are no longer changing and are tested more than enough. It's up to the developers now to add it to GIT or drop it. Or possible resume on a later day.
If it's final: add to GIT, if it's not ready, put it on ice or start developing. If the same happens to psy_rdo as what happened to AQ, i am not going to wait and spend wasted time (auto compiling is a lot less time consuming) on compiling builds which are not "stable/signed by pengvado"!

Use skystrife's builds for now :)

As for CoreAVC i was just pointing out CoreAVC has a problem, and not the x264 patches.... so prepare it for GIT or put it on ice.

And if more tests are needed, all anyone has to do is shout and tons of testers ready!

[lexor]

@bobor: if the problem is coreavc not decoding standard compliant streams, they should fix it or ppl have to use other decoding softwares.
i dont see the reason to cripple something to fix a problem related to another software...


From what bobor said, I don't get the impression that he dropped patch support to fix coreavc compatibility, I think he removed patches because he believes them ready for commit and thus not worth extra effort on part of builders.

I agree for psy_rdo and hdr patches. But new bframes still needs work. It is not linear time currently, aku promised to make it so by reusing motion vectors (or something), but there have been no patch updates for that. So bframe is still under development (I presume). The other 2 had no changes for a long time and only need updating because git keeps changing.

[Sharktooth]

I am sorry you don't understand me.
The whole reason for NOT compiling with patches anymore is because the patches are no longer changing and are tested more than enough. It's up to the developers now to add it to GIT or drop it. Or possible resume on a later day.
If it's final: add to GIT, if it's not ready, put it on ice or start developing. If the same happens to psy_rdo as what happened to AQ, i am not going to wait and spend wasted time (auto compiling is a lot less time consuming) on compiling builds which are not "stable/signed by pengvado"!

Use skystrife's builds for now :)

As for CoreAVC i was just pointing out CoreAVC has a problem, and not the x264 patches.... so prepare it for GIT or put it on ice.

And if more tests are needed, all anyone has to do is shout and tons of testers ready!
uh, sorry. i got the impression it was due to coreavc problems.

[burfadel]

Its good to see that the new b-frame decision is added as an option with 969, but just curious whether it will always be available an option or will it be the default once it is fully optimised? (it would be easy to set the default to 2 and have 1 as the original as is at the moment if that does every happen)!

[bob0r]

I am quite sure the best speed/quality trade off will be set as default, and that ofcourse is always the goal of the x264 devs.
So when its fast enough, it will replace the current b-frame methods.... maybe the old will be an option, maybe it will disappear.

[ImmortAlex]

... x264's improved B-frame decision will be patched into the official version within a few days ...
Sounds good!

[kemuri-_9]

trying to make a new build and getting some errors trying to access the git repository:

git.videolan.org[0: 91.121.111.144]: errno=No such file or directory
fatal: unable to connect a socket (No such file or directory)

git.videolan.org[0: 91.121.111.144]: errno=Invalid argument
fatal: unable to connect a socket (Invalid argument)

can anyone else confirm?

[Sagekilla]

In r969, was the whole b-frame patch (the latest one anyway) applied or are there new parts to this that have been included? I've been reading through the description (Heh, are you uploading with --verbose now to git? :p) and I'm seeing a few things I wasn't even aware of before.

[skystrife]

trying to make a new build and getting some errors trying to access the git repository:

can anyone else confirm?

Confirmed.

$ git pull
git.videolan.org[0: 91.121.111.144]: errno=No error
fatal: unable to connect a socket (No error)

[Sagekilla]

accessing git.videolan.org seems to be a bit off lately. I tried checking last night too and the whole videolan.org site was down, with the git portion variably accesible.

[komisar]

x264 GIT:969 source
http://komisar.gin.by/test/x264_969_src.7z

[stanjr]

yes, going to snv would be a lot better.. at least for linux users, since no one are building latest snapshot+patch for *nix :(

BHHI could build this for you for 64bit Ubuntu Linux if you want.

[buzzqw]

i actually can compile git versione without problem (./configure --enable-pthread --enable-mp4-output)
but.. i miss the patches

anyway.. on last git b-adapt is committed, just missing the psy-rd and hrd_pulldown

and.. btw i use 32bit debian sid

thanks a lot for your offer stanjr!

BHH

[kemuri-_9]

x264 GIT:969 source
http://komisar.gin.by/test/x264_969_src.7z

thanks for providing!
since it's CRLF, makes things more of a pain though

and stanjr should still be able to compile for x86 linux on his x64 one, by using
(iirc) --host=i686-pc-linux-gnu
which may or may not need --extra-cflags=-m32 as well

going to need the gcc multilib packages to do that tho.

[ImmortAlex]

Hey, GIT is on again and psy-rd is commited! Waiting for fresh builds...

[martino]

yes, going to snv would be a lot better.. at least for linux users, since no one are building latest snapshot+patch for *nix :(

BHH
Actually, I started after switching to Ubuntu.

[buzzqw]

i am compiling too (for anyone speaking italian http://forum.divxmania.it/x264-linux-build-14092008/t11427/n.html )

@ImmortAlex
git is out for me... are you sure you can git clone git://git.videolan.org/x264.git ?

BHH

[Ranguvar]

Git is back online :)

[Comatose]

Dead for me ><

[LoRd_MuldeR]

Doesn't work for me either, I still get:

LoRd_MuldeR@MULDER_NEU /c/downloads/x264_git
$ ./build.sh
Initialize x264/.git
Initialized empty Git repository in c:/downloads/x264_git/x264/.git/
git.videolan.org[0: 91.121.111.144]: errno=No such file or directory
fatal: unable to connect a socket (No such file or directory)

[burfadel]

GIT back online, seems nice and fast now unlike a couple of hours ago. The downside is that bobor's site x264.nl seems to have missed the last two git commits, which is now Psy-rd (on by default) and psy-trellis (optional) :) and some hadamard stuff. Its just unfortunate GIT when down when these goodies were committed!

[LoRd_MuldeR]

GIT back online, seems nice and fast now unlike a couple of hours ago. The downside is that bobor's site x264.nl seems to have missed the last two git commits, which is now Psy-rd (on by default) and psy-trellis (optional) :) and some hadamard stuff. Its just unfortunate GIT when down when these goodies were committed!

No, it's not back online. At least I cannot check out. Or something has changed and I need to adjust my command? :confused:

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

[komisar]

Git on web online... But "git clone" not work. Alternatively, you can take snapshot from http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog

[kemuri-_9]

yeah but the snapshots also don't have any of the git repository information within them,
so the ./configure in x264 will go :mad: from not having the information to write in the version build number

[komisar]

Of course. The option for "impatient". :-)
As we have seen already 971 available

[Inventive Software]

This is the build I've been waiting for. I'll wait for x264.nl to chuck a build online before I start transcoding. :)

[kemuri-_9]

Of course. The option for "impatient". :-)
As we have seen already 971 available

yeah psy-rd is included for 970 and hardamard added to psy-rd in 971

looking at the raw diffs, seems that psy-rd will be on by default and psy-trellis is off by default,
which is actually better for me since i've seen psy-trellis be hit and miss on my anime encodes.

-Edit-
meh, i'll go ahead and get a build in and manually put in the version definitions

-Edit2-
Git seems to be working again

[LoRd_MuldeR]

looking at the raw diffs, seems that psy-rd will be on by default and psy-trellis is off by default.

How do you enable Psy Trellis now? Simply with "--trellis 1" respectively "--trellis 2" or is there a new switch?

Git seems to be working again

Confirmed :)

[kemuri-_9]

How do you enable Psy Trellis now? Simply with "--trellis 1" respectively "--trellis 2" or is there a new switch?
Confirmed :)

it's the same switch, just do --psy-rd 1.0 or 1.0:1.0 to enable both


--psy-rd Strength of psychovisual optimization ["1.0:0.0"]
#1: RDO (requires subme>=6)
#2: Trellis (requires trellis, experimental)

[LoRd_MuldeR]

it's the same switch, just do --psy-rd 1.0 or 1.0:1.0 to enable both

Oh, I see :o

[elguaxo]

no more patches? http://img89.imageshack.us/img89/7123/mspacman2thwb6.gif

[kemuri-_9]

no more patches? http://img89.imageshack.us/img89/7123/mspacman2thwb6.gif

the hrd pulldown is the only left as the mostly used ones go

and the devs already stated they won't commit it until it has some factual basis for working (iirc)

[stanjr]

no more patches? http://img89.imageshack.us/img89/7123/mspacman2thwb6.gifMaybe this one will still be useful for those of us encoding on Linux:Second Pass ETA Patch:
Current: http://www.benswebs.com/public/x264/patches/x264_fp-eta.01.r680.diff
Creator/Maintainer: morph166955
Description: Forces x264 to use the frame count from the stats file on a second pass if the frame count can't be calculated for some reason (such as the use of a fifo pipe).

[kemuri-_9]

Maybe this one will still be useful for those of us encoding on Linux:

that'll be useful only in the cases where piping occurs, which is mostly the current standard practice for the linux side
(since they for some reason don't want to save .y4m/.yuv files and encode from them :p)

but it also makes me wonder how avisynth 3.0 has been designed to handle passing off to linux based encoders (since it is platformless)....

[stanjr]

How in the heck is that patch supposed to be applied? I get this when trying to apply it:stanjr@stanjr-desktop:~/Programs/Source/mplayer-x264/x264$ patch -p1 -i ../x264diffs/x264_fp-eta.01.r680.diff
patch: **** Only garbage was found in the patch input.

[Ranguvar]

You probably need to convert it to the Unix line-end convention. Try dos2unix.

[kemuri-_9]

patch -p 0 -i ../x264patches/x264_fp-eta.01.r680.diff
patching file encoder/ratecontrol.c
Hunk #1 succeeded at 409 (offset 57 lines).
patching file x264.c
Hunk #1 succeeded at 799 (offset 36 lines).
patching file x264.h
Hunk #1 succeeded at 156 with fuzz 2 (offset 9 lines).


my text editor already recognizes it as LF only (unix style)

[skystrife]

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

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

psyrd and b-adapt 2 patches have been committed!

[gav1577]

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

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

psyrd and b-adapt 2 patches have been committed!

Nice 1 thanks

[Romario]

Please, skystrife, can you compile 64-bit build of your patched versions of x264 ?

It's about time, it's shame not to have 64-bit build in year 2008.

[LoRd_MuldeR]

Please, skystrife, can you compile 64-bit build of your patched versions of x264 ?

x264 doesn't support x64 Windows. I think it could be built for x64 Windows by disabling all the Assembly, but that wouldn't make sense, speed-wise...

[kemuri-_9]

x264 doesn't support x64 Windows. I think it could be built for x64 Windows by disabling all the Assembly, but that wouldn't make sense, speed-wise...

yes i have made x64 builds but the assembly does not work with it (seg faults right at the start), and when disabling the assembly it's slower than the x86 with assembly.

[LoRd_MuldeR]

yes i have made x64 builds but the assembly does not work with it (seg faults right at the start), and when disabling the assembly it's slower than the x86 with assembly.

That's because Win-x64 uses a different calling convention than Linux-x64 and hence the x264 assembly won't work on Win-x64 (but on Linux-x64 it does).
It's a known problem, but currently none of the developers is willing to fix it...

[akupenguin]

None of the developers has win64 nor is willing to install it. But you can help by donating a shell account on a win64/cygwin box.

[LoRd_MuldeR]

None of the developers has win64 nor is willing to install it. But you can help by donating a shell account on a win64/cygwin box.

I'm running WinXP x64 Edition. If you tell me what to do, I'll do what I can...

[Ranguvar]

Same as above.

[akupenguin]

I don't actually know how, since cygwin isn't designed to be a whole multiuser environment. But there is a sshd, maybe that's enough.

[kemuri-_9]

None of the developers has win64 nor is willing to install it. But you can help by donating a shell account on a win64/cygwin box.

win64, msys + mingw 64, and RDP?
does that sound sufficient, or would you still rather prefer sshd?

[akupenguin]

win64, msys + mingw 64, and RDP?
does that sound sufficient, or would you still rather prefer sshd?
Sufficient if it works. The only times I've used RDP was RDP-over-X-over-compressed-ssh :)

[Manao]

sshd works well with cygwin, and is surprisingly easy to set up.

[Shinigami-Sama]

Sufficient if it works. The only times I've used RDP was RDP-over-X-over-compressed-ssh :)

rdesktop works wonderfully well on solaris
so it should work on any other *nixy OS

[Ranguvar]

Check the Git log! Awesome new changes!

Home (http://sites.google.com/site/ranguvar13/x264-builds)
Direct download (http://sites.google.com/site/ranguvar13/x264-builds/rang_x264_r0977.7z?attredirects=0), Mirrors (http://www.rapidspread.com/file.jsp?id=abz7nxcc8z)

x264 r977 from Git (patched, fprofiled).
Thanks to the x264 devs, including those who made the patches I use.
Compiled by Ranguvar on September 16th, 2008, with GCC 4.3.2.
DON'T think that because I used march=athlon it restricts the CPUs you can use.
It seems to improve performance (VERY slightly) for all CPUs.

Open this archive with the free, multi-platform tools 7-Zip or p7zip. Compressed with LZMA.
The src folder contains the patched source code.
The bin folder contains a binary executable, and a DLL for those apps that use it
(May not work in AviDemux. Get those DLLs from LoRd_MuldeR).

Git: git://git.videolan.org/x264.git
Info, and source tarballs: http://www.videolan.org/developers/x264.html
Changelog: http://git.videolan.org/gitweb.cgi?p=x264.git
Vanilla builds: http://x264.nl/
Discussion: http://forum.doom9.org/forumdisplay.php?f=77
http://forum.doom9.org/showthread.php?t=130364


Applied patches, in the order applied (included, unchanged, in the patches folder):

patch -p1 -i ../x264diffs/rang_x264_version.diff
patch -p1 -i ../x264diffs/x264_dll_alignment_fix.01.diff
patch -p1 -i ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p0 -i ../x264diffs/x264_fp-eta.01.r680.diff


CLI used for build: ./configure --enable-shared --extra-cflags="-march=athlon -pipe"
make fprofiled VIDS="../enctests/deadline_cif.y4m"

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

[Avenger007]

Check the Git log! Awesome new changes!
:D lol
I guess you're referring to
commit a92bbc2325942d2ceab2ab043727f5943a33bd64 r974
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Tue Sep 16 00:31:26 2008 -0700

Cache motion vectors in lowres lookahead
This vastly speeds up b-adapt 2, especially at large bframes values.
This changes output because now MV prediction in lookahead only uses L0/L1 MVs, not bidir. This isn't a problem, since the bidir prediction wasn't really correct to begin with, so the change in output is neither positive nor negative.
This also allowed the removal of some unnecessary memsets, which should also give a small speed boost.
Finally, this allows the use of the lowres motion vectors for predictors in some future patch.
Btw, thanks for the Athlon builds. :)

[Inventive Software]

Yeah, plus the VBV ones. ;)

[Ranguvar]

Yep :)
And I use march=athlon not for the Athlon CPU, but because it seems to improve performance on all CPUs (especially the Athlons), including my Core 2 Quad :)

[skystrife]

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

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

Excited about the b-adapt 2 speedboost!

[kemuri-_9]

bah *stabs the planet*
I'm having problems accessing the git repository again... guess i'll try waiting it out.... :(

[Ranguvar]

here ya go, unpatched, straight git clone :)

http://www.rapidspread.com/file.jsp?id=dwephtordq

[kemuri-_9]

thanks, but it worked for me this time!
the repository needs to stop being so finicky!

[skystrife]

thanks, but it worked for me this time!
the repository needs to stop being so finicky!

I blame the new VLC release.

[Ranguvar]

ahhh....

[Soichiro]

Excited about the b-adapt 2 speedboost!

Still would like some working multithreading up in there. :(

[Dark Shikari]

Still would like some working multithreading up in there. :(What's the problem? Works fine here...

[kemuri-_9]

What's the problem? Works fine here...

maybe whining that it's not as fast as b-adapt 1?

[Sharktooth]

Still would like some working multithreading up in there. :(
just use a sane number of b-frames.

[Soichiro]

Of course it's all my fault if it's being slow. Of course I'm just whining and being stupid. -_-;

I am using a sane number of b-frames. It's set to 6. And while it's better than before, it still doesn't use all of both cores with --b-adapt 2, which is something ideally I would like to see fixed. It's not too crippling on a dual core (though 70% CPU usage isn't something to be happy about either), but I imagine the new method would cause much more of a slowdown on a 4+ core system.

[Sharktooth]

6 is not sane... 3 (or 4 maybe) is...
and as Dark_Shikari said, even 2 with b-adapt 2 will look better then 16 with b-adapt 1.

[Soichiro]

Well my tests show that 6 is a good balance between speed and quality for animated material. Almost all my anime encodes have shown large (10%+) b-frame usage in up to 6-frame sequences, while beyond 6 frames is below 1%. I would call that "sane".

[Sharktooth]

not with b-adapt 2... using 6 b-frames will kill the encoding speed, so it's not a good balance.
use 3 b-frames with b-adapt 2. also for animes, maybe you better stick with b-adapt 1 and 6 or more b-frames.

[Soichiro]

Has b-adapt 2 shown bad results on anime? o.O

[Dark Shikari]

Has b-adapt 2 shown bad results on anime? o.ONo, I haven't done much testing on anime.

The question is whether you lose more from the lower --bframes than you gain from b-adapt 2, and I highly doubt that is the case.

[Sharktooth]

no, but since anime encodings will be happy with more b-frames, b-adapt 1 is faster and probably will be not much different than b-adapt 2 with less b-frames.

[Dark Shikari]

no, but since anime encodings will be happy with more b-frames, b-adapt 1 is faster and probably will be not much different than b-adapt 2 with less b-frames.We don't know this for sure :p Some testing will have to be done.

I have some anime clips that benefit tremendously from b-adapt 2. Though it might be because they're full of fades.

[Soichiro]

Ah, that makes sense, then. So I should keep using the old method until the new method is more optimized/properly multithreaded, then (unless I have extra time to kill :p).

Thank you. ;D

[Quark.Fusion]

AFAIK --b-adapt 2 can't be multithreaded as it relies on it's previous result (correct me if I'm wrong). Get process explorer and see how much cpu b-adapt thread uses, if it's greatly lesser that 100%/(num of cores) — try thread-pool patch.

[kemuri-_9]

working on some b-adapt comparisons
http://forum.doom9.org/showthread.php?p=1184814#post1184814

[skystrife]

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

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[Sharktooth]

tnx skystrife :)

[gav1577]

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

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

Thanks :)

[fields_g]

If the next 21 builds come as quickly as the last 21, we will be at r1000 in 2 weeks...... wow....

It's not the quantity changes, but the QUALITY of the changes that impress me though! Thanks Devs!!

[burfadel]

Just wondering whether anyone has done tests adjusting the b-frame bias with --b-adapt 2? would be interesting to see the outcome of such tests. A different bias may be beneficial for anime, or resolve those having issues with psy trellis? (thats a question not a statement)!

[Ranguvar]

Sorry for the wait. Busy with encode tests.

Home (http://sites.google.com/site/ranguvar13/x264-builds)
Direct download (http://sites.google.com/site/ranguvar13/x264-builds/rang_x264_r0979.7z?attredirects=0), Mirrors (http://www.rapidspread.com/file.jsp?id=vjhzyxcku8)

x264 r979 from Git (patched, fprofiled).
Thanks to the x264 devs, including those who made the patches I use.
Compiled by Ranguvar on September 18th, 2008, with GCC 4.3.2.
DON'T think that because I used march=athlon it restricts the CPUs you can use.
It seems to improve performance (VERY slightly) for all CPUs.

Open this archive with the free, multi-platform tools 7-Zip or p7zip. Compressed with LZMA.
The src folder contains the patched source code.
The bin folder contains a binary executable, and a DLL for those apps that use it
(May not work in AviDemux. Get those DLLs from LoRd_MuldeR).

Git: git://git.videolan.org/x264.git
Info, and source tarballs: http://www.videolan.org/developers/x264.html
Changelog: http://git.videolan.org/gitweb.cgi?p=x264.git
Vanilla builds: http://x264.nl/
Discussion: http://forum.doom9.org/forumdisplay.php?f=77
http://forum.doom9.org/showthread.php?t=130364


Applied patches, in the order applied (included, unchanged, in the patches folder):

patch -p1 -i ../x264diffs/rang_x264_version.diff
patch -p1 -i ../x264diffs/x264_dll_alignment_fix.01.diff
patch -p1 -i ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p0 -i ../x264diffs/x264_fp-eta.01.r680.diff


CLI used for build: ./configure --enable-shared --extra-cflags="-march=athlon -pipe"
make fprofiled VIDS="../enctests/deadline_cif.y4m"

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

[Ranguvar]

WARNING: --bime b0rked in all revisions since and including r980, including this build. Don't use.

Home (http://sites.google.com/site/ranguvar13/x264-builds)
Direct download (http://sites.google.com/site/ranguvar13/x264-builds/rang_x264_r0982.7z?attredirects=0), Mirrors (http://www.rapidspread.com/file.jsp?id=jdfnjy3qms)

x264 r982 from Git (patched, fprofiled).
Thanks to the x264 devs, including those who made the patches I use.
Compiled by Ranguvar on September 20th, 2008, with GCC 4.3.2.
DON'T think that because I used march=athlon it restricts the CPUs you can use.
It seems to improve performance (VERY slightly) for all CPUs.

Open this archive with the free, multi-platform tools 7-Zip or p7zip. Compressed with LZMA.
The src folder contains the patched source code.
The bin folder contains a binary executable, and a DLL for those apps that use it
(May not work in AviDemux. Get those DLLs from LoRd_MuldeR).

Git: git://git.videolan.org/x264.git
Info, and source tarballs: http://www.videolan.org/developers/x264.html
Changelog: http://git.videolan.org/gitweb.cgi?p=x264.git
Vanilla builds: http://x264.nl/
Discussion: http://forum.doom9.org/forumdisplay.php?f=77
http://forum.doom9.org/showthread.php?t=130364


Applied patches, in the order applied (included, unchanged, in the patches folder):

patch -p1 -i ../x264diffs/rang_x264_version.diff
patch -p1 -i ../x264diffs/x264_dll_alignment_fix.01.diff
patch -p1 -i ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p0 -i ../x264diffs/x264_fp-eta.01.r680.diff


CLI used for build: ./configure --enable-shared --extra-cflags="-march=athlon -pipe"
make fprofiled VIDS="../enctests/deadline_cif.y4m"

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

[gigah72]

under which catergory do the last 3 patches fall (since 979), e.g. stability-, general-, internal-, bug- or ??-fix?
i ask, 'coz i notice a decrease of ~15% in encodingspeed with my usual testfiles?


EDIT:
the problem was in my setup, sorry, speed is OK.

[Warpman]

under which catergory do the last 3 patches fall (since 979), e.g. stability-, general-, internal-, bug- or ??-fix?
i ask, 'coz i notice a decrease of ~15% in encodingspeed with my usual testfiles?

The last 3 commits were mostly bugfixes I don't expect any big performence gain or loss.

[skystrife]

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

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

Apologies for the recent absence--cleaning out the water loop was worth it though.

[Ranguvar]

Home (http://sites.google.com/site/ranguvar13/x264-builds)
Direct Download (http://sites.google.com/site/ranguvar13/x264-builds/rang_x264_r0983.7z?attredirects=0), Mirrors (http://www.rapidspread.com/file.jsp?id=zehc3cjzv8)

x264 r983 from Git (patched, fprofiled).
Thanks to the x264 devs, including those who made the patches I use.
Compiled by Ranguvar on September 20th, 2008, with GCC 4.3.2.
DON'T think that because I used march=athlon it restricts the CPUs you can use.
It seems to improve performance (VERY slightly) for all CPUs.

Open this archive with the free, multi-platform tools 7-Zip or p7zip. Compressed with LZMA.
The src folder contains the patched source code.
The bin folder contains a binary executable, and a DLL for those apps that use it
(May not work in AviDemux. Get those DLLs from LoRd_MuldeR).

Git: git://git.videolan.org/x264.git
Info, and source tarballs: http://www.videolan.org/developers/x264.html
Changelog: http://git.videolan.org/gitweb.cgi?p=x264.git
Vanilla builds: http://x264.nl/
Discussion: http://forum.doom9.org/forumdisplay.php?f=77
http://forum.doom9.org/showthread.php?t=130364


Applied patches, in the order applied (included, unchanged, in the patches folder):

patch -p1 -i ../x264diffs/rang_x264_version.diff
patch -p1 -i ../x264diffs/x264_dll_alignment_fix.01.diff
patch -p1 -i ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p0 -i ../x264diffs/x264_fp-eta.01.r680.diff


CLI used for build: ./configure --enable-shared --extra-cflags="-march=athlon -pipe"
make fprofiled VIDS="../enctests/deadline_cif.y4m"

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

[skystrife]

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

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[Romario]

Why you not use GCC 4.3.2, it's mush better then too old 3.4.5 ?

[Sagekilla]

Just saw r984 hit git, how much of a speedup can we expect from this?

[Dark Shikari]

Just saw r984 hit git, how much of a speedup can we expect from this?Depends on settings, since it speeds up hpel, and hpel is run a constant number of times regardless of settings (so slower settings == less speedup).

I think the speedup should be about 0-1% depending on settings. There's more coming afterwards; I'm going to be merging holger's intra pred and a few other things.

[Sagekilla]

Any speedup is good to hear. On that note, was this the one GSOC project that was "successful," besides the B frame patch you did yourself?

[Dark Shikari]

Any speedup is good to hear. On that note, was this the one GSOC project that was "successful," besides the B frame patch you did yourself?Yes. After this set of patches will come the merging of the other main successful patch.

[skystrife]

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

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[Audionut]

I got problems trying to get the version info.

mingw32 says "./version.sh: git-rev-list: command not found"

msysgit says "./version.sh: line 5: join: command not found"

[Dark Shikari]

I got problems trying to get the version info.

mingw32 says "./version.sh: git-rev-list: command not found"

msysgit says "./version.sh: line 5: join: command not found"The current script doesn't work with the latest version of git because the command names were changed from "git-$command" to "git $command", I think.

[LoRd_MuldeR]

I got problems trying to get the version info.

mingw32 says "./version.sh: git-rev-list: command not found"

msysgit says "./version.sh: line 5: join: command not found"

You must add the Git "bin" folder to your PATH variable. Then the first warning will be gone :)

I do it this way:
export PATH=$PATH:"/c/Program Files (x86)/Git/bin"

EDIT: I currently use Git version 1.5.6.1.1071.g76fb and I get the "join: command not found" warning too (but this seems to be no problem).

[foxyshadis]

Machinae Supremacy talk moved (https://forum.doom9.org/showthread.php?t=141346).

[Audionut]

Thanks guys.

[Lux Delux]

I'm using megui with the latest skystrife build, just now I noticed (in just 1 scene for now) a strange blocking in an area

http://img217.imageshack.us/img217/1049/snapshot20080922004609uq2.jpg (http://imageshack.us)

below is the 1st and 2nd pass settings


Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.exe" --pass 1 --bitrate 1137 --stats "D:\WALKER S1\01\udegrain2.stats"
--ref 16 --mixed-refs --no-fast-pskip --bframes 6
--b-adapt 2 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -1:-1 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct
--me tesa --merange 32 --threads auto --thread-input --sar 59:65 --progress --no-dct-decimate --no-psnr --no-ssim --output NUL "D:\WALKER S1\01\udegrain2.avs"

Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.exe" --pass 2 --bitrate 1137 --stats "D:\WALKER S1\01\udegrain2.stats"
--ref 16 --mixed-refs --no-fast-pskip --bframes 6
--b-adapt 2 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -1:-1 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct
--me tesa --merange 32 --threads auto --thread-input --sar 59:65 --progress --no-dct-decimate --no-psnr --no-ssim --output "D:\WALKER S1\01\udegrain2.mkv" "D:\WALKER S1\01\udegrain2.avs"

[LoRd_MuldeR]

Lux Delux, it usually helps to upload a short sample of your source, which can be used to reproduce the problem...

[Audionut]

I had funky blocking problems like that when I forgot to change the output in mpc from system default.

Changing to haali or vmr9 fixed it.

[Lux Delux]

Yikes it seems it was the ffdshow build I was using, reverted to an older one had the output fine then.

Sorry for the false alarm :o

[LoRd_MuldeR]

Yikes it seems it was the ffdshow build I was using, reverted to an older one had the output fine then.

Sorry for the false alarm :o

You should report that in the ffdshow thread:
http://forum.doom9.org/showthread.php?t=120465&page=214

[Ranguvar]

NOTICE: I have switched back over to Arch GNU+Linux. Therefore, unless someone is willing to help me learn to cross-compile for Windows, I will either stop making builds, or may eventually put XP in a virtual machine and do it from there. :)

[gruntster]

EDIT: I currently use Git version 1.5.6.1.1071.g76fb and I get the "join: command not found" warning too (but this seems to be no problem).
Installing MSYS coreutils (http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=24963) should resolve this warning.

[Audionut]

Revision 987

Fix deblocking + threads + AQ bug

At low QPs, with threads and deblocking on, deblocking could be improperly disabled.
Revision in which this bug was introduced is unknown; it may be as old as b_variable_qp in x264 itself.


Trafficshare Download (http://rapidshare.com/files/147408536/x264-987.rar)


Compiled with gcc 3.4.5
./configure --enable-mp4-output --extra-cflags="-march=athlon -pipe"
fprofiled.

[skystrife]

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

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[bob0r]

x264.987.modified.01.exe (http://files.x264.nl/x264.987.modified.01.exe)
libx264-64.987.modified.01.dll (http://files.x264.nl/libx264-64.987.modified.01.dll)

x264_hrd_pulldown.09_interlace.diff

[komisar]

And my 987 builds also... :) (profiled, patched vaq-mod, unpatсhed as skyfire/bob0r, vfw, tuned)

http://komisar.gin.by/

[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:

[elguaxo]

techouse, could you post a sample? TIA.

[stanjr]

With the x264 r996, I can't get mplayer (r27682) to compile due to libx264.c not knowing what b_bidir_me and b_bframe_rdo are. I tried changing them to i_bidir_me and i_bframe_rdo within libx264.c like with the issue before, but that doesn't work either. What should I make them to get it to compile?

[Sagekilla]

b_bidir_me and b_bframe_brdo paramters were removed from x264. bime is automatically enabled at subme => 5 and b-rdo at subme => 7 I believe.

You need to remove the bime and b-rdo params from mplayer that it's inputting to x264.

[stanjr]

Cool, completely removing them worked!

[kemuri-_9]

Casino Royale; encode's bitrate is 9500 kbps
Subme9 is 5.26% slower on my PC than Subme8.

and what settings was that compared on, as the other settings often do determine the fps speed change for a single specific setting
i.e. subme 8->9 on --me dia and subme 8->9 on --me tesa will likely not have the same percentage-based speed loss.

[techouse]

techouse, could you post a sample? TIA.
http://sets.djslo-forum.com/mp3/memi/shark/

(Strange link, I know...)

and what settings was that compared on, as the other settings often do determine the fps speed change for a single specific setting
i.e. subme 8->9 on --me dia and subme 8->9 on --me tesa will likely not have the same percentage-based speed loss.

aq-strength 0.8
psy-rd 0.8:0.8
trellis 2
level 4.1
ref 5
bframes 16
merange 32
me umh

[skystrife]

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

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[Rodger]

Hi guys,

sorry for answering so late. Been busy updating/upgrading my system. I wanted a new motherboard. Not because of the problem..but to get better performance out of what I already have and man I didn´t get disappointed.
Asus P5Q really shows it to Asus P5B-E. At lower voltage already 150Mhz more core speed and not yet done.
However...just got it all back together, started Megui the update came...PERFECTLY Stable at 3600Mhz here.

[Atak_Snajpera]

However...just got it all back together, started Megui the update came...PERFECTLY Stable at 3600Mhz here.
Only Prime95 will tell you truth about stability :)

[poisondeathray]

Or try Linpack 64-bit, it stresses more than Prime95; temps get about 4-5 degress higher with it than "wimpy" Prime95 :)

[Rodger]

Only Prime95 will tell you truth about stability :)

I tell you both...WAY OVERRATED. It´s a good start. But still I realize very often, that playing 3D-Games or doing video-encodes for hours is a different Kind of stress testing which will in some cases proof you wrong.
Well...as I said...the 3600Mhz is kinda out of the box ;)
Before with tricks and stuff 3430Mhz was a dead end for me with the old board. Now on the P45-board the E8400 finally gets to life ;)
Weel see...the max Vcore will be 1,28V...thats definitive!
And the Ram is only at stock-setting more performance is to gain here to.

But thats clearly OT so...talk will have to be via PM.

[skystrife]

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

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[techouse]

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

Applied patches (current versions):

x264_hrd_pulldown.09_interlace.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 October 3rd 2008, 10:39:01 CEST with GCC-4.3.2 on Windows Vista Business SP-1 64-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

[Audionut]

Revision 999

List of changes from here. http://git.videolan.org/?p=x264.git;a=summary

*Fix minor memory leak accidentally added with the addition of b-adapt 2

*Resolve quality regression in r996
Accidentally removed the wrong line of code. I think this classifies as a "10l".
Thanks to techouse for initial bug report and skystrife for helping me find it.

*rm gtk, avc2avi.
I don't remember why I allowed a gui into the repository in the first place. There's nothing that makes this one special relative to all the other x264 guis.
avc2avi doesn't compile since we removed the bitstream reader. And avc doesn't belong in avi.

x264-999.rar (http://rapidshare.com/files/150504515/x264-999.rar)


edit: no builds from me till about wed arvo aus time. Water pump shat itself and i won't get a replacement till tues. And i'm going away tues-wed.

[Atak_Snajpera]

I tell you both...WAY OVERRATED. It´s a good start. But still I realize very often, that playing 3D-Games or doing video-encodes for hours is a different Kind of stress testing which will in some cases proof you wrong.
I will not agree with you. Prime95 MT version crashes almost immidietely if cpu has too low voltage. x264 works always longer. Besides Prime95 MT always gives me alot higher temp than games or x264. I've never seen situation when Prime95 MT was stable but x264 or games would crash. (Let's focus on cpu only)

[saint-francis]

I will not agree with you. Prime95 MT version crashes almost immidietely if cpu has too low voltage. x264 works always longer. Besides Prime95 MT always gives me alot higher temp than games or x264. I've never seen situation when Prime95 MT was stable but x264 or games would crash. (Let's focus on cpu only)

This is an interesting topic and highly relevant to many of us here on the doom9 forum who are in the pursuit of faster hardware to decrease our encoding time. Can we move it to the hardware forum? I would like to contribute but I don't want to bring this thread OT any more.

[Kurtnoise]

Hmm.... I think i developed a small patch that relaxes the qpfile to be able to only specify certain frames of the video (i believe this was mentioned as a feature request somewhere)
http://kemuri9.net/dev/x264/x264_qpfile_relax.diff
(based on r889)

did you have still this patch somewhere please ?

[MasterNobody]

did you have still this patch somewhere please ?

It was commited in git (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=9c5e557c5544690b22f61614fae9b516c7e53ba1)

[Kurtnoise]

yeah...I asked this because I can't access to the x264 git right now.

[J_Darnley]

Can you not even access the web interface? Diff (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff_plain;h=9c5e557c5544690b22f61614fae9b516c7e53ba1) and on Pastebin (http://pastebin.com/d3a350c84)

[Kurtnoise]

Can you not even access the web interface? Diff (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff_plain;h=9c5e557c5544690b22f61614fae9b516c7e53ba1) and on Pastebin (http://pastebin.com/d3a350c84)
well all is working fine now...so, I suppose that is an issue from videolan.org


10x anyway.

[3ngel]

Hi,
i've discovered and i want to signal a systematic (althoug random) bug wich happens on all Pure Black & White screens or Coda Titles. I discovered it first on Shining (in the Intermezzo BW Writing Titles) the on some movies at the final credits (bw). I post examples.

http://img135.imageshack.us/img135/6769/bug1cbu3.png

http://img222.imageshack.us/img222/1346/bug2cog3.png

Correct
http://img243.imageshack.us/img243/2782/correctce4.png

This happens starting from 994 (not included) to up (998 included).

[buzzqw]

@3ngel

same script and filters?

BHH

[3ngel]

Yes, obviously identical.
The only difference is that the last one (correct) is done with the 994.
I can add that the corrupted pixel is not continous but it's flashing. Prev frame correct, next corrupted, next correct.

[Dark Shikari]

Yes, obviously identical.
The only difference is that the last one (correct) is done with the 994.
I can add that the corrupted pixel is not continous but it's flashing. Prev frame correct, next corrupted, next correct.Let me guess, the problem goes away when you update to the latest libavcodec or use any other decoder?

[3ngel]

Sorry bad guess. Tested with ffdshow, CoreAvc, Sonic, Mpc. Same results.

Moreover the abnormality is exactly repeteable whitin the same source. That is same script,
994 encoded -> ok
995 and up -> bug.

[Dark Shikari]

Sorry bad guess. Tested with ffdshow, CoreAvc, Sonic, Mpc. Same results.

Moreover the abnormality is exactly repeteable whitin the same source. That is same script,
994 encoded -> ok
995 and up -> bug.Post a stream, bug reports are useless without an actual encoded sample.

And if 995 managed to cause a problem, then its GCC's fault, because the purpose of 995 was to add even more constraints to the inline assembler in the hope that GCC would stop breaking our code.

[3ngel]

Ok, as soon i'll post a stream piece.

[3ngel]

This is from the first pic "jiikine". Encoded with 998.

The bug is at 00:11

http://www.megaupload.com/?d=BQHJ7KU2

[Dark Shikari]

This is from the first pic "jiikine". Encoded with 998.

The bug is at 00:11

http://www.megaupload.com/?d=BQHJ7KU2
Are you sure you cut it correctly? That clip doesn't contain the name "Hubbs" in the credits, nor did I notice anything wrong with the video.

[3ngel]

The word is "jiikine" not "hubbs".

Anyway i post the frame from the stream so you can find it

http://img225.imageshack.us/img225/7370/snapshot200810272229042yh9.th.png (http://img225.imageshack.us/my.php?image=snapshot200810272229042yh9.png)http://img225.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

[Dark Shikari]

This is actually rather interesting... its a false skip. This shouldn't happen, especially in this kind of case. I'm going to guess what happened, since you said it began in revision 995, is that the encoder chose a direct macroblock with 8x8 transform, falsely identified all the quantized DCTs as empty, and so declared it a skip.

... any chance you can try a build compiled with a different version of gcc?

[3ngel]

I have downloaded the build from the official first page.
If you link me here the builds i can try, i will gladly do it.

[Dark Shikari]

I have downloaded the build from the official first page.
If you link me here the builds i can try, i will gladly do it.Look at the last couple pages of this thread; there are various other builds you can try. Also, could someone post a build with --disable-asm? If, when compiled with that, there are no problems, its yet another issue with that stupid array_non_zero code that keeps biting us in the ass.

[LoRd_MuldeR]

Here you go:
* http://www.mediafire.com/file/1zinvyjmzry/x264-r999-gcc432.zip
* http://www.mediafire.com/file/m0ymzojczi2/x264-r999-gcc432-noasm.zip
* http://www.mediafire.com/file/liimtvzy0yi/pthreadGC2.zip


BTW: Please don't tell me that x264 r1000 will be a simple bugfix release :D

[J_Darnley]

Rev 999 with ./configure --disable-asm
http://users.telenet.be/darnley/x264/x264_r999_no-asm.7z

[3ngel]

Rev 999 with ./configure --disable-asm
http://users.telenet.be/darnley/x264/x264_r999_no-asm.7z

It seems that with this build the bug doesn't appear. I have done only a piece. Tomorrow i'll do the entire final credits to see if it appears.

[3ngel]

Here you go:
* http://www.mediafire.com/file/1zinvyjmzry/x264-r999-gcc432.zip
* http://www.mediafire.com/file/m0ymzojczi2/x264-r999-gcc432-noasm.zip
* http://www.mediafire.com/file/liimtvzy0yi/pthreadGC2.zip

I've done a complete encode with gcc432 and the bug appears.

I've done a partial encode with gcc432-noasm and the bug doesn't seem to appear. I'm doing a complete encode with this right now (i'll post as it finishes).

As a sidenote with the noasm there is a huge performance drop. In order of 3 fps (noasm) against 15fps (asm).

[LoRd_MuldeR]

As a sidenote with the noasm there is a huge performance drop. In order of 3 fps (noasm) against 15fps (asm).

What a surprise :D

[3ngel]

That's a shame because it seems that we have to sleep in front of the monitor to obtain a correct encode :D

[lexor]

That's a shame because it seems that we have to sleep in front of the monitor to obtain a correct encode :D
I've found that encoding is a lot like watching paint dry. It's boring, but if you don't watch it, it won't dry.

Still I'm surprised that the first compile you've tested (gcc 3.xx) and Lord's gcc4.3x builds break in the same way... usually you can never get gcc to do anything consistently in different versions.

[3ngel]

Finished the encode. Confirmed. With

http://www.mediafire.com/file/m0ymzo...c432-noasm.zip

The encode is bug free, while with the asm version the bug appears.

Can someone do a VC2008 asm/noasm compile builds so i can repeat and compare the test?

EDIT:
the first compile you've tested and Lord's gcc4.3x builds break in the same way
The first compile doesn't break as i said. Infact is noasm

[Dark Shikari]

Can someone do a VC2008 asm/noasm compile builds so i can repeat and compare the test?Not useful; everything except GCC won't even build the inline assembly.

Useful would be using other versions of GCC to try to spot which ones cause things to break. I use 3.4, so odds are no problems occur in such old versions.

[3ngel]

Not useful; everything except GCC won't even build the inline assembly.

I see.

Useful would be using other versions of GCC to try to spot which ones cause things to break.

Well, if someone can do these builds i'm here :)

[LoRd_MuldeR]

My builds posted above were built with MinGW/GCC v4.3.2 tdm-1 (SJLJ Unwinding).

You can find MinGW/GCC v3.4.6 builds on http://www.x264.nl/ for example...

[3ngel]

MinGW/GCC v4.3.2 tdm-1 (SJLJ Unwinding) -> Broken

I would prefer to download directly from a link instead of a dir in order to avoid i get a wrong version. So if you can link them here i think it would be better.

[LoRd_MuldeR]

MinGW/GCC v4.3.2 tdm-1 (SJLJ Unwinding) 4.3.2 -> Broken

Do the MinGW/GCC v3.4.6 builds work any better? :confused:


I would prefer to download directly from a link instead of a dir in order to avoid i get a wrong version. So if you can link them here i think it would be better.

I did so:

Here you go:
* http://www.mediafire.com/file/1zinvyjmzry/x264-r999-gcc432.zip
* http://www.mediafire.com/file/m0ymzojczi2/x264-r999-gcc432-noasm.zip
* http://www.mediafire.com/file/liimtvzy0yi/pthreadGC2.zip

The file names should be self-explaining...

[3ngel]

Do the MinGW/GCC v3.4.6 work any better?

If someone post a build link i can try.

The file names should be self-explaining...

Yes, infact up to now i've tested only yours with asm.

[LoRd_MuldeR]

If someone post a build link i can try.

I just did:
You can find MinGW/GCC v3.4.6 builds on http://www.x264.nl/ for example...

If you need a direct link, here you go:
http://mirror01.x264.nl/x264/revision999/x264.exe

[3ngel]

If you need a direct link, here you go

Yes thanks. Gonna try.

[3ngel]

3.4.6 Broken

http://img219.imageshack.us/img219/230/15390722oy0.th.png (http://img219.imageshack.us/my.php?image=15390722oy0.png)http://img219.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

Up to now

MinGW/GCC v3.4.6-> Broken

MinGW/GCC v4.3.2 tdm-1 (SJLJ Unwinding) -> Broken

[LoRd_MuldeR]

MinGW/GCC v3.4.5 here:
http://forum.doom9.org/showpost.php?p=1191032&postcount=1212

MinGW/GCC v4.3.3 here:
http://komisar.gin.by/x264.999kMod.generic.exe

[kemuri-_9]

3ngel: could you put up a sample of the source for the problematic section?
would help for people to have it so they can do testing on it themselves....

[3ngel]

3.4.5 Broken

Same Frame as 3.4.6 +

http://img221.imageshack.us/img221/3492/345zo4.th.png (http://img221.imageshack.us/my.php?image=345zo4.png)http://img221.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

MinGW/GCC v3.4.5 -> Broken

MinGW/GCC v3.4.6 -> Broken

MinGW/GCC v4.3.2 tdm-1 (SJLJ Unwinding) -> Broken

@kemuri-_9
It seems that the errors (among other sections) can be systematically repeated over small section. If this is confirmed in my next test, i'll post a Lagarith section.

EDIT: Moreover i think you can take any End Credits in any film and i think you'll see the error sooner or later.

4.3.3 Broken

http://img98.imageshack.us/img98/8937/433xe9.th.png (http://img98.imageshack.us/my.php?image=433xe9.png)http://img98.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

MinGW/GCC v3.4.5 -> Broken

MinGW/GCC v3.4.6 -> Broken

MinGW/GCC v4.3.2 tdm-1 (SJLJ Unwinding) -> Broken

MinGW/GCC v4.3.3 -> Broken

Now i try to isolate a small section

[3ngel]

The frame that seems to be systematically repeteable is this

http://img88.imageshack.us/img88/412/frametv7.th.png (http://img88.imageshack.us/my.php?image=frametv7.png)http://img88.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

This is the lags video portion

http://www.megaupload.com/?d=GDGX6WR5

It seems that every gcc version has the error. Can i hazard an asm code error?

EDIT:
And now a ridiculous update to laugh us all

With the CPU i've done all the tests above (Phenom BE) the encode is corrupted. With a 2 cores Athlon the encode is correct.

http://img75.imageshack.us/img75/5694/phenomkk5.th.png (http://img75.imageshack.us/my.php?image=phenomkk5.png)http://img75.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)http://img75.imageshack.us/img75/5179/athloneu7.th.png (http://img75.imageshack.us/my.php?image=athloneu7.png)http://img75.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

Said that i think it's the strangest error i've ever seen.

[kemuri-_9]

that's interesting...
well as i have the same cpu (phenom 9850 BE), technically i should be able to repeat the problem when i get back from work.

[elguaxo]

With a 2 cores Athlon the encode is correct.

I was wondering why I never got the artifacts on the many encodes I did with r998, now I know why! Thanks for the tests.

[Dark Shikari]

A bug that only exists on Phenom--no wonder nobody ever reported it before ;)

[poisondeathray]

I did a quick test with your sample with an Athlon64 single core, and Intel Quad but cannot reproduce the artifacts with r998

[akupenguin]

could someone post a build with --disable-asm?
Did you skip over the testing of a normal build with --no-asm ?

[Dark Shikari]

Did you skip over the testing of a normal build with --no-asm ?Yes, since the bug is most probably in inline assembly, not autoloaded, but that's a good idea--we should test that, too.

[3ngel]

How can it be a bug on one type of processor? Never heard something like this :)

[LoRd_MuldeR]

Maybe that CPU has some undocumented feature (one may say "bug") that only triggers in this particular situation...

[kemuri-_9]

what was the x264 parameters that you used? I was unable to reproduce the error with the x264.nl build nor my own with some simple settings.
might be specific to the parameters and the cpu...

but then again, i'm still at work and doing these tests through RDP, so it may be messing with the visualization.

either way, it would be helpful for me if you could provide the parameters as i seem to be the only one around with a phenom to try reduplicating the error,
which in then turn can help akupenguin and Dark Shikari at solving the issue.

[3ngel]

It's 2 pass

x264.999kMod.genericGCC433.exe --pass 1 --bitrate 3984 --stats ".stats" --progress --keyint 250 --bframes 16 --qpmin 10 --qpmax 51 --aq-mode 0 --psy-rd 0.8:0 --no-psnr --no-ssim --no-fast-pskip --mixed-refs --b-adapt 0 --trellis 2 --ref 9 --no-deblock --subme 7 --direct auto --direct-8x8 -1 --me umh --merange 32 --nf --weightb --b-pyramid --partitions all --8x8dct --threads auto --thread-input --no-dct-decimate --level 41 --output NUL "t.avs"

x264.999kMod.genericGCC433.exe --pass 2 --bitrate 3984 --stats ".stats" --progress --keyint 250 --bframes 16 --qpmin 10 --qpmax 51 --aq-mode 0 --psy-rd 0.8:0 --no-psnr --no-ssim --no-fast-pskip --mixed-refs --b-adapt 0 --trellis 2 --ref 9 --no-deblock --subme 7 --direct auto --direct-8x8 -1 --me umh --merange 32 --nf --weightb --b-pyramid --partitions all --8x8dct --threads auto --thread-input --no-dct-decimate --level 41 --output "2pass.mkv" "t.avs"

This is getting more and more strange

For the moment i'm alone in my trouble :(

Ehehe

[LoRd_MuldeR]

3ngel, is your CPU overclocked? Did you run Prime95 for a few hours, check your RAM with Memtest86+ and so on ???

[3ngel]

No, stock cpu and mem. No overclock.

If it was a mem corrupt problem the --noasm would have the same problem (and the problem could not be reproduced systematically as it is).
Moreover the situation happens only on BW credits streams or white text on black. On color or any other stream not a problem.

[kemuri-_9]

It's 2 pass

x264.999kMod.genericGCC433.exe --pass 1 --bitrate 3984 --stats ".stats" --progress --keyint 250
--bframes 16 --qpmin 10 --qpmax 51 --aq-mode 0 --psy-rd 0.8:0 --no-psnr --no-ssim --no-fast-pskip
--mixed-refs --b-adapt 0 --trellis 2 --ref 9 --no-deblock --subme 7 --direct auto --direct-8x8 -1 --me umh
--merange 32 --nf --weightb --b-pyramid --partitions all --8x8dct --threads auto --thread-input --no-dct-decimate --level 41 --output NUL "t.avs"

x264.999kMod.genericGCC433.exe --pass 2 --bitrate 3984 --stats ".stats" --progress --keyint 250
--bframes 16 --qpmin 10 --qpmax 51 --aq-mode 0 --psy-rd 0.8:0 --no-psnr --no-ssim --no-fast-pskip
--mixed-refs --b-adapt 0 --trellis 2 --ref 9 --no-deblock --subme 7 --direct auto --direct-8x8 -1 --me umh
--merange 32 --nf --weightb --b-pyramid --partitions all --8x8dct --threads auto --thread-input --no-dct-decimate --level 41 --output "2pass.mkv" "t.avs"

This is getting more and more strange

For the moment i'm alone in my trouble :(

Ehehe

confirmed error for those settings!
--asm 0 has no error.

StackVertical comparison:
top is --asm 0
bottom is running asm based on cpu detection.
snap (http://kemuri9.net/forumpics/x264_bug.png)

used the std x264.nl build

[Dark Shikari]

Can you raise --asm progressively (MMX2, SSE2Slow, SSE2, etc, etc) and see which setting is the lowest at which the problem occurs?

Oh, and before you do that, make checkasm and run checkasm. It should fail if there really is a problem.

[3ngel]

confirmed error for those settings!

Phew... :)

Ehehe

[kemuri-_9]

sure i'll do that when i get back to the house, about to leave work now... so be a while
however, i did the same settings except with psy-rd set to 0:0 and couldn't see an error with asm active.

[Dark Shikari]

sure i'll do that when i get back to the house, about to leave work now... so be a while
however, i did the same settings except with psy-rd set to 0:0 and couldn't see an error with asm active.Since the error could be triggered out of mere coincidence, just because it disappears with an option changed doesn't mean that option is at fault.

[kemuri-_9]

indeed, since dropping it back to threads 1 also didn't have an error.

but as for checking increasing asm to pinpoint the error:
MMX2: no error
SSE2Slow: no error
SSE2: error
SSE2Fast: error


$ ./checkasm.exe
x264: using random seed 56950896
x264: MMX
- pixel sad : [OK]
- pixel sad_aligned : [OK]
- pixel ssd : [OK]
- pixel satd : [OK]
- pixel sa8d : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
- pixel var : [OK]
- pixel hadamard_ac : [OK]
- intra satd_x3 : [OK]
- intra sad_x3 : [OK]
- ssim : [OK]
- esa ads: [OK]
- sub_dct4 : [OK]
- sub_dct8 : [OK]
- add_idct4 : [OK]
- add_idct8 : [OK]
- (i)dct4x4dc : [OK]
- zigzag_frame : [OK]
- zigzag_field : [OK]
- mc luma : [OK]
- mc chroma : [OK]
- mc wpredb : [OK]
- hpel filter : [OK]
- lowres init : [OK]
- intra pred : [OK]
- deblock : [OK]
- quant : [OK]
- dequant : [OK]
- denoise dct : [OK]
- cabac : [OK]
x264: MMX Cache64
- pixel sad : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
- mc luma : [OK]
- lowres init : [OK]
x264: MMX Cache32
- pixel sad : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
- mc luma : [OK]
- lowres init : [OK]
x264: SSE2Slow
- pixel sad_aligned : [OK]
- pixel ssd : [OK]
- pixel satd : [OK]
- pixel sa8d : [OK]
- pixel var : [OK]
- ssim : [OK]
- sub_dct4 : [OK]
- sub_dct8 : [OK]
- add_idct4 : [OK]
- add_idct8 : [OK]
- hpel filter : [OK]
- intra pred : [OK]
- deblock : [OK]
- quant : [OK]
- dequant : [OK]
- denoise dct : [OK]
x264: SSE2Fast
- pixel sad : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
- pixel var : [OK]
- pixel hadamard_ac : [OK]
- intra sad_x3 : [OK]
- esa ads: [OK]
- zigzag_frame : [OK]
- mc luma : [OK]
- mc chroma : [OK]
- mc wpredb : [OK]
- hpel filter : [OK]
- lowres init : [OK]
- intra pred : [OK]
x264: SSE2Fast Cache64
- pixel sad : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
- mc luma : [OK]
x264: SSE3
- pixel sad : [OK]
- pixel sad_x3 : [OK]
- pixel sad_x4 : [OK]
x264: All tests passed Yeah :)

[burfadel]

Rev 1000 doesn't (and I'm sure won't be) have to be a bugfix. Any fixes can be released as patches then submitted to GIT once the time comes :)

[kemuri-_9]

was the information i posted above able to help you (Dark Shikari/akupenguin) in finding the error, or do you still need some more data?

[Dark Shikari]

was the information i posted above able to help you (Dark Shikari/akupenguin) in finding the error, or do you still need some more data?Can you confirm that all --asm levels work properly on other CPUs, that is, the issue only occurs on Phenom?

The next thing you can do is go throughout x264 commenting out SSE2 function initializations (find if( cpu&X264_CPU_SSE2 ) lines and change them to if(0) ) until the bug stops occurring.

[kemuri-_9]

this came out when i plugged it on my other two computers with --asm SSE2:
top: athlon64 x2 4200+
bottom: prescott (p4 3GHz w/ HT)
snapshot (http://kemuri9.net/forumpics/x264_bug2.png)
diff frame within the sample, but still a fubar frame
--asm SSE2Slow was fine once again.

would attribute 3ngel not seeing a problem with it on the athlon64, since the default asm usage is SSE2Slow for them (as you well know).

I'll go through commenting out SSE2 function inits in a bit.

[akupenguin]

top: athlon64 x2 4200+
bottom: prescott (p4 3GHz w/ HT)
You could have just said that both cpus showed the same error, rather than pasting two copies of the same image and making me overlay them in GIMP to make sure that they're identical.

[kemuri-_9]

yeah, hadn't thought about that...

so trying what DS said about the asm init disabling:
removing in quant.c - error
removing in pixel.c:
if( (cpu&X264_CPU_SSE2) && !(cpu&X264_CPU_SSE2_IS_SLOW) ) -> if ( 0 ) - error free
if (cpu&X264_CPU_SSE2 ) -> if( 0 ) - error
removing in dct.c - error

by line commenting within the found bracket (via commenting the specified line only):
//INIT2( sad, _sse2 ); - error
//INIT2( sad_x3, _sse2 ); - error
//INIT2( sad_x4, _sse2 ); - error
//INIT4( hadamard_ac, _sse2 ); - error free
//INIT_ADS( _sse2 ); - error
//pixf->var[PIXEL_8x8] = x264_pixel_var_8x8_sse2; - error
//pixf->intra_sad_x3_16x16 = x264_intra_sad_x3_16x16_sse2; - error

Edit:
all the error blocks I've been seeing are focused on the bottom of the frame, near the frame edge...
possibly related to having a 532 pixel (non mod16) height?

[Dark Shikari]

Hadamard_ac... ooooooooooh, it is a bug in psy-RD, but in the assembly, not the C code or the algorithm!

I'm going to guess there was some sort of overflow, considering the fact that it only happens on a black/white area like that.

[3ngel]

but in the assembly, not the C code

I would guessed it. Remember to me the ol' amiga days when strange things happened in hardcored asm code :)

@kemuri-_9
If you look at the "Jiikine" word, it probably happens in the middle of the screen. I found it happens almost anytime.

Good BTW.

[Dark Shikari]

Here's Akupenguin's fix (http://akuvian.org/src/x264/hadamard_ac.diff).

It seems to fix the problem; it avoids possibility of overflow as far as I can tell.

If no issues are reported, I'll commit it locally (yes, yes, r1k is coming soon!).

[LoRd_MuldeR]

Here's Akupenguin's fix (http://akuvian.org/src/x264/hadamard_ac.diff).

It seems to fix the problem; it avoids possibility of overflow as far as I can tell.

If no issues are reported, I'll commit it locally (yes, yes, r1k is coming soon!).

x264 r999 + hadamard_ac.diff
http://www.mediafire.com/file/myqnqimddg0/x264-r999-gcc432-hadamard_ac.zip

MinGW/GCC 4.3.2-tdm-1, yasm 0.7.1.2093, march=pentium2, no fprofiled

[kemuri-_9]

Here's Akupenguin's fix (http://akuvian.org/src/x264/hadamard_ac.diff).

It seems to fix the problem; it avoids possibility of overflow as far as I can tell.

If no issues are reported, I'll commit it locally (yes, yes, r1k is coming soon!).

i ran the patch on my own build and didn't see any fubar blocks in the sample,
so it appears to have done the trick.

[3ngel]

Confirmed. Encode clean with no problem.

Good work.

Out of curiosity, there is something that could be done to furtherly improve the performance on Phenom?

Moreover, there can be add a customizable option to buffer ahead frames? It something happens to me to do encodes over RDP, taking frames from remote location, and the read over the net lose 3-4 fps. So with a buffer ahead the x264.exe would have the same performance as locally.

[lexor]

zomg, the pipeline changes just went live into git! (well not nahelem and interlace ones, obviously) I'm getting giddy just thinking about trying the new toys.

We need a build pronto!

[Disabled]

We need a build pronto!
x264.nl has one...
Congratulations on the 1000+th revision.

[LoRd_MuldeR]

x264.nl has one...
Congratulations on the 1000+th revision.

So when is the revision 1000 party at pengvado's villa going to start? :D

[Avenger007]

So when is the revision 1000 party at pengvado's villa going to start? :D
Thu Oct 16 03:17:53 2008 :p

[LoRd_MuldeR]

x264 r1016
http://www.mediafire.com/file/dkn5mzndyyi/x264-r1016-gcc432-fprofiled.7z

MinGW/GCC 4.3.2-tdm-1, yasm 0.7.1.2093, march=pentium2, fprofiled

[microchip8]

So when is the revision 1000 party at pengvado's villa going to start? :D

it has already began on IRC, the cake is delicious :p

[pcordes]

Moreover, there can be add a customizable option to buffer ahead frames?

A separate program can implement the buffer. There are several buffered-pipe programs around, such as bfr. This works well on Linux, and helps even when feeding x264 from a local but bursty source, e.g. mplayer -vo yuv4mpeg:file=pipe.y4m. See my post here:
http://forum.doom9.org/showthread.php?p=1206916#post1206916

[Shinigami-Sama]

it has already began on IRC, the cake is delicious :p

the cake is a lie...



its actually a pie

[Adub]

Excellent! I can't wait to back up my tv series in even more quality now!

[kemuri-_9]

thanks for all the revisions devs, they were delicious.

[LoRd_MuldeR]

it has already began on IRC, the cake is delicious :p

I'll open a bottle of beer now to celebrate the occasion http://forum.gleitz.info/images/smilies/cheers.gif

[skystrife]

Broken, because I'm a retard.

[XhmikosR]

@skystrife: I'm getting an error with your build that pthreadGC2.dll was not found.

http://img376.imageshack.us/img376/9500/01112008143613hz6.png (http://imageshack.us)

techhouse's x264 x86 r1016 (http://techouse.project357.com/builds/x264_x86_r1016_techouse.7z) is working fine.

[roozhou]

@skystrife: I'm getting an error with your build that pthreadGC2.dll was not found.



Seems skystrife's build dynamically links to pthread library. He needs a patch to build a static-linked x264.

[skystrife]

Oh, well fuck. I did something stupid with my msys environment and forgot to set it back to normal. Fixed build coming soon.

Fixed: http://skystrife.com/x264/x264.1016.modified.02.exe

[3ngel]

A separate program can implement the buffer. There are several buffered-pipe programs around, such as bfr. This works well on Linux, and helps even when feeding x264 from a local but bursty source, e.g. mplayer -vo yuv4mpeg:file=pipe.y4m. See my post here:
http://forum.doom9.org/showthread.php?p=1206916#post1206916

Yes, i see thanks, but i'm running under windows.

I think an option like --FrameBuffer NumFrames, would not so hard to develop, and it would simplify things even in your case :)
I hope this suggestion will be considered sometime.
Thanks.

[MasterNobody]

Here is my patch collection for x264 (for revision 1019), most of which I use in my builds of x264vfw: http://stashbox.org/288851/bm_x264_patch_collection.r1019.zip.

Description of included patches:
'independent' dir:
x264_cosmetic.r1019.diff - cosmetic fix for warning "C4028: formal parameter 2 different from declaration" when compiling with VS2008.
x264_cost_mv_memoryleaks.r1019.diff - fixes memoryleaks of mvs cost arrays (not very important for x264 CLI, but useful when using x264 as shared library).
x264_custom_strtok_r.r1019.diff - fixes incorrect zones parsing at Windows (due the use of non reentrant version of strtok_r). For example, with command line "x264.exe --crf 26 --zones 0,10,asm=MMX2,psy-rd=1:1/11,50,psy-rd=0:0 -o test.mkv foreman_cif_352x288.yuv".
x264_debug_defines.r1019.diff - add defines '_DEBUG' / 'NDEBUG' when compile with gcc (using 'configure').
x264_error_memoryleaks.03.r1019.diff - fixes different memoryleaks when error happens durring 'x264_encoder_open', 'x264_ratecontrol_new', 'parse_zone', 'parse_zones'. Also fix incorrect memory allocation 'z->param' in 'parse_zone' (allocated with 'malloc' but frees with 'x264_free').
x264_fix_crash_cqp_and_vbv.r1019.diff - fixes crash with command line "x264.exe --qp 26 --vbv-maxrate 20000 --vbv-bufsize 25000 -o test.mkv foreman_cif_352x288.yuv".
x264_fix_stats_file_work.r1019.diff - add some workarounds for work with stats file (not very important for x264 CLI, but useful for applications which use x264 as library and expects "one in - one out" behaviour, for example x264vfw).
x264_multithreading_bug_check.r1019.diff - enables one bug check for multithreading for release builds which originally used only for debug builds.
x264_thread_pool.r1019.diff - adds thread-pool feature (slighly improves multithreading).
x264_vaqmod.05.r1019.diff - some modifications of VAQ (adds support for command line options '--aq-metric' and '--aq-sensitivity').

'misc' dir:
x264_disable_hadamard_ac_on_mod4_stack.r1019.diff - disables 'hadamard_ac' SSE2/SSSE3 optimizations when compiled with VS due the crash (general-protection exception) (fixed version of http://mailman.videolan.org/pipermail/x264-devel/2008-October/005069.html).
x264_vs_project.r1019.diff - removes 'eval.c' from VS project files (http://mailman.videolan.org/pipermail/x264-devel/2008-October/005050.html).
x264_x64_compilation.r1019.diff - fixes error "LNK2001: unresolved external symbol x264_pixel_avg2_w20_cache64_mmxext" when compiling for x64 platform (at least in VS).
'vs2008' dir - project files for VS2008 (not only update of current project files).

'batch' dir - same patches as in 'independent', but keeps in mind possible conflicts in applying.

[Dark Shikari]

x264_cost_mv_memoryleaks.r1019.diff - fixes memoryleaks of mvs cost arrays (not very important for x264 CLI, but useful when using x264 as shared library).How is this a memory leak? These arrays will be initialized only once, no matter how many times you instance x264 as a shared library, and will be shared between all running processes.

Your change, as far as I can tell, actually breaks things because if you instanced x264 twice using the same library and one of the encodes finished before the other, it would proceed to free all the arrays used by the second instance, instantly crashing the other encode. In other words, with this patch, it becomes impossible to make multiple simultaneous encoder_encode calls from a single application.

Patch tentatively rejected.x264_debug_defines.r1019.diff - add defines '_DEBUG' / 'NDEBUG' when compile with gcc (using 'configure').Patch rejected, a significant bit of crash-avoidance code is under NDEBUG, and this patch disables it, risking crashes during encoding. I see you have another patch which makes this not dependent on NDEBUG; does that even leave NDEBUG used anywhere else in the entire program? I'd rather just remove NDEBUG completely.
x264_cosmetic.r1019.diff - cosmetic fix for warning "C4028: formal parameter 2 different from declaration" when compiling with VS2008.
x264_fix_crash_cqp_and_vbv.r1019.diff - fixes crash with command line "x264.exe --qp 26 --vbv-maxrate 20000 --vbv-bufsize 25000 -o test.mkv foreman_cif_352x288.yuv".
x264_disable_hadamard_ac_on_mod4_stack.r1019.diff - disables 'hadamard_ac' SSE2/SSSE3 optimizations when compiled with VS due the crash (general-protection exception) (fixed version of http://mailman.videolan.org/pipermail/x264-devel/2008-October/005069.html).
x264_vs_project.r1019.diff - removes 'eval.c' from VS project files (http://mailman.videolan.org/pipermail/x264-devel/2008-October/005050.html).Patches approved.
x264_x64_compilation.r1019.diff - fixes error "LNK2001: unresolved external symbol x264_pixel_avg2_w20_cache64_mmxext" when compiling for x64 platform (at least in VS).Patch rejected; the bug is in mc-c.c, not in the assembly file:

#ifdef ARCH_X86
PIXEL_AVG_WTAB(cache32_mmxext, mmxext, cache32_mmxext, cache32_mmxext, cache32_mmxext, cache32_mmxext)
#endif
PIXEL_AVG_WTAB(cache64_mmxext, mmxext, cache64_mmxext, cache64_mmxext, cache64_mmxext, cache64_mmxext)
should be
#ifdef ARCH_X86
PIXEL_AVG_WTAB(cache32_mmxext, mmxext, cache32_mmxext, cache32_mmxext, cache32_mmxext, cache32_mmxext)
PIXEL_AVG_WTAB(cache64_mmxext, mmxext, cache64_mmxext, cache64_mmxext, cache64_mmxext, cache64_mmxext)
#endif
x264_custom_strtok_r.r1019.diff - fixes incorrect zones parsing at Windows (due the use of non reentrant version of strtok_r). For example, with command line "x264.exe --crf 26 --zones 0,10,asm=MMX2,psy-rd=1:1/11,50,psy-rd=0:0 -o test.mkv foreman_cif_352x288.yuv".Tentatively rejected until you explain exactly what the problem is. "incorrect" does not tell me anything.
x264_error_memoryleaks.03.r1019.diff - fixes different memoryleaks when error happens durring 'x264_encoder_open', 'x264_ratecontrol_new', 'parse_zone', 'parse_zones'. Also fix incorrect memory allocation 'z->param' in 'parse_zone' (allocated with 'malloc' but frees with 'x264_free').Tentatively approved, pengvado will need to look at this one.
x264_fix_stats_file_work.r1019.diff - add some workarounds for work with stats file (not very important for x264 CLI, but useful for applications which use x264 as library and expects "one in - one out" behaviour, for example x264vfw).Patch rejected. x264's API is explicitly not one-in-one-out. VFW workarounds will never ever be accepted into the main tree for any reason.
compiling for x64 platformYou got x264 working on x64 Windows? Can you post the assembly calling convention patch you used?

[akupenguin]

These arrays will be initialized only once, no matter how many times you instance x264 as a shared library, and will be shared between all running processes.
Shared between all invocations of x264 within one process (which is sufficient to make it not a leak). Shared between processes only if they forked after initializing x264. Further sharing would violate virtual memory protections. Unfortunately there's no way to allow sharing between multiple processes without writing the entire contents of the array literally in the executable (and it requires some contortions in the source code too).

+#undef strtok_r //pthread.h can already define own variant (non reentrant version)
What is a non reentrant version of strtok_r? The sole difference between strtok and strtok_r is that strtok_r is reentrant and strtok isn't.

[MasterNobody]

How is this a memory leak? These arrays will be initialized only once, no matter how many times you instance x264 as a shared library, and will be shared between all running processes.

Your change, as far as I can tell, actually breaks things because if you instanced x264 twice using the same library and one of the encodes finished before the other, it would proceed to free all the arrays used by the second instance, instantly crashing the other encode. In other words, with this patch, it becomes impossible to make multiple simultaneous encoder_encode calls from a single application.
May be you right.
Patch rejected, a significant bit of crash-avoidance code is under NDEBUG, and this patch disables it, risking crashes during encoding. I see you have another patch which makes this not dependent on NDEBUG; does that even leave NDEBUG used anywhere else in the entire program? I'd rather just remove NDEBUG completely.
The main idea of defining NDEBUG is to disable assert checks in release builds (to get little more speed).
Patch rejected; the bug is in mc-c.c, not in the assembly file:
#ifdef ARCH_X86
PIXEL_AVG_WTAB(cache32_mmxext, mmxext, cache32_mmxext, cache32_mmxext, cache32_mmxext, cache32_mmxext)
#endif
PIXEL_AVG_WTAB(cache64_mmxext, mmxext, cache64_mmxext, cache64_mmxext, cache64_mmxext, cache64_mmxext)
should be
#ifdef ARCH_X86
PIXEL_AVG_WTAB(cache32_mmxext, mmxext, cache32_mmxext, cache32_mmxext, cache32_mmxext, cache32_mmxext)
PIXEL_AVG_WTAB(cache64_mmxext, mmxext, cache64_mmxext, cache64_mmxext, cache64_mmxext, cache64_mmxext)
#endif
But that is exactly what I change in my patch (it doesn't change any assembly file).
Tentatively rejected until you explain exactly what the problem is. "incorrect" does not tell me anything.
"incorrect" means that you will get "x264 [error]: failed to parse zones" for command line: "x264.exe --crf 26 --zones 0,10,asm=MMX2,psy-rd=1:1/11,50,psy-rd=0:0 -o test.mkv foreman_cif_352x288.yuv"
Patch rejected. x264's API is explicitly not one-in-one-out. VFW workarounds will never ever be accepted into the main tree for any reason.
That was expected.
You got x264 working on x64 Windows? Can you post the assembly calling convention patch you used?
No. x264_x64_compilation.r1019.diff and vs2008 project files was the first step before hacking assembly files (with no luck).
What is a non reentrant version of strtok_r? The sole difference between strtok and strtok_r is that strtok_r is reentrant and strtok isn't.
I mean this from pthread.h:
#if !defined(__MINGW32__)
#define strtok_r( _s, _sep, _lasts ) \
( *(_lasts) = strtok( (_s), (_sep) ) )
#endif /* !__MINGW32__ */

[Dark Shikari]

The main idea of defining NDEBUG is to disable assert checks in release builds (to get little more speed).There are no asserts in speed-significant portions of the code. Those in non-speed-significant sections allow us to catch bugs in release builds.But that is exactly what I change in my patch (it doesn't change any assembly file).Oops, I apparently fail at reading. In that case, approved."incorrect" means that you will get "x264 [error]: failed to parse zones" for command line: "x264.exe --crf 26 --zones 0,10,asm=MMX2,psy-rd=1:1/11,50,psy-rd=0:0 -o test.mkv foreman_cif_352x288.yuv"Well that's obvious; asm isn't supposed to be an option allowed in zones.

[MasterNobody]

Well that's obvious; asm isn't supposed to be an option allowed in zones.
It fails not because of 'asm' option (I use it only to show the worst variant for zones). It will fail even without 'asm' (with command line: "x264.exe --crf 26 --zones 0,10,psy-rd=1:1/11,50,psy-rd=0:0 -o test.mkv foreman_cif_352x288.yuv"). The course of the fail is nested use of 'strtok' (because in Windows there is no 'strtok_r') in 'parse_zones'->'parse_zone'->'x264_param_parse' (in worst case of using 'asm' option) which is non reentrant and after second call with not NULL first param in 'parse_zone' will return incorrect results in 'parse_zones' (will return NULL for second zone).

[skystrife]

2^10 GET!

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

Patches used:

x264_hrd_pulldown.09_interlace.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[kemuri-_9]

no fixing of the broken windows zone parser/strtok_r?

[bob0r]

[03:12] (pengvado): to fix the problem on windows, you would have to implement strtok_r in windows's libc
[03:12] (pengvado): anything else is a kludge, not a fix
[03:22] (pengvado): it's worse than nothing because it offends my aesthetics

[ACrowley]

Question : I follow the Level 4.1 HP Compliance Restriction for my x264 DXVA Compliant encodes

I always follow these Rules from Refernce Frames/resolution

|-----------|---------|
|Resolution | no. ref |
|-----------|---------|
| 1280x544 | 12 |
| 1280x720 | 9 |
| 1920x800 | 5 |
| 1920x816 | 5 |
| 1920x1080 | 4 |

Where there Changes last Time ? I do my encodes with megui Profil which is identical to Sharktooth DXVA HD HQ Profile,% 5 Ref Frames/1920x800/3 B frames/Level 4.1 HP and without B Pyramid, always with latest x264 Build from techhouse
DXVA works perfect with Cyberlink,Nero oder MPC HC Decoder.

But now i noticed that aencode with newest x264 Build in 1280x544 with 12 Ref Frames doesnt work with DXVA anymore ? Encodes with 12 Ref Frames on 1280x544 was fine in the Past so far i can remenber.
But now it only works with 9 Ref Frames ?
--pass 2 --bitrate 5150 --stats "E:\mo.stats" --level 4.1 --ref 9 --mixed-refs --bframes 3 --b-adapt 2 --weightb --direct auto --deblock -2:-2 --subme 8 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 40000 --vbv-maxrate 50000 --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "E:\mohikaner.mp4" "E:\m.avs"

1280x544 ,9 Ref Frames works fine with DXVA. The same with 12 Ref Frames not.

So, are there new Level 4.1 HP -Ref Frames Compliance Rules ?

[MasterNobody]

And what about:
x264_error_memoryleaks.03.r1019.diff - fixes different memoryleaks when error happens durring 'x264_encoder_open', 'x264_ratecontrol_new', 'parse_zone', 'parse_zones'. Also fix incorrect memory allocation 'z->param' in 'parse_zone' (allocated with 'malloc' but frees with 'x264_free').

Is it also rejected? If it is rejected than I want to know why (may be I can fix things that akupenguin/pengvado doesn't like in it).

[kemuri-_9]

that was addressed by both Dark Shikari and Akupenguin after you originally posted the patches.

well thanks for the info at least on the strtok_r not going to be fixed, so i just made my own patch for ratecontrol.c to get it to work on winblows.

[Sagekilla]

@ACrowley: DPB for Level 4.1 must be width * height * refs * 1.5 bytes <= 12441600 bytes so doing simple math you can get max refs:

1920x1080 = 4 refs
1920x816 = 5 refs (round down from 5.29)
1920x800 = 5 refs (round from 5.4)
1280x720 = 9 refs
1280x544 = 11 refs (round from 11.91)

never round up when doing those calculations. Whoever calculated that table did it wrong.

[Betsy25]

@ACrowley: DPB for Level 4.1 must be width * height * refs * 1.5 bytes <= 12441600 bytes so doing simple math you can get max refs:

1920x1080 = 4 refs
1920x816 = 5 refs (round down from 5.29)
1920x800 = 5 refs (round from 5.4)
1280x720 = 9 refs
1280x544 = 11 refs (round from 11.91)

never round up when doing those calculations. Whoever calculated that table did it wrong.

Hi,

Does the reference frames calculation also hold truth when using the Unrestricted level, and for lower resolutions ?

[Sagekilla]

That's the DPB for level 4.1. If you want to get L4.1 compatibility you must use a max DPB value of 12441600 bytes. Unrestricted means you're not conforming to levels or profiles, so DPB doesn't apply.

TBH, you only need to worry about DPB if you're encoding for compatibility. In this case, Level 4.1 is required for hardware acceleration and PS3 requires 4.1 for playback too.


tl;dr: DPB doesn't matter for unrestricted.

[Ranguvar]

that was addressed by both Dark Shikari and Akupenguin after you originally posted the patches.

well thanks for the info at least on the strtok_r not going to be fixed, so i just made my own patch for ratecontrol.c to get it to work on winblows.

Post please? I use Linux, but I'd still like to see it.

[Snowknight26]

Don't forget to round the height and width up to the 16 when calculating the # of reference frames.

[Comatose]

I'm also interested.

[video_magic]

Just saying thanks to everybody who has contributed their skills and time to x264, I've been amazed at the results I've been getting, including thankyou to MasterNobody - really appreciated here everybody.

[kemuri-_9]

Post please? I use Linux, but I'd still like to see it.

strtok_r is only used in three places, once in the param parser and twice in zone parsing.
because zone parser has two calls to strtok, using a non reentrant strtok causes the break.

(wtg winblows for not having strtok_r, causing the whole situation)
(if you could change asm in zones, then it would be a triple call - as that's where it's used in the param parser)
(^ this situation would really need a reentrant strtok)

so as such there's two ways of solving the current situation:
1. alter the zone parser to use only one call to strtok so a non reentrant strtok can be used. (as the one posted below does)
2. properly implement strtok_r. (as MasterNobody's patch does)

if a truly reentrant strtok_r was required in more locations, option #2 would be the choice to take.
But as there's only one spot, we can get away with doing #1, which has less code to get added.

So it's pretty much up to the person which fix they would want for this situation.
here's the patch for fix method #1:
x264_win_zone_parse_fix_r1024.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_r1024.diff)

[akupenguin]

While Microsoft isn't likely to care, you might be able to get a strtok_r implementation into mingw, and that would help more than just x264.

I might consider the patch that adds only 4 lines. But I seriously have a policy of not working around other people's bugs, no matter how easy it would be.

[Sharktooth]

more than a bug, that is a lack of implementation.

[Dark Shikari]

While Microsoft isn't likely to care, you might be able to get a strtok_r implementation into mingw, and that would help more than just x264.

I might consider the patch that adds only 4 lines. But I seriously have a policy of not working around other people's bugs, no matter how easy it would be.O rly? (http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=16b8f79bb6825053b6dd0eebb1d24c1bdf112fbb) ;)

[akupenguin]

You're right, I'm not being consistent. I'll go remove that kludge too.

[Dark Shikari]

You're right, I'm not being consistent. I'll go remove that kludge too.Already gone, when we added pixel.var().

[MasterNobody]

Here is updated my patch collection for x264 (for revision 1024): http://stashbox.org/290274/bm_x264_patch_collection.r1024.zip
Besides updating of some patches and removing of commited I also add new patch:
x264_inv_qscale_factor_memoryleak.r1024.diff - to fix new memoryleak after http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=7cdaf638c3777f2b38fb60181dde7ed4de614cc1

[Dark Shikari]

Here is updated my patch collection for x264 (for revision 1024): http://stashbox.org/290274/bm_x264_patch_collection.r1024.zip
Besides updating of some patches and removing of commited I also add new patch:
x264_inv_qscale_factor_memoryleak.r1024.diff - to fix new memoryleak after http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=7cdaf638c3777f2b38fb60181dde7ed4de614cc1Oops, seems I forgot to free that one as well... I'm getting into a rather bad habit of this.

I'll commit it along with the next batch of fixes.

[Audionut]

Revision 1026

x264-r1026.rar (http://rapidshare.com/files/162602312/x264-r1026.rar)

To many changes since my last build.

[kemuri-_9]

are there any other known kludges that aren't planned to be fixed us windoze users should be aware of?

[Snowknight26]

x264-r1026.rar (http://rapidshare.com/files/162602312/x264-r1026.rar)

Would be nice if you either included pthreadGC2.dll in the rar or compiled x264 with it.

[Audionut]

Hmm. I've broken something.

[Snowknight26]

Still occurs.

[Snowknight26]

Nope, still requires pthreadGC2.dll.

[Audionut]

Final fixed working version.
Thanks Snowknight26.

x264-r1026b.rar (http://rapidshare.com/files/162654279/x264-r1026b.rar)

[ACrowley]

@ACrowley: DPB for Level 4.1 must be width * height * refs * 1.5 bytes <= 12441600 bytes so doing simple math you can get max refs:

1920x1080 = 4 refs
1920x816 = 5 refs (round down from 5.29)
1920x800 = 5 refs (round from 5.4)
1280x720 = 9 refs
1280x544 = 11 refs (round from 11.91)

never round up when doing those calculations. Whoever calculated that table did it wrong.


THX :)
Works fine now with 11 Ref Frames.

[azulazules]

@Sagekilla
Confused... Even though some DXVA enabled player cannot decode more than 11 refs (whatever the resolution the video is), isn't it 12MB (=12582912 Bytes) the DBP for h264 High@4.1?

Then High@4.1 for 1280x544 limit is 12 ref = integer(12MB*1024²/(1280px*544px*1.5Bytes)), or is it not ?

[Atak_Snajpera]

Then High@4.1 for 1280x544 limit is 12 ref = integer(12MB*1024²/(1280px*544px*1.5Bytes)), or is it not ?
Read carefully!

1280x544 = 11 refs (round from 11.91)

never round up when doing those calculations. Whoever calculated that table did it wrong.

[Sagekilla]

I don't have the spec on hand, but I don't think the DPB for High@4.1 isn't 12 MB even, but ~11.86 MB (12441600).

[kemuri-_9]

Spec says that the MaxDPB for Levels 4.0 & 4.1 is 12880 KB;
12880 KB / 1024 (KB/MB) ~ 12.57 MB

it's listed in Table A-1, which is on page 283, (305 in the PDF (http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.264-200711-I!!PDF-E&type=items))

[azulazules]

:cool: thanks Kemuri for your answer and the document.

Then max REF for 1280x544 at High@4.1 is really 12.
BTW: 12MB is 12288kB. :-)

[kemuri-_9]

yeah, the calculator failed me on that one :rolleyes:

[ACrowley]

Is there anything new about B-Pyramid ?
I mean Sharktooth has disabled B-Pyramid in his DXVA megui Profiles...

I encode DXVA Compliant....i always used B-Pramid in my encodes ,and i never had any Playback Problmes with mpc-hc or Cyberlink Decoder etc.

Is it safe to use B pyramid in DXVA Compliant encodes or not ?

[juGGaKNot]

Is it safe to use B pyramid in DXVA Compliant encodes or not ?

I also need this answer.

[LoRd_MuldeR]

Is it safe to use B pyramid in DXVA Compliant encodes or not ?I also need this answer.
As long as you calculate the number of ref frames accordingly, it should be safe to use b-pyramid.

[azulazules]

As long as you calculate the number of ref frames accordingly, it should be safe to use b-pyramid.

If I am right, then b-pyramid could make x264 produce video stream that could break DXVA.

The information that I read is that b-pyramid does break the DPB limits depending on the source video.
http://forum.doom9.org/showthread.php?t=140223

If #ref is set to X [--ref X] and b-pyramid is set, then x264 can actually produce X+Y refs video streams thus breaking DPB limit (which is 12MB for High@4.1).

[LoRd_MuldeR]

If I am right, then b-pyramid could make x264 produce video stream that could break DXVA.

The information that I read is that b-pyramid does break the DPB limits depending on the source video.
http://forum.doom9.org/showthread.php?t=140223

If #ref is set to X [--ref X] and b-pyramid is set, then x264 can actually produce X+Y refs video streams thus breaking DPB limit (which is 12MB for High@4.1).

That's why you have to take b-pyramid into account when you calculate the number of ref frames, right?

See this thread, for example:
http://forum.doom9.org/showthread.php?t=142758

(And no, as far as I understand, x264 requires the decoder to cache X+1 refs with "--ref X" and "--b-pyramid" set)

[skystrife]

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

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_r1024.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[ACrowley]

As long as you calculate the number of ref frames accordingly, it should be safe to use b-pyramid.


Casn you give me an example ?

i encode to 1920x800. So i use Level 4.1 HP with 5 Reframes

1920x800 / 816 = 5 Ref Frames
1920x1080 = 4 Refframes
1280x720 = 9
1280x544 =11

So, how do i have to claulate the Ref Frames accroding to these Rules ?

[Disabled]

Casn you give me an example ?

i encode to 1920x800. So i use Level 4.1 HP with 5 Reframes

1920x800 / 816 = 5 Ref Frames
1920x1080 = 4 Refframes
1280x720 = 9
1280x544 =11

So, how do i have to claulate the Ref Frames accroding to these Rules ?
x264 requires the decoder to cache X+1 refs
Thus you have to use one ref frame less: 4 with 1920x800, 3 with 1080p, 8 with 720p and 10 with 1280x544

[shon3i]

B-pyramid is not completly safe even with lowering reference frames. There is small chances to keep stream on standard with b-pyramid but that is gambling.

[Audionut]

x264-r1028.rar (http://rapidshare.com/files/163652679/x264-r1028.rar)

-Add subme=0 (fullpel motion estimation only)
Only for experimental purposes and ultra-fast encoding. Probably not a good idea for firstpass.

-Nehalem optimization part 2: SSE2 width-8 SAD
Helps a bit on Phenom as well
~25% faster width8 multiSAD on Nehalem

[azulazules]

If you use x264, there is a formula I like posted by Selur on:
http://forum.doom9.org/showpost.php?p=1212843&postcount=14

Even with it, it seems it is still possible the h264 stream is not 100% compliant, thus breaking hardware decodes.

In your case, I guess you can go with the following:1920x1088 High@4.1 NO bframe NO b-pyramid ==> max #ref= 4, min #ref=0
1920x1088 High@4.1 bframe(s) allowed NO b-pyramid ==> max #ref= 4, min #ref=2
1920x1088 High@4.1 bframe(s) allowed b-pyramid allowed ==> max #ref= 3, min #ref=3
1920x800 High@4.1 NO bframe NO b-pyramid ==> max #ref= 5, min #ref=0
1920x800 High@4.1 bframe(s) allowed NO b-pyramid ==> max #ref= 5, min #ref=2
1920x800 High@4.1 bframe(s) allowed b-pyramid allowed ==> max #ref= 4, min #ref=3
1280x720 High@4.1 NO bframe NO b-pyramid ==> max #ref= 9, min #ref=0
1280x720 High@4.1 bframe(s) allowed NO b-pyramid ==> max #ref= 9, min #ref=2
1280x720 High@4.1 bframe(s) allowed b-pyramid allowed ==> max #ref= 8, min #ref=3
1280x544 High@4.1 NO bframe NO b-pyramid ==> max #ref=12, min #ref=0
1280x544 High@4.1 bframe(s) allowed NO b-pyramid ==> max #ref=12, min #ref=2
1280x544 High@4.1 bframe(s) allowed b-pyramid allowed ==> max #ref=11, min #ref=3Now, another question could be: is it usually better to use one more REF and not b-pyramid? :p

BTW, aren't we OT here?

[Dark Shikari]

BTW, aren't we OT here?Indeed.

[kemuri-_9]

thanks to Emp3r0r's help, a bug in the win zone parse patch i made was discovered
(which incidentally only seemed to have affected Vista, as it worked fine on my XP)

here's the fixed patch
x264_win_zone_parse_fix_02.diff (http://kemuri9.net/dev/x264/patches/x264_win_zone_parse_fix_02.diff)

[Blue_MiSfit]

What exactly does this zone parse patch do??

~MiSfit

[LoRd_MuldeR]

What exactly does this zone parse patch do??

~MiSfit

Think it refers to this problem:
http://forum.doom9.org/showpost.php?p=1211426&postcount=1307

[kemuri-_9]

yes
it's one of the available solutions to the --zones parameter on windows

having only 1 zone works fine all ready,
but specifying multiple zones fails and has x264 error+quit without either of the fixes.
only on windows that is... <_<

[wata]

skystrife x264.1028.modified.exe failed when using multi-zones, have to go back to r1024

--[Information] [11/16/2008 3:45:56 PM] Encoding started
--[Error] An error occurred: x264 [error]: invalid zone param: d = (null)
--[Error] An error occurred: x264 [error]: failed to parse zones
--[Error] An error occurred: x264 [error]: x264_encoder_open failed

[skystrife]

x264.1028.modified.02.exe (http://www.mediafire.com/?1tzzmzmtnyz) - Alternate Download (http://skystrife.com/x264/x264.1028.modified.02.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_custom_strtok_r.r1024.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

(kemuri's patch doesn't appear to work on my machine where as MasterNobody's patch does, so I'll use it for now).

[kemuri-_9]

(kemuri's patch doesn't appear to work on my machine where as MasterNobody's patch does, so I'll use it for now).

the updated one doesn't?

[skystrife]

Nope, for some reason it would just crash (without any error messages) using either the old or the new patch. *shrug*

Maybe something in my mingw environment is screwing the patch somehow, but there weren't any strange warnings or anything when I patched.

[Audionut]

No problems here. :confused:

Revision 1028 (http://rapidshare.com/files/164874957/x264-r1028-patched.rar)

Patched with x264_win_zone_parse_fix_02.diff

[G_M_C]

No problems with techouse's builds either, and he mentiones no applied patches (asside from the NAL-HRD-patch).

[skystrife]

I'll try again with the next revision's build.

EDIT: I tried again with a clean build (make clean, git checkout -f, patch -p1 <x264_win_zone_parse_fix_02.diff, ./configure --extra-cflags="-march=pentium2", make) and it crashes with this command line: x264 --crf 26 --zones 0,10,psy-rd=1:1/11,50,psy-rd=0:0 -o test.mkv LosslessTouhou.avs

Could it have something to do with gcc 3 vs gcc 4?

EDIT(2): No, just tested with gcc 4 on here to no avail... odd.

[skystrife]

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

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_custom_strtok_r.r1024.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[video_magic]

Hello, Skystrife - please could you tell me whether your build that you have in the post above is fast for someone with a normal P4 HT, I don't know much about this sort of thing, sorry :thanks:

I just would like to encode a little faster if possible than maybe using the otherwise great builds which I have sometimes used from x264.nl . Any encoding speed increase is welcome because I have many hours of tapes that I am capturing and then backing up.
I'm using XP SP2.
My CPU details are here:

http://processorfinder.intel.com/details.aspx?sSpec=SL9KF

[Shinigami-Sama]

CPU specific builds are moot with x264 does its own runtime CPU detection for its ASM code
so...

[akupenguin]

CPU specific builds are moot with x264 does its own runtime CPU detection for its ASM code
That's true for any CPU other than P4. But P4 is so perverse that you do need to compile specially for it.

[Dark Shikari]

That's true for any CPU other than P4. But P4 is so perverse that you do need to compile specially for it.By that logic, its so perverse that we'd need to write custom asm for it (due to the 6-clocks-to-move-between-registers issue).

Not like I care enough about the P4 to do that.

[akupenguin]

It's so perverse that we don't care enough to write custom asm for it. But if you can get some of that speedup just from gcc -march, that's easy. Now, if what you're saying is that we don't care enough to publish P4 builds, so you'll only get one if you compile it yourself, then I agree.

[Audionut]

x264-r1029.rar (http://rapidshare.com/files/165918146/x264-r1029.rar)

Patched with,
x264_hrd_pulldown.09_interlace
x264_win_zone_parse_fix_02

All my builds are built with gcc 3.4.5 fprofiled. March=prescott

[techouse]

EDIT(2): No, just tested with gcc 4 on here to no avail... odd.
So does x264_win_zone_parse_fix_02 break x264 when compiled with GCC4 or not?

[Audionut]

skystrife is having problems with the zone patch with both gcc 3 and 4.

I have no problems with gcc 3.4.5. But i've got a clean build of xp and mingw + gcc running in a virtual machine.

If that makes any difference.

[video_magic]

Being a P4-pervert I will try this build from Audionut and thanks to You guys :)

I did have a P4 prescott before I got the 775 Cedar Mill stepping D0 (65 Watts to run cooler) so I hope that build will be 'close enough'.

Big thanks again everyone for helping me.

[skystrife]

I'm running Vista x64 natively with mingw. It's odd to me that patched or unpatched unexpectedly crashes without giving me any error messages when using zones (I never get the "failed to parse zones" error, it just stops working entirely). Maybe it's a Vista specific thing?

Just a reminder to those using my build: the zones patch I am using worked with that build, so there's nothing for you to worry about. It's just me trying to figure out why the alternative patch (much smaller) isn't working on my end.

[kemuri-_9]

you don't seem to be the only one with problems with running x264 on vista x64...
as this thread (http://forum.doom9.org/showthread.php?t=142925) seems to be leaning towards unexplainable vista x64 failure as well.

i'm on XP x64 myself (and satisfied)

[skystrife]

Testing using Audionut's build to rule out my mingw environment atm.

...and a crash. Issue must be specific to Vista (and maybe x64). I will continue to use MasterNobody's patch for now.

Wonder why Vista chokes on that bit of code?

[Audionut]

Running Vista 64 here.

No Problems.

edit. I tested my build with the command line you posted earlier.

x264 --crf 26 --zones 0,10,psy-rd=1:1/11,50,psy-rd=0:0 -o test.mkv test.avs

[Sharktooth]

/me suggests skystrife to check his system for stability...

[skystrife]

If there was an issue with stability I would have caught it by now. x264 only crashes with the zones parameter, nothing else. (And I've already tested for stability recently anyway, the system is fine).

I'll rule it out as a problem on my end, though I will continue to use MasterNobody's patch.

EDIT: Just tested with Audionut's build on another Vista x64 machine and it worked just fine. Odd; I'll continue to troubleshoot on my pc then.

EDIT2: *facepalm* It was an avisynth issue, not an x264 issue. -_-;

[burfadel]

Never had an issue with x264 due to it being Vista x64 here either!

[Audionut]

EDIT2: *facepalm* It was an avisynth issue, not an x264 issue. -_-;

Trouble shooting is soooo much fun. :rolleyes:

[komisar]

1034 CLI version with (x264-devel) (PATCH) single frame flashes (http://mailman.videolan.org/pipermail/x264-devel/2008-November/005208.html)

http://komisar.gin.by/

[MasterNobody]

Few new patches from me (MasterNobody / BugMaster): http://stashbox.org/306091/x264_misc_diff_r1032.zip
x264_fix_2pass.r1032.diff - fix this bug (http://forum.doom9.org/showthread.php?t=142922) introduced in r1020 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=418cace8646a6f546a9026da47f79fad7285f577)
x264_vs_compilation_fix.r1032.diff - fix compilation with MS VisualStudio after r1030 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=f9dba8bb274dffb19394db20912823464efcb8e1)
x264_vs_compilation_fix_and_clean.r1032.diff - same as x264_vs_compilation_fix.r1032.diff but also removes old not working configuration Release64 and absent files of decoder

[skystrife]

Ok, well fun, the bug is back. If I build an exe using the patch, it crashes instantly after loading the input file (I'm now using a yuv4mpeg input to rule out avisynth). If I use Audionut's build, it crashes 20% of the time right before printing the "encoded 300 frames, xx.xx fps, xxx.xx kb/s". The output file is ~50 frames short.

The system is not overclocked (it was before but I've brought it back to stock) and the memory is fine (just ran a 12h memtest86). I have no idea wtf is causing this.

I've created a second partition and installed a clean Vista x64 to it (slipstreamed the 4GB fix into the normal install media) and tried running x264 after the install (cd'd to the original partition and ran it from there). My build still crashes, and I can replicate the pattern I'm seeing with Audionut's build. I know this is probably getting off topic, but does anyone have the slightest idea what's going on here?

Interestingly enough, the build that instantly crashes on my machine works flawlessly on other machines (tested on 32-bit XP and 64-bit Vista). This further perplexes me.

I'm about ready to blame my install media.

[LoRd_MuldeR]

Can the crash in your build be tracked down to a certain CPU type? What if you use "--no-asm" to encode ???

[skystrife]

Can the crash in your build be tracked down to a certain CPU type? What if you use "--no-asm" to encode ???

Just got Audionut's to crash with --no-asm. =/ Machine is running a Q6700, friend's machine that I tested on (x64 Vista) was running an E6700 and worked fine.

My build crashes instantaneously with --no-asm as well. Note that it works fine save for zones; I can only replicate the crash when I'm using the zones parameter.

[LoRd_MuldeR]

Just got Audionut's to crash with --no-asm. =/ Machine is running a Q6700, friend's machine that I tested on (x64 Vista) was running an E6700 and worked fine.

My build crashes instantaneously with --no-asm as well.

I'd say: Make a build with --enable-debug and do a stacktrace when it crashes...

[kemuri-_9]

I'd say: Make a build with --enable-debug and do a stacktrace when it crashes...

my new permanent x264 build w/ debug symbols can be found here (http://kemuri9.net/dev/x264/x264_debug.exe)
the debug version is now standardized into my automatic compilation scripting setup,
so it'll update along with the other builds i have.

I find that it should be helpful for such situations when weird crashes occur to nail down the reasons.

[skystrife]

(gdb) run
Starting program: C:\msys\1.0\home\Chase\x264/x264.exe --crf 26 --zones 0,10,psy-rd=1:1/11,50,psy-rd=0:0 -o NUL foreman_cif.y4m
gdb: do_initial_child_stuff: process 3228
gdb: kernel event for pid=3228 tid=3924 code=CREATE_PROCESS_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=UNLOAD_DLL_DEBUG_EVENT)
Error: dll starting at 0x775c1000 not found.

Error: dll starting at 0x75aa1000 not found.

Error: dll starting at 0x775c1000 not found.

Error: dll starting at 0x774f1000 not found.

ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=EXCEPTION_DEBUG_EVENT)
gdb: Target exception EXCEPTION_BREAKPOINT at 0x778a0004
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 3228.0xf54
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=3228, ctid=3924, DBG_CONTINUE);
gdb: kernel event for pid=3228 tid=3924 code=EXCEPTION_DEBUG_EVENT)
gdb: Target exception EXCEPTION_ACCESS_VIOLATION at 0x778bf217

Program received signal SIGSEGV, Segmentation fault.
0x778bf217 in ntdll!RtlDecompressBuffer ()
(gdb) bt full
#0 0x778bf217 in ntdll!RtlDecompressBuffer ()
No symbol table info available.
#1 0x1c0769b8 in ?? ()
No symbol table info available.
#2 0x00000000 in ?? () from
No symbol table info available.
#3 0x02777150 in ?? ()
No symbol table info available.
#4 0x0027f80c in ?? ()
No symbol table info available.
#5 0x75b23593 in KERNEL32!GetNumaAvailableMemoryNode ()
No symbol table info available.
#6 0x00c60000 in ?? ()
No symbol table info available.
#7 0x00000000 in ?? () from
No symbol table info available.
#8 0x1c0769b8 in ?? ()
No symbol table info available.
#9 0x0027f858 in ?? ()
No symbol table info available.
#10 0x76f89d6b in msvcrt!free () from C:\Windows\syswow64\msvcrt.dll
No symbol table info available.
#11 0x00c60000 in ?? ()
No symbol table info available.
#12 0x00000000 in ?? () from
No symbol table info available.
#13 0x1c0769b8 in ?? ()
No symbol table info available.
#14 0xa2704883 in ?? ()
No symbol table info available.
#15 0x00000000 in ?? () from
No symbol table info available.
#16 0x00000001 in ?? ()
No symbol table info available.
#17 0x02777150 in ?? ()
No symbol table info available.
#18 0x76fa24b5 in strtoui64 () from C:\Windows\syswow64\msvcrt.dll
No symbol table info available.
#19 0xd4a8eabb in ?? ()
No symbol table info available.
#20 0xfffffffe in ?? ()
No symbol table info available.
#21 0x76ff5a50 in tempnam_dbg () from C:\Windows\syswow64\msvcrt.dll
No symbol table info available.
#22 0x0027f820 in ?? ()
No symbol table info available.
#23 0x76f8d516 in strncmp () from C:\Windows\syswow64\msvcrt.dll
No symbol table info available.
#24 0x0027ffc4 in ?? ()
No symbol table info available.
#25 0x76fa24b5 in strtoui64 () from C:\Windows\syswow64\msvcrt.dll
No symbol table info available.
#26 0xd4af2d5b in ?? ()
No symbol table info available.
#27 0xfffffffe in ?? ()
No symbol table info available.
#28 0x0027f868 in ?? ()
No symbol table info available.
#29 0x0040ed43 in x264_free (p=0xc60000) at common/common.c:733
p = (void *) 0x1c0769b0

I'm new to debugging anything, so let me know if I'm Doing It Wrong.

[LoRd_MuldeR]

Looks like the crash happens in ntdll.dll (Windows Native API), but it originates from x264_free() in "common.c" :confused:

Reminds me to the crash in x264_malloc as reported here:
http://forum.doom9.org/showthread.php?p=1215181#post1215181

[kemuri-_9]

except that it's failing on a free, which is the oppositte of malloc...
where as malloc can fail when it can't get the memory it needs for allocation,
for free to fail, it means there's no allocated memory to free (freeing a null or unmalloc'd pointer)

and if it was indeed a null or unmalloc'd pointer that was causing free to fail, it should fail consistently across computers/platforms.

[video_magic]

Hey Audionut - thanks for that P4 Prescott build, which is indeed faster than the one from x264.nl , Mainly it is a lot more noticeably so on the first pass :thanks:

I noticed that r1038 is out and wondered whether you might put a Prescott build of that up, because I'm going to leave this machine for half a week encoding.

(Next step in my quest for speed is get a mobo that supports ddr2-800 memory (which my ram is) to run at that speed, someone told me matching 1/1 ram to my CPU bus speed is the best thing I can do if I'm going to not 'bottleneck' encoding.)

[Audionut]

x264-r1038.rar (http://rapidshare.com/files/167452005/x264-r1038.rar)


Patched with,
x264_hrd_pulldown.09_interlace
x264_win_zone_parse_fix_02

[skystrife]

except that it's failing on a free, which is the oppositte of malloc...
where as malloc can fail when it can't get the memory it needs for allocation,
for free to fail, it means there's no allocated memory to free (freeing a null or unmalloc'd pointer)

and if it was indeed a null or unmalloc'd pointer that was causing free to fail, it should fail consistently across computers/platforms.

Should, but unless my original disc is corrupt in some way then something else is borking. I just tried an install from the original disc, no updates installed, no slipstream (popped out 3 sticks of ram to avoid 4GB install bug) and replicated the crash.

(Sorry for clogging up the thread).

For now, I'll use the custom strtok_r patch since that doesn't seem to reproduce the crash on my machine. The crash is really weird, though, and I'd like to find out what's causing it. D=

[Audionut]

I'm in the process of building GDB so I can hopefully debug some builds on my machine.

How about continuing this on irc.

[MasterNobody]

skystrife
Try builds with x264_error_memoryleaks.03.r1032.diff (http://stashbox.org/306370/x264_error_memoryleaks.03.r1032.diff) patch or at least replace
z->param = malloc( sizeof(x264_param_t) );
with
z->param = x264_malloc( sizeof(x264_param_t) );
in parse_zone function

P.S. I mentioned this error in post1211218 (http://forum.doom9.org/showthread.php?p=1211218#post1211218) in x264_error_memoryleaks.03.r1019.diff description.

[burfadel]

Should, but unless my original disc is corrupt in some way then something else is borking. I just tried an install from the original disc, no updates installed, no slipstream (popped out 3 sticks of ram to avoid 4GB install bug) and replicated the crash.

(Sorry for clogging up the thread).

For now, I'll use the custom strtok_r patch since that doesn't seem to reproduce the crash on my machine. The crash is really weird, though, and I'd like to find out what's causing it. D=

I take it you have all the normal updates applied (normal means updates available on the download site, windowsupdate etc as there are many times more hotfixes available than normal updates for all Microsoft products)? Many people still don't have SP1 installed due to the windowsupdate debacle...

What build of ntdll.dll do you have? Mines 6.0.6001.22221

[MasterNobody]

Updated collection of my patches: bm_x264_patch_collection.r1038.zip (http://stashbox.org/306696/bm_x264_patch_collection.r1038.zip)

[skystrife]

I take it you have all the normal updates applied (normal means updates available on the download site, windowsupdate etc as there are many times more hotfixes available than normal updates for all Microsoft products)? Many people still don't have SP1 installed due to the windowsupdate debacle...

What build of ntdll.dll do you have? Mines 6.0.6001.22221

Yeah, all the updates installed have been from Windows Update. ntdll version is 6.0.6001.18000. /me wonders why it's less than what you have.

And, I just got a friend to get the build to crash on his system, so it's not just me. (Note that it crashes intermittently; sometimes I need to run it about five times before I get the crash, but others it just crashes instantly.)

[Audionut]

For what it's worth, my ntdll version is 6.0.6001.18000 also.

Date modified 21/01/2008

[MasterNobody]

skystrife
Did you try what I write here: #post1217256 (http://forum.doom9.org/showthread.php?p=1217256#post1217256)?

P.S. I think x264_win_zone_parse_fix_02.diff have bugs. I highly doubt about correctness of this actions:
tok = ( char * ) x264_realloc( tok, i_tok+1 );
I think you have crash in x264_realloc

[kemuri-_9]

how's that a bug?

[MasterNobody]

kemuri-_9
At least you need to initialize tok before first call to x264_realloc. Like this: x264_win_zone_parse_fix_03.diff (http://stashbox.org/307641/x264_win_zone_parse_fix_03.diff)

[kemuri-_9]

yeah, i'll give you that one,
there is a small chance that the memory allocated for the char * is not 0'd out and will conflict with the first call to x264_realloc, causing a seg fault,

but if that's truly the cause, i would expect more randomness in success/failure.
especially in skystrife's case who's getting purefire failures.

[burfadel]

That build is from hotfix update KB955455, not a general release update :) This is where the confusion comes in to play with service packs, many say that a service pack is a recompiled version of all the released updates which is incorrect! Microsoft doesn't release most of their updates, and the above is one of them.

The update can be requested here (its an automated process):
http://support.microsoft.com/kb/955445/en-us

Hotfixes are released almost daily, some of them install later revisions of files than earlier hotfixes, but the hotfixes themselves aren't listed as replacements for earlier hotfixes. I download them just out of interest, and some of them can be a little interesting. Including the normal updates there are over 276 unique (from what I can tell) updates!

If you're curious, open task manager and check out the memory usage of explorer.exe without any explorer windows open. Run the following update:
http://support.microsoft.com/kb/955555/en-us

Then when back in windows (and even after doing stuff) check out the memory use of explorer.exe again. You'll find that its much (unbelievability) lower :)!

The build includes all updates both listed on the update site and internal modifications to the code, the above gives an indication of how things are now being coded/compiled better by Microsoft, at least it seems that way!

[Audionut]

x264-r1040.rar (http://rapidshare.com/files/167859766/x264-r1040.rar)


Patched with,
x264_hrd_pulldown.09_interlace
x264_win_zone_parse_fix_03

[kemuri-_9]

i've been snooping around here and there, and came across some extra aligned memory allocation methods for both mingw and msvc
(which currently x264 has to hand align for both of these)

mingw (http://kemuri9.net/dev/x264/patches/x264_mingw_aligned.diff)
adds a requirement to have mingw's mingwex library (patch currently assumes it's just there).
msvc (http://kemuri9.net/dev/x264/patches/x264_msvc_aligned.diff)
they've been there since VC7.1
mingw+msvc (http://kemuri9.net/dev/x264/patches/x264_mingw_msvc_aligned.diff)
necessary, since the singles will reject each other

i would like to see if some people could help in testing these,
to see if there's any conflicts and noticeable performance gain/loss,
to then see if they're worth using permanently.
(ofc definitely not if there's any noticeable performance loss)

thanks in advance.

Edit:
dev input on whether or not that these functions are already known to be slower, would also be useful.

[Audionut]

x264-r1040-patch.rar (http://rapidshare.com/files/168068203/x264-r1040-patch.rar)

Patched with,
x264_hrd_pulldown.09_interlace
x264_win_zone_parse_fix_03
x264_mingw_aligned.diff

2 runs with this build.
E:\>x264 --crf 15.0 --keyint 120 --min-keyint 2 --ref 4 --mixed-refs --bframes 5
--b-adapt 2 --b-pyramid --weightb --direct auto --deblock -2:-1 --subme 7 --tre
llis 1 --psy-rd 0.8:0 --partitions all --8x8dct --qpmin 1 --qpstep 6 --ipratio
1.3 --pbratio 1.1 --vbv-bufsize 40000 --vbv-maxrate 40000 --scenecut 30 --merang
e 32 --threads auto --thread-input --aq-strength 0.4 --progress --no-psnr --no-s
sim --output "e:\222.mp4" "e:\test.avs" --level 4.1
avis [info]: 1280x720 @ 23.98 fps (982 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 834166 (scale 10000000)
x264 [info]: slice I:15 Avg QP:12.50 size:199076
x264 [info]: slice P:384 Avg QP:14.38 size: 53499
x264 [info]: slice B:583 Avg QP:15.34 size: 23749
x264 [info]: consecutive B-frames: 3.2% 33.5% 50.3% 8.7% 3.1% 1.2%
x264 [info]: mb I I16..4: 6.5% 64.1% 29.4%
x264 [info]: mb P I16..4: 0.4% 5.6% 1.8% P16..4: 38.1% 22.1% 19.3% 2.3% 3
.2% skip: 7.1%
x264 [info]: mb B I16..4: 0.0% 0.8% 0.4% B16..8: 37.0% 5.0% 8.5% direct:
5.9% skip:42.4% L0:36.1% L1:42.8% BI:21.1%
x264 [info]: 8x8 transform intra:68.8% inter:50.3%
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: ref P L0 61.9% 17.8% 12.7% 7.6%
x264 [info]: ref B L0 75.0% 18.5% 6.5%
x264 [info]: ref B L1 90.5% 9.5%
x264 [info]: kb/s:7300.4

encoded 982 frames, 11.21 fps, 7300.59 kb/s

E:\>x264 --crf 15.0 --keyint 120 --min-keyint 2 --ref 4 --mixed-refs --bframes 5
--b-adapt 2 --b-pyramid --weightb --direct auto --deblock -2:-1 --subme 7 --tre
llis 1 --psy-rd 0.8:0 --partitions all --8x8dct --qpmin 1 --qpstep 6 --ipratio
1.3 --pbratio 1.1 --vbv-bufsize 40000 --vbv-maxrate 40000 --scenecut 30 --merang
e 32 --threads auto --thread-input --aq-strength 0.4 --progress --no-psnr --no-s
sim --output "e:\222.mp4" "e:\test.avs" --level 4.1
avis [info]: 1280x720 @ 23.98 fps (982 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 834166 (scale 10000000)
x264 [info]: slice I:15 Avg QP:12.50 size:199076
x264 [info]: slice P:384 Avg QP:14.38 size: 53499
x264 [info]: slice B:583 Avg QP:15.34 size: 23749
x264 [info]: consecutive B-frames: 3.2% 33.5% 50.3% 8.7% 3.1% 1.2%
x264 [info]: mb I I16..4: 6.5% 64.1% 29.4%
x264 [info]: mb P I16..4: 0.4% 5.6% 1.8% P16..4: 38.1% 22.1% 19.3% 2.3% 3
.2% skip: 7.1%
x264 [info]: mb B I16..4: 0.0% 0.8% 0.4% B16..8: 37.0% 5.0% 8.5% direct:
5.9% skip:42.4% L0:36.1% L1:42.8% BI:21.1%
x264 [info]: 8x8 transform intra:68.8% inter:50.3%
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: ref P L0 61.9% 17.8% 12.7% 7.6%
x264 [info]: ref B L0 75.0% 18.5% 6.5%
x264 [info]: ref B L1 90.5% 9.5%
x264 [info]: kb/s:7300.4

encoded 982 frames, 11.26 fps, 7300.59 kb/s


2 runs with my original revision 1040 build.
K:\>x264 --crf 15.0 --keyint 120 --min-keyint 2 --ref 4 --mixed-refs --bframes 5
--b-adapt 2 --b-pyramid --weightb --direct auto --deblock -2:-1 --subme 7 --tre
llis 1 --psy-rd 0.8:0 --partitions all --8x8dct --qpmin 1 --qpstep 6 --ipratio
1.3 --pbratio 1.1 --vbv-bufsize 40000 --vbv-maxrate 40000 --scenecut 30 --merang
e 32 --threads auto --thread-input --aq-strength 0.4 --progress --no-psnr --no-s
sim --output "e:\111.mp4" "e:\test.avs" --level 4.1
avis [info]: 1280x720 @ 23.98 fps (982 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 834166 (scale 10000000)
x264 [info]: slice I:15 Avg QP:12.50 size:199076
x264 [info]: slice P:384 Avg QP:14.38 size: 53499
x264 [info]: slice B:583 Avg QP:15.34 size: 23749
x264 [info]: consecutive B-frames: 3.2% 33.5% 50.3% 8.7% 3.1% 1.2%
x264 [info]: mb I I16..4: 6.5% 64.1% 29.4%
x264 [info]: mb P I16..4: 0.4% 5.6% 1.8% P16..4: 38.1% 22.1% 19.3% 2.3% 3
.2% skip: 7.1%
x264 [info]: mb B I16..4: 0.0% 0.8% 0.4% B16..8: 37.0% 5.0% 8.5% direct:
5.9% skip:42.4% L0:36.1% L1:42.8% BI:21.1%
x264 [info]: 8x8 transform intra:68.8% inter:50.3%
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: ref P L0 61.9% 17.8% 12.7% 7.6%
x264 [info]: ref B L0 75.0% 18.5% 6.5%
x264 [info]: ref B L1 90.5% 9.5%
x264 [info]: kb/s:7300.4

encoded 982 frames, 10.84 fps, 7300.59 kb/s

K:\>x264 --crf 15.0 --keyint 120 --min-keyint 2 --ref 4 --mixed-refs --bframes 5
--b-adapt 2 --b-pyramid --weightb --direct auto --deblock -2:-1 --subme 7 --tre
llis 1 --psy-rd 0.8:0 --partitions all --8x8dct --qpmin 1 --qpstep 6 --ipratio
1.3 --pbratio 1.1 --vbv-bufsize 40000 --vbv-maxrate 40000 --scenecut 30 --merang
e 32 --threads auto --thread-input --aq-strength 0.4 --progress --no-psnr --no-s
sim --output "e:\222.mp4" "e:\test.avs" --level 4.1
avis [info]: 1280x720 @ 23.98 fps (982 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 834166 (scale 10000000)
x264 [info]: slice I:15 Avg QP:12.50 size:199076
x264 [info]: slice P:384 Avg QP:14.38 size: 53499
x264 [info]: slice B:583 Avg QP:15.34 size: 23749
x264 [info]: consecutive B-frames: 3.2% 33.5% 50.3% 8.7% 3.1% 1.2%
x264 [info]: mb I I16..4: 6.5% 64.1% 29.4%
x264 [info]: mb P I16..4: 0.4% 5.6% 1.8% P16..4: 38.1% 22.1% 19.3% 2.3% 3
.2% skip: 7.1%
x264 [info]: mb B I16..4: 0.0% 0.8% 0.4% B16..8: 37.0% 5.0% 8.5% direct:
5.9% skip:42.4% L0:36.1% L1:42.8% BI:21.1%
x264 [info]: 8x8 transform intra:68.8% inter:50.3%
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: ref P L0 61.9% 17.8% 12.7% 7.6%
x264 [info]: ref B L0 75.0% 18.5% 6.5%
x264 [info]: ref B L1 90.5% 9.5%
x264 [info]: kb/s:7300.4

encoded 982 frames, 10.44 fps, 7300.59 kb/s

[skystrife]

x264.1040M.exe (http://www.mediafire.com/?jnytznqheyk) - Alternate Download (http://skystrife.com/x264/x264.1040M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_03.diff
x264_mingw_aligned.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

The 03 version of the zones patch appears to have fixed the crashing issue. Thanks MasterNobody!

[laserfan]

x264.1040M.exe (http://www.mediafire.com/?jnytznqheyk) - Alternate Download (http://skystrife.com/x264/x264.1040M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_03.diff
x264_mingw_aligned.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

The 03 version of the zones patch appears to have fixed the crashing issue...
Just a note to say "THANKS" skystrife for your quality/timely builds!

:thanks:

[skystrife]

x264.1042M.exe (http://www.mediafire.com/?t1lmjn2jtme) - Alternate Download (http://skystrife.com/x264/x264.1042M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_03.diff
x264_mingw_aligned.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[Audionut]

x264-r1042.rar (http://rapidshare.com/files/168377004/x264-r1042.rar)

Patched with,
x264_hrd_pulldown.09_interlace
x264_win_zone_parse_fix_03
x264_mingw_aligned.diff

[kemuri-_9]

ok, so i've been trying to benchmark standard builds of msvc and mingw against the built-in aligned memory functions in the patches above.

my findings are:
MSVC - up to 1.5% slower (honestly, with how broken msvc is, not really surprising)
MinGW - up to 1% faster

so:
A. the msvc one is dropped due to noticeable performance loss.
B. It turns out that the library that the mingw aligned memory methods lie within is (always?) automatically included in the build,
so there's not an extra dependency like originally thought of.
thus, new patch to reflect this (also redone to minimize code changes):
x264_mingw_aligned_02.diff (http://kemuri9.net/dev/x264/patches/x264_mingw_aligned_02.diff)

as a small side note, i suspect that cygwin would have some similar functions,
but as i don't develop within it, i don't know what they actually are.

[Audionut]

x264-r1046.rar (http://rapidshare.com/files/168799673/x264-r1046.rar)

x264 0.65.0+1046 71d34b4
built on Nov 30 2008, gcc: 3.4.5 (mingw-vista special r3)

Patched with,
x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_03.diff
x264_mingw_aligned_02.diff

[Dark Shikari]

as a small side note, i suspect that cygwin would have some similar functions,
but as i don't develop within it, i don't know what they actually are.x264 doesn't use Cygwin; it's compiled with -mno-cygwin on Cygwin systems.

[kemuri-_9]

x264 doesn't use Cygwin; it's compiled with -mno-cygwin on Cygwin systems.

well, i was referring to what the aligned memory function names/prototypes are.
the choices (of course) are
A. linux standard prototypes
B. some special prototypes (ex. mingw's were much more similar to the msvc prototypes than linux's)

but as i've never used cygwin, i don't know which one it falls under,
nor if using the built-in aligned methods will cause a positive performance difference

[MasterNobody]

Here is patch that allow to use --no-b-adapt (--b-adapt 0) along with --pre-scenecut (and so with multiple threads): x264_no_b_adapt_with_pre_scenecut.r1046.diff (http://stashbox.org/310366/x264_no_b_adapt_with_pre_scenecut.r1046.diff)

P.S. --no-b-adapt sometimes useful for testing purposes (also someone can consider that this is bug that it doesn't work with --pre-scenecut or multithreading).

[skystrife]

I'm getting a crash during fprofiling when I use the updated mingw patch, kemuri. If I use the previous one I can't get it to crash, but I can readily get the new patch version to crash.


Here's a backtrace from a debug build (using the settings from the fprofile run that made it crash):

(gdb) file x264
Reading symbols from C:\msys\1.0\home\Chase\x264/x264.exe...done.
(gdb) run --crf 30 -b1 -m1 -r1 --me dia --no-cabac --pre-scenecut --direct temporal --no-ssim --no-psnr --progress -o NUL test.y4m
Starting program: C:\msys\1.0\home\Chase\x264/x264.exe --crf 30 -b1 -m1 -r1 --me dia --no-cabac --pre-scenecut --direct temporal --no-ssim --no-psnr --progress -o NUL test.y4m
gdb: do_initial_child_stuff: process 5328
gdb: kernel event for pid=5328 tid=3888 code=CREATE_PROCESS_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=UNLOAD_DLL_DEBUG_EVENT)
Error: dll starting at 0x77211000 not found.

Error: dll starting at 0x75a41000 not found.

Error: dll starting at 0x77211000 not found.

Error: dll starting at 0x77341000 not found.

ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=EXCEPTION_DEBUG_EVENT)
gdb: Target exception EXCEPTION_BREAKPOINT at 0x775c0004
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 5328.0xf30
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=LOAD_DLL_DEBUG_EVENT)
yuv4mpeg: 1920x1080@12570329/524288fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 4.0
gdb: child_resume.SetThreadContext: thread 5328.0xf30 0:00:00
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=UNLOAD_DLL_DEBUG_EVENT)
ContinueDebugEvent (cpid=5328, ctid=3888, DBG_CONTINUE);
gdb: kernel event for pid=5328 tid=3888 code=EXCEPTION_DEBUG_EVENT)
gdb: Target exception EXCEPTION_ACCESS_VIOLATION at 0x775df217

Program received signal SIGSEGV, Segmentation fault.
0x775df217 in ntdll!RtlDecompressBuffer ()
(gdb) bt
#0 0x775df217 in ntdll!RtlDecompressBuffer ()
#1 0x1900e308 in ?? ()
#2 0x00000020 in ?? ()
#3 0x00345010 in ?? ()
#4 0x0027f84c in ?? ()
#5 0x75ac3593 in KERNEL32!GetNumaAvailableMemoryNode ()
#6 0x00340000 in ?? ()
#7 0x00000000 in ?? () from
#8 0x1900e308 in ?? ()
#9 0x0027f898 in ?? ()
#10 0x763c9d6b in msvcrt!free () from C:\Windows\syswow64\msvcrt.dll
#11 0x00340000 in ?? ()
#12 0x00000000 in ?? () from
#13 0x1900e308 in ?? ()
#14 0x723d3e7a in ?? ()
#15 0x00000020 in ?? ()
#16 0x00000000 in ?? () from
#17 0x00345010 in ?? ()
#18 0x026251d0 in ?? ()
#19 0x00000000 in ?? () from
#20 0x0027f898 in ?? ()
#21 0x0040eb7d in x264_log (h=0x340000, i_level=0,
psz_fmt=0x1900e308 <Address 0x1900e308 out of bounds>)
at common/common.c:598

Any ideas? (I'll continue to use the previous patch for now.)

[kemuri-_9]

hmm... strange... i'll have to crack at it then.

Edit:
ok, i'm confirming the crash, i suspect that the way the 2nd patch works is interfering with some of the calls to free() on non aligned memory.
i'll work a new one out using the first patch as a starting point.

Edit Edit:
ok, new patch
preventing breaking cygwin building (as the first probably did break it)
preventing overwriting basic mem functions to avoid aligned freeing non aligned mem (problem with the second)
x264_mingw_aligned_03.diff (http://kemuri9.net/dev/x264/patches/x264_mingw_aligned_03.diff)

[skystrife]

Thanks, kemuri.

x264.1046M.exe (http://www.mediafire.com/?nfjlmmjzgzm) - Alternate Download (http://skystrife.com/x264/x264.1046M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_03.diff
x264_mingw_aligned_03.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[Willyfan]

I'm trying to compile x264, dowloaded from the last snapshot and patched with the last patch, using visual studio 2008. (I want to try to apply a old patch for slicing support, for BD specs problem). I convert from VC 7 to visual studio without problem, and the porgram compile without errot, but when I try to encode the encoding is very slow. There is something I need to do? Many thanks.
William

[LoRd_MuldeR]

Some of the assmbler functions are not working with MSVC compiler and will be disabled. Hence MSVC builds are a bit slower than MinGW/GCC builds.

Also make sure yasm.exe (nasm.exe isn't supporetd anymore) is available in your build environment. Otherwise all assembler code is disabled and you will get a really slow build...

[Willyfan]

What is the best compiler I must to use for the best result (under XP)?

[LoRd_MuldeR]

What is the best compiler I must to use for the best result (under XP)?

There is no "best" compiler and you are not allowed to ask what's best. Use the compiler that works most convenient for you ;)

I personally use TDM's Experimental GCC/MinGW32 Builds (http://www.tdragon.net/recentgcc/) plus MSYS (http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=24963&release_id=89960). It seems most of the x264 builds floating around are MinGW/GCC builds :)

[Willyfan]

There is no "best" compiler and you are not allowed to ask what's best.
I'm really sorry, the question was what compiler was the best for x264, or if x264 is compiled with a specific compiler. Not what is the best compiler at all. Anyway, many thanks for your advice.
William

[LoRd_MuldeR]

I'm really sorry, the question was what compiler was the best for x264, or if x264 is compiled with a specific compiler. Not what is the best compiler at all. Anyway, many thanks for your advice.
William

Still there is no "best" compiler for x264. Use the compiler that works best for your individual needs and preferences...

(Not that if you use TDM's MinGW/GCC and MSYS, you still need to install yasm.exe separately. The pthread lib is already included in TDM's installer)

[Audionut]

This should help get you started with Mingw.

http://forum.doom9.org/showthread.php?p=723782#post723782

[kemuri-_9]

I've ran comparisons of mingw and msvc builds,
in my case it was gcc 3.4.5 fprofiled and 2008 (vc++ 9) w/ PGO,
and they were fairly close in speeds, so this is not the problem.

there's a few possibilities that would have the MSVC version go slow:
A1. it's in debug configuration (which is extremely slow compared to release)
A2. Release config is not fully optimized.

B. the problem may be that it's not compiling with asm support
make sure HAVE_MMX is defined in the preprocessor section of the
projects.

C. no pthread support
the .vcproj's do not have pthread (nor gpac) support by default,
you'll need to compile, and then add the respective folders to the library and include paths for the x264 and libx264 solutions
(gpac to x264, pthreads to both)
then add in the proper preprocessor defines to have x264/libx264 go looking for them to compile with support.
(MP4_OUTPUT and HAVE_PTHREADS iirc)

[Willyfan]

C. no pthread support
the .vcproj's do not have pthread (nor gpac) support by default,
you'll need to compile, and then add the respective folders to the library and include paths for the x264 and libx264 solutions
(gpac to x264, pthreads to both)
then add in the proper preprocessor defines to have x264/libx264 go looking for them to compile with support.
(MP4_OUTPUT and HAVE_PTHREADS iirc)

Yes, I think that this is my problem. Now I downloaded the last version of pthread library (2.8.0). A question about gpac: this one is a framework, and need compilation, and not a library. Can you explain to me how to use gpac in MSVC? Many thanks!
William

[Dark Shikari]

Still there is no "best" compiler for x264. Use the compiler that works best for your individual needs and preferences...Certainly any compiler that doesn't define __GNUC__, however, couldn't be the best, as that disables a whole lot of inline assembly and such.

[foxyshadis]

Still there is no "best" compiler for x264. Use the compiler that works best for your individual needs and preferences...

No, that's the advice for 'best' video questions. Here, 'best' is possible to answer because there's only one recommended & supported compiler for x264: gcc. I still say it's better to err on the side of being helpful than on being a rules lawyer, but admittedly not everyone agrees.

Willy, you should still get used to asking for 'recommended' or 'your recommendations' if you stick around here long, though.

[Dark Shikari]

No, that's the advice for 'best' video questions. Here, 'best' is possible to answer because there's only one recommended & supported compiler for x264: gcc. I still say it's better to err on the side of being helpful than on being a rules lawyer, but admittedly not everyone agrees.ICC works as well, since it has a GCC compatibility mode.

[Audionut]

x264 0.65.0+1051 549cc55 (http://rapidshare.com/files/172339645/x264-r1051.rar)
built on Dec 11 2008, gcc: 3.4.5 (mingw-vista special r3)


Patched with,
x264_hrd_pulldown.09_interlace.diff
x264_mingw_aligned_03.diff

There was an error trying to patch x264_win_zone_parse_fix_03.diff, and i'm not clever enough to fix it.

[bob0r]

For x264_win_zone_parse_fix_03.diff, change:

- char *p, *tok, *saveptr;

to

- char *p, *tok, UNUSED *saveptr;

[Audionut]

Yep, that fixed it. Thanks bob0r.

x264_win_zone_parse_fix_04.diff (http://rapidshare.com/files/172375397/x264_win_zone_parse_fix_04.diff)


As above but with the zone patch.
x264-r1051-A.rar (http://rapidshare.com/files/172377727/x264-r1051-A.rar)

[skystrife]

x264.1051M.exe (http://www.mediafire.com/?20tndewntxz) - Alternate Download (http://skystrife.com/x264/x264.1051M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_04.diff
x264_mingw_aligned_03.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[kemuri-_9]

i will no longer be supporting the
x264_win_zone_parse_fix patch i originally started.

for the reason of:
I've successfully added BugMaster's strtok_r to my mingw's native libraries.
it works like a charm,
thus the patch is not needed for me anymore ;)

[Sharktooth]

kemuri-_9: please submit the changes to the mingw team. maybe they will consider to add them in future versions.

[skystrife]

i will no longer be supporting the
x264_win_zone_parse_fix patch i originally started.

for the reason of:
I've successfully added BugMaster's strtok_r to my mingw's native libraries.
it works like a charm,
thus the patch is not needed for me anymore ;)

This may be a dumb question, but how did you go about doing this?

--------------------------------------------------------------------

x264.1055M.exe (http://www.mediafire.com/?gtzygdgwmrz) - Alternate Download (http://skystrife.com/x264/x264.1055M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_04.diff
x264_mingw_aligned_03.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

[kemuri-_9]

This may be a dumb question, but how did you go about doing this?

put it most simply 'library hacking' though i wouldn't slate it as 100% hacking,
due to the way the mingw libraries are setup as ar packages.

[Audionut]

x264-r1056.rar (http://rapidshare.com/files/173767502/x264-r1056.rar)

Patched with,
x264_hrd_pulldown.09_interlace.diff
x264_mingw_aligned_03.diff
x264_win_zone_parse_fix_04.diff

[kemuri-_9]

This may be a dumb question, but how did you go about doing this?

I've finished standardizing a shell script which should be able to handle patching any mingw installation...
(in other words, tell me if it says it didn't work with supplying what didn't work)

files:
install_strtok_r.sh (http://kemuri9.net/dev/mingw/install_strtok_r.sh): "./install_strtok_r.sh /mingw" - should work for most (requires base directory prefix of lib and include dirs as a parameter - which for most is /mingw)
x264_mingw_check_strtok_r.diff (http://kemuri9.net/dev/x264/patches/x264_mingw_check_strtok_r.diff): recognize existence of strtok_r to not define it as strtok if strtok_r does exist.

Edit:
oh right, here's a patch for msvc users to use its version of reentrant strtok (and thus have zone support).
x264_msvc_zones_fix.diff (http://kemuri9.net/dev/x264/patches/x264_msvc_zones_fix.diff)

[skystrife]

Thanks again, kemuri; the script worked like a charm.

x264.1057M.exe (http://www.mediafire.com/?nmuzkwjttmj) - Alternate Download (http://skystrife.com/x264/x264.1057M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_mingw_aligned_03.diff
x264_mingw_check_strtok_r.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

-----------------------------------------------

x264.1057M.x64.exe (http://www.mediafire.com/?5m0uzndzzdi) - Alternate Download (http://skystrife.com/x264/x264.1057M.x64.exe)

Patches used:
x264_win64_support.01.r1057.diff
x264_win_zone_parse_fix_04.diff (as the custom strtok_r patch likes to crash with the 64-bit build, unsure as of why but it crashes upon reaching 100% completion. I suspect gcc being stupid, personally.)
x264_mingw_aligned_03.diff
x264_hrd_pulldown.09_interlace.diff

[burfadel]

What do these two uncommitted? patches do?
http://akuvian.org/src/x264/satd.diff

http://akuvian.org/src/x264/sea.diff

The second one has some SSE4 references :)

[Dark Shikari]

What do these two uncommitted? patches do?
http://akuvian.org/src/x264/satd.diff

http://akuvian.org/src/x264/sea.diff

The second one has some SSE4 references :)The first is the first part of an evil plan to make an obnoxiously fast SATD function. Current estimations say that we might be able to beat the current one by over 60% on Conroe Core 2. Once all the parts of the evil plan come together, they may result in the largest speed gain in a single patch in at least a year.

The second one is a prototype of an attempt to make exhaustive a little bit faster.

Wait for them to be finished and committed :p

[burfadel]

What would a 60 percent faster SATD function result in overall for speed, using typical settings (as an estimation)? :) I realise its not nice to annoy developers with such questions, but I think its justified in this case :D.

Keep up the great work! Its appreciated by a lot of people. Merry Christmas/Seasons greetings!

[Dark Shikari]

What would a 60 percent faster SATD function result in overall for speed, using typical settings (as an estimation)? :) I realise its not nice to annoy developers with such questions, but I think its justified in this case :D.At ordinary encoding settings, SATD can be up to 20-25% of encoding time.

Do the math.

(By the way, we define "60% faster" as "60% more SATDs can be done in the same period of time", not "takes 60% less time").

[kemuri-_9]

Patches used:
x264_win64_support.01.r1057.diff
x264_win_zone_parse_fix_04.diff (as the custom strtok_r patch likes to crash with the 64-bit build, unsure as of why but it crashes upon reaching 100% completion. I suspect gcc being stupid, personally.)
x264_mingw_aligned_03.diff
x264_hrd_pulldown.09_interlace.diff

reasons for the crash could be one of the following:
1. it might be crashing due to the mingw aligned patch, since the function names are different for mingw x64.*1

2. the win zone patch also includes a memory allocation change since 03,
this change is meant to fix possible incorrect allocations, which could rear it's ugly head in data manipulation and when freeing the data which would result in seg faults.
the strtok_r patch does not include the supposed memory allocation fix, as it's never crashed for me in mingw builds, only in msvc builds.

*1
I'm holding on releasing the updated patch, since I'm not sure what's going on with mingw x64 having the necessary aligned memory prototypes commented out in the header file.
(options are that the methods are not implemented or not needed, but i'm not exactly sure which one it is - current patch assumes the latter)

you can try out my build listed in the win x64 support thread to see if it proceeds to crash so i can determine if the patches are ok to release or need some working.

[alexVS]

I have a question that may be very simple, may be not
I use VFW version of h264 encoder for using in TMpg Express 4.0 Encoder.
I use default settings, just set up ABR mode and bitrait.

What h264 codec settings can I change to get much better output quality WITHOUT big decrease of encoding speed?
I've got not a superb CPU. Only Athlon64 X2 4000+

[bmnot]

Why this patch was not accepted in main code?


HD HRD/Pulldown Patch:
Current: x264_hrd_pulldown.diff
Creator: Ian Caulfield/Trahald
Description: HRD and pulldown for HD compatibility.


Sorry, I didn't read 70 pages, but I am seeing it in many alternative builds.

[J_Darnley]

Why this patch was not accepted in main code?
Sorry, I didn't read 70 pages, but I am seeing it in many alternative builds.
:search: http://forum.doom9.org/showthread.php?p=1086281&highlight=hrd#post1086281

Granted it was not in this thread but it wasn't hard to find by searching for posts by akupenguin that contain hrd

[MasterNobody]

I have a question that may be very simple, may be not
I use VFW version of h264 encoder for using in TMpg Express 4.0 Encoder.
I use default settings, just set up ABR mode and bitrait.

What h264 codec settings can I change to get much better output quality WITHOUT big decrease of encoding speed?
I've got not a superb CPU. Only Athlon64 X2 4000+
This is bad thread for VfW discussion (better here (http://forum.doom9.org/showthread.php?t=98247)). If you mean x264vfw then I would recommend to change this options (they are not optimal by default but there is reason why they used):
Max consecutive B-frames: 0 -> 3
Threads: 1 -> 0
Max frame refs: 1 -> 3
BUT this changes would lead to drop of few last frames (and may be video vs audio desync). And you can't use "VirtualDub hack" to fix this problems because TMPGEnc doesn't support it.

[burfadel]

I thought www.x264.nl was self updating? I see there's rev 1058 up on git for 12 hours and www.x264.nl still shows build 1057...

I don't use ESA for which the patch pertains to, however I'm still curious why it hasn't self updated in case the same thing happens later! :)

[LoRd_MuldeR]

I thought www.x264.nl was self updating? I see there's rev 1058 up on git for 12 hours and www.x264.nl still shows build 1057...

I don't use ESA for which the patch pertains to, however I'm still curious why it hasn't self updated in case the same thing happens later! :)

Maybe the compile script failed? :p

[EDIT]

Yup, something seems to be wrong with r1058 :eek:

This happens with "make fprofiled" on my system:

http://img411.imageshack.us/img411/6885/x264crashja4.th.png (http://img411.imageshack.us/img411/6885/x264crashja4.png)

[EDIT²]

Seems like "-me esa" causes a crash, as soon as the encoding process reaches 100%.

Can't post backtrace, because GDB encounters an "internal error" right at the beginning with my r1058 debug build :confused:

[burfadel]

At a guess I'd presume the output file is fine? It may be related to the issue that I and someone else mentioned a few days ago under the x64 x264 thread, that rarely and unreproduceably the x86 x264 crashes right at the end, exactly the same fault as in your screenshot!

[LoRd_MuldeR]

At a guess I'd presume the output file is fine? It may be related to the issue that I and someone else mentioned a few days ago under the x64 x264 thread, that rarely and unreproduceably the x86 x264 crashes right at the end, exactly the same fault as in your screenshot!

Since it only happens with "--me esa" and didn't happen in previous revision, I suspect the latest commit...

[Audionut]

No problems here.


x264-r1058.rar (http://rapidshare.com/files/175769647/x264-r1058.rar)


Patched with,
x264_hrd_pulldown.09_interlace.diff
x264_mingw_aligned_03.diff
x264_win_zone_parse_fix_04.diff

[LoRd_MuldeR]

No problems here.


x264-r1058.rar (http://rapidshare.com/files/175769647/x264-r1058.rar)


Patched with,
x264_hrd_pulldown.09_interlace.diff
x264_mingw_aligned_03.diff
x264_win_zone_parse_fix_04.diff

Nope. Identical problem with that build:

http://img254.imageshack.us/img254/1669/x264crash2pnguj9.th.jpg (http://img254.imageshack.us/img254/1669/x264crash2pnguj9.jpg)

[Audionut]

Well I had no problems with a simple command line such as yours, with a 300 frame yuv or a 9000 frame avs.

But I am getting a crash with a more complex command line.
Still testing.

edit: ok, i've nailed it down to the input parameter.


edit2. No it's not. It's the resolution making it crash.

width of 960 and under works
962 = unsupported input format
964 = crash.

[LoRd_MuldeR]

Well, it crashed for me with a 352x288 sample, raw YUV data. And only with the "--me esa" parameter...

[Audionut]

http://img72.imageshack.us/img72/1654/x264qs4.png

[LoRd_MuldeR]

Any ideas what to do with that ???

C:\TEMP\x264\x264>gdb --args x264.exe --crf 22 --me esa --output NUL --progress c:\temp\x264\sample.avs
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) run
Starting program: C:\TEMP\x264\x264/x264.exe --crf 22 --me esa --output NUL --pr
ogress c:\\temp\\x264\\sample.avs
[New thread 2036.0xce8]
Error: dll starting at 0x77d40000 not found.
Error while mapping shared library sections:
NOT_AN_IMAGE: No such file or directory.
Error while mapping shared library sections:
C:\WINDOWS\SysWOW64\ntdll32.dll: No such file or directory.
Error: dll starting at 0x77d40000 not found.
Error: dll starting at 0x77c20000 not found.
[New thread 2036.0x18c]
warning: DllMain: hModule=0x024a0000, ulReason=1, lpReserved=0x00000000, gRefCnt
= 0

warning: DllGetClassObject() CLSID: CAVIFileSynth

warning: 00038190->CAVIFileSynth::CAVIFileSynth()

warning: 00038190->CAVIFileSynth::AddRef() gRefCnt=1, m_refs=1

warning: 00038190->CAVIFileSynth::QueryInterface() {00000001-0000-0000-c000-0000
00000046} (IClassFactory)

warning: 00038190->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2

warning: 00038190->CAVIFileSynth::Release() gRefCnt=1, m_refs=1

warning: DllGetClassObject() result=0x0, object=00038198

warning: 00038190->CAVIFileSynth::CreateInstance()

warning: 000381E8->CAVIFileSynth::CAVIFileSynth()

warning: 000381E8->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=1

warning: 000381E8->CAVIFileSynth::QueryInterface() {00000000-0000-0000-c000-0000
00000046} (IUnknown)

warning: 000381E8->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=2

warning: 000381E8->CAVIFileSynth::Release() gRefCnt=2, m_refs=1

warning: 00038190->CAVIFileSynth::CreateInstance() result=0x0, object=000381E8

warning: 000381E8->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=2

warning: 000381E8->CAVIFileSynth::Release() gRefCnt=2, m_refs=1

warning: 00038190->CAVIFileSynth::Release() gRefCnt=1, m_refs=0

warning: 00038190->CAVIFileSynth::~CAVIFileSynth(), gRefCnt = 1

warning: 000381E8->CAVIFileSynth::QueryInterface() {00000000-0000-0000-c000-0000
00000046} (IUnknown)

warning: 000381E8->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2

warning: 000381E8->CAVIFileSynth::Release() gRefCnt=1, m_refs=1

warning: 000381E8->CAVIFileSynth::QueryInterface() {00020025-0000-0000-c000-0000
00000046} (unsupported!)

warning: 000381E8->CAVIFileSynth::QueryInterface() {0000010b-0000-0000-c000-0000
00000046} (IPersistFile)

warning: 000381E8->CAVIFileSynth::AddRef() gRefCnt=2, m_refs=2

warning: 000381E8->CAVIFileSynth::QueryInterface() {00020020-0000-0000-c000-0000
00000046} (IAVIFile)

warning: 000381E8->CAVIFileSynth::AddRef() gRefCnt=3, m_refs=3

warning: 000381E8->CAVIFileSynth::Load("c:\\temp\\x264\\sample.avs", 0x0)

warning: 000381E8->CAVIFileSynth::Release() gRefCnt=2, m_refs=2

warning: 000381E8->CAVIFileSynth::Release() gRefCnt=1, m_refs=1

warning: 000381E8->CAVIFileSynth::GetStream(*, 73646976(vids), 0)

dbxread.c:1336: internal-error: Section index is uninitialized
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

[Kurtnoise]

Error: dll starting at 0x77d40000 not found.
Error while mapping shared library sections:
NOT_AN_IMAGE: No such file or directory.
Error while mapping shared library sections:
C:\WINDOWS\SysWOW64\ntdll32.dll: No such file or directory.

[burfadel]

There is no ntdll32.dll file in Vista x64 or XP x64! - that explains this line in your output above:

C:\WINDOWS\SysWOW64\ntdll32.dll: No such file or directory.

[Kurtnoise]

edit2. No it's not. It's the resolution making it crash.

width of 960 and under works
962 = unsupported input format
964 = crash.
mmmh, width>=960 works for me...:D

c:\tmp\x264-r1058>x264.exe --crf 22 --me esa --progress -o "E:\HD\t1.h264" "E:\H
D\Vc1.avs"
avis [info]: 1920x800 @ 23.98 fps (2001 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 PHADD SSE4.1 Cache64
x264 [info]: profile Main, level 4.0
x264 [info]: slice I:16 Avg QP:16.30 size:114738 PSNR Mean Y:46.93 U:51.53
V:52.23 Avg:48.03 Global:47.84
x264 [info]: slice P:1985 Avg QP:19.59 size: 32387 PSNR Mean Y:44.16 U:49.33
V:50.11 Avg:45.35 Global:45.09
x264 [info]: mb I I16..4: 30.4% 0.0% 69.6%
x264 [info]: mb P I16..4: 1.2% 0.0% 1.3% P16..4: 56.7% 16.6% 10.2% 0.0% 0
.0% skip:13.9%
x264 [info]: SSIM Mean Y:0.9737218
x264 [info]: PSNR Mean Y:44.184 U:49.347 V:50.123 Avg:45.369 Global:45.105 kb/s:
6338.38

encoded 2001 frames, 1.94 fps, 6338.49 kb/s

http://pix.nofrag.com/6/b/c/176548141bfff13a98501d6a10438t.jpg (http://pix.nofrag.com/6/b/c/176548141bfff13a98501d6a10438.html)

using your build...

[bob0r]

--frames 50 --crf 24 --me esa (or --me tesa) = crash

From the MAKEFILE:
--crf 22 -b3 -m7 -r4 --me esa -8 -t2 -A all --mixed-refs = no crash
--frames 50 --crf 24 -b3 -m9 -r3 --me tesa -8 -t1 --mixed-refs = crash

We shall wait for the mighty penguin to solve this issue...

[kemuri-_9]

i only bothered to compile the x64 version with my usual patches and it fprofiled just fine <_<

also tossed it a 2120x1200 avs script and it ran esa and tesa just fine

if it's crashing at the end it's likely crashing while freeing memory on the encoder close/cleanup calls.
if it's indeed this case, then the resulting encode would be just fine.

Edit:
tried an x86 build and confirmed the crash

Program received signal SIGTRAP, Trace/breakpoint trap.
0x7d61002e in ?? ()
warning: HEAP[x264_debug.exe]:
warning: Heap block at 024EA610 modified at 02502C2C past requested size of 18614

[LoRd_MuldeR]

Error: dll starting at 0x77d40000 not found.
Error while mapping shared library sections:
NOT_AN_IMAGE: No such file or directory.
Error while mapping shared library sections:
C:\WINDOWS\SysWOW64\ntdll32.dll: No such file or directory.


But the file is there for sure:

http://img391.imageshack.us/img391/3773/ntdllqf1.th.png (http://img391.imageshack.us/img391/3773/ntdllqf1.png)

I doubt Windows would even boot up, if the "native" API (ntdll.dll) was missing. Nor would any application work :p

So there must be another problem. I got no idea what though...

[video_magic]

It says ntdll32 not just ntdll

[LoRd_MuldeR]

It says ntdll32 not just ntdll

Your are absolutely right :o

[Audionut]

x264-r1058-clean.rar (http://rapidshare.com/files/176381226/x264-r1058-clean.rar)

No patches.

Seems to be working fine.

[Sharktooth]

bobor's build (x264.nl) is "clean" too, but still crashes.

[LoRd_MuldeR]

Any comment on that crash from the x264 gurus yet? :confused:

[Dark Shikari]

Any comment on that crash from the x264 gurus yet? :confused:worksforme

[LoRd_MuldeR]

worksforme

Well, obviously something was broken between r1057 and r1058. Various people can reproduce the crash. Nobody is going the investigate this?

I could give a more detailed error report, if GDB wouldn't fail with "C:\WINDOWS\SysWOW64\ntdll32.dll: No such file or directory." when I try to debug the build :rolleyes:

[kemuri-_9]

it might be limited to x86 windows builds, as everyone here has reported problems with x86 mingw builds...
i've gotten x64 to work fine.


Program received signal SIGTRAP, Trace/breakpoint trap.
0x7d61002e in strchr () from C:\WINDOWS\SysWOW64\ntdll32.dll
warning: HEAP[x264.exe]:
warning: Heap block at 0243A318 modified at 02452937 past requested size of 18617

bt full
#0 0x7d61002e in strchr () from C:\WINDOWS\SysWOW64\ntdll32.dll
No symbol table info available.
#1 0x7d6820f9 in ntdll!LdrAccessOutOfProcessResource ()
from C:\WINDOWS\SysWOW64\ntdll32.dll
No symbol table info available.
#2 0x0022f618 in ?? ()
No symbol table info available.
#3 0x7d66e7ec in ntdll!RtlpNtEnumerateSubKey ()
from C:\WINDOWS\SysWOW64\ntdll32.dll
No symbol table info available.
#4 0x0243a318 in ?? ()
No symbol table info available.
#5 0x0243a318 in ?? ()
No symbol table info available.
#6 0x003f0000 in ?? ()
No symbol table info available.
#7 0x0243a318 in ?? ()
No symbol table info available.
#8 0x0022f62c in ?? ()
No symbol table info available.
#9 0x7d659d2e in ntdll!LdrGetDllHandleEx ()
from C:\WINDOWS\SysWOW64\ntdll32.dll
No symbol table info available.
#10 0x00000000 in ?? ()
No symbol table info available.


and msvc (to confirm that's it not just specific to mingw):
http://kemuri9.net/forumpics/x264_r1058.png
'retrying' it, pulls up

retval = HeapFree(_crtheap, 0, pBlock);

as the problem, from free()

[LoRd_MuldeR]

But why ntdll32.dll, when x264.exe is not even linked against that DLL ???

The debugger is right: There is no ntdll32.dll in my "SysWOW64" folder, nor in my "System32" folder. But x264.exe doesn't need/use that DLL, verified by Dependency Walker.

It indirectly requires ntdll.dll, because it's linked to MSVCRT.dll, which is linked against ntdll.dll. But there's certainly no ntdll32.dll in the dependency tree...

http://img187.imageshack.us/img187/6974/x264dependsgw8.th.png (http://img187.imageshack.us/img187/6974/x264dependsgw8.png)

Is ntdll32.dll an alias name for the 32-Bit version of ntdll.dll? And if so, why it doesn't work for GDB anymore all of a sudden? :confused:

[Dark Shikari]

How about you debug on a sane operating system then? :rolleyes:

[LoRd_MuldeR]

How about you debug on a sane operating system then? :rolleyes:

If you don't consider Windows XP sane, what shall I use? :p

Note that debugging with GDB always worked 100% fine up to build r1058, so the must be something "strange" with that one. It's not like I'm trying to debug for the first time.

And no, I didn't change the OS, the GCC version or the GDB version recently...


Anyways. Since kemuri-_9 tracked the problem down to "retval = HeapFree(_crtheap, 0, pBlock);", is there a chance for a fix or a workaround at least? :o

[Dark Shikari]

Anyways. Since kemuri-_9 tracked the problem down to "retval = HeapFree(_crtheap, 0, pBlock);", is there a chance for a fix or a workaround at least? :oHow can you "track down" a problem to code that doesn't even exist?

xeelee x264_commit_repo
$ grep -r "HeapFree" *

xeelee x264_commit_repo
$

[LoRd_MuldeR]

How can you "track down" a problem to code that doesn't even exist?

xeelee x264_commit_repo
$ grep -r "HeapFree" *

xeelee x264_commit_repo
$

I hope kemuri-_9 can answer where he got this code from :)

[squid_80]

A quick poke at google seems to indicate gdb has issues with XP64 (http://cygwin.com/ml/cygwin/2007-10/msg00179.html). But I don't think the ntdll32 problem is making it crash on you, since it continues to spit out all the avisynth debug info.

[kemuri-_9]

Anyways. Since kemuri-_9 tracked the problem down to "retval = HeapFree(_crtheap, 0, pBlock);", is there a chance for a fix or a workaround at least? :o

i stated that the code was from free.c, where the definition of free is.

free is crashing due to the heap violation that x264 is apparently performing.

so according to the error stated by both gdb and msvc, x264 is editing memory beyond its requested allocation in the latest revision.

are the linux builds not exhibiting the problem?
if only windows had a decent and relatively cheap/free equivalent of valgrind, nailing this down would be easier.

btw, i just symlinked C:\Windows\sysWOW64\ntdll32.dll to C:\Windows\sysWOW64\ntdll.dll (copying would suffice as well) to solve the gdb problem.

[Dark Shikari]

i stated that the code was from free.c, where the definition of free is.

free is crashing due to the heap violation that x264 is apparently performing.

so according to the error stated by both gdb and msvc, x264 is editing memory beyond its requested allocation in the latest revision.If x264 edited memory beyond what it allocated, there would be an instant segfault, not a free() crash.

[kemuri-_9]

i'm not an expert at using at msvc as a debugger, but i did spot this:
http://kemuri9.net/forumpics/x264_r1058_2.png

showing that free is being called and crashing due to a heap corruption
(well, this doesn't show the heap corruption part, but the code it's pointing to is throwing the actual heap corruption window box)

Edit:
If i'm reading this correctly,
it appears to be crashing on:

for( i = 0; i < 4; i++ )
x264_free( frame->buffer[i] );

[bob0r]

Why are we all, all of a sudden pretending Windows never needed fixing before and now it has made a mistake, we aren't allowed to even backtrace together with the developers help?

Aren't there like plenty of work-arounds for GCC and/or Windows issues?

I offered my help 3x, and 3x i was ignored, i know i am annoying at most times, but i also know i am way too dumb to know exactly what commands to time for the correct info.


I hear some "company whispering".....


Again: http://x264.nl/gdb.1058.txt what more shall/can i do to help?

[Dark Shikari]

Why are we all, all of a sudden pretending Windows never needed fixing before and now it has made a mistake, we aren't allowed to even backtrace together with the developers help?No, I'm saying that if you have the choice between a debugging environment that does work, and one that doesn't, why the hell would you insist on the one that doesn't when you could do the debugging far more easily on the one that does work?

I don't understand the reason why people spend hours and hours trying to get a Windows gdb to work when it clearly isn't--when they could just boot up Linux and send me a proper backtrace and disass from the crash and stop whining.

[bob0r]

If you just said to me: "jarod, Windows gdb is bugged, it can't be used for a proper debug backtrace."
Thats all i needed to know, in fact i didn't even know before i read: :stupid:

I would have said okay, then lets wait for someone with linux who might help, even though the problem might be Windows related.

If there is nothing I can do, then all i can do is wait (hmm that a weird sentence :D)

[Dark Shikari]

If you just said to me: "jarod, Windows gdb is bugged, it can't be used for a proper debug backtrace."No, I said to you on IRC half a dozen times that I wanted a disass, but I still don't have a disass from you, so I made the assumption that you are incapable of making one.

[kemuri-_9]

here's one from a debian server i rent out:
gdb bt (http://kemuri9.net/dev/x264/r1058_gdb.bt.txt)

[MasterNobody]

Dark Shikari
Something wrong with decrease of buffer[3] size in http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=a4ec1020efb1a2a6757f8f891d78c2dd9344bb91 when there is no p4x4. I think somewhere in x264_frame_filter there is writes out of allocated memory block (and it writes out of range also without asm).

There is no crash if I return "*2" instead of "<< h->frames.b_have_sub8x8_esa"

[Likewise]

> If x264 edited memory beyond what it allocated, there would be an instant segfault, not a free() crash.

Only if it reaches into a next page boundary for dynamically allocated memory, with pages typically 4096 bytes for most Linux platforms.

Please correct me if I'm mistaken.

Leon.

[LoRd_MuldeR]

There is no crash if I return "*2" instead of "<< h->frames.b_have_sub8x8_esa"

Interesting. Could you kindly provide a patch? :thanks:

[bob0r]

> If x264 edited memory beyond what it allocated, there would be an instant segfault, not a free() crash.

Only if it reaches into a next page boundary for dynamically allocated memory, with pages typically 4096 bytes for most Linux platforms.

Please correct me if I'm mistaken.

Leon.


Likewise
Registered User


Join Date: Jun 2006
Posts: 1




It's ALIIIIIVE!! (MERRY X-MAS! :D)
Likewise must be pengvado's third half.

[MasterNobody]

Interesting. Could you kindly provide a patch? :thanks:

I think this would be more correct than increasing size of buffer[3]: http://stashbox.org/337696/x264_fix_esa_crash.diff

[LoRd_MuldeR]

I think this would be more correct than increasing size of buffer[3]: http://stashbox.org/337696/x264_fix_esa_crash.diff

That fixes the crash for me :)

:goodpost:

[Audionut]

x264-r1060.rar (http://rapidshare.com/files/176544392/x264-r1060.rar)

Patched with,
x264_custom_strtok_r.r1038.diff
x264_debug_defines.r1038.diff
x264_fix_stats_file_work.r1038.diff
x264_multithreading_bug_check.r1038.diff
x264_error_memoryleaks.03.r1038.diff
x264_thread_pool.r1038.diff
x264_thread_priority_with_pool.02.diff
x264_Cosmetic.02.diff
x264_log_file.03k.diff
x264_hrd_pulldown.09_interlace.diff
x264_single_frame_flash.diff
x264_mingw_aligned_03.diff
x264_fix_esa_crash.diff

[video_magic]

Thanks as always for the build audionut (I assume that it is still as before one of your P4 Prescott optimised builds right?) :)

Just a bit 'concerned' at the large patch list - I've read some of the latest previous comments, and wonder if I'm supposed to leave any Windows builds for a while until something is resolved (to make x264 work probably reliably under Windows?), I don't know the technicalities but because I'm archiving I have to wonder - what is the chances of this problem that the builders and developers are mentioning, affecting the output (on WinXP SP2 +some security updates), if at all?

PS. audionut: re: the PMs. My board seems to be such an unstable P.O.S. that I am so distraught after some moths wasted, no overclocking or anything will be sensible now, because having tracked down and resolved so many problems and settings related to encoding to X264 from VHS captues, (over the last several months) the usual (and final remaining) problem, is 'interference lines' in the captured video on any BIOS or other setting, with any capture codec. It seems to be because of having a VIA chipset and the effect on the PCI bus :( :( After all this time I am so upset that. I will get an Intel chipset based board for my Intel SL9KF P4.

When I do finally get every last remaining problem squished, I just want to know that the X264 build is going to be alright (as in generally safe) for H.264 output, and also fairly well optimised for the encoding speed. Thanks and praise as always to the developers and builders for what seems like a great codec. I just wondered regarding the last few posts and this quite long patch-list for this build.

Thanks for any advice as always guys, it's really appreciated.

[Adub]

Holy crap, I haven't looked at this thread in a while, and I just glanced at Audionut's build. How many freakin' patches do we have/need now?

[LoRd_MuldeR]

Holy crap, I haven't looked at this thread in a while, and I just glanced at Audionut's build. How many freakin' patches do we have/need now?

x264_fix_esa_crash.diff - workaround to avoid a crash with "Exhaustive Search" introduced in r1057
x264_hrd_pulldown.09_interlace.diff - required only for Blu-Ray compatibility
x264_custom_strtok_r.r1038.diff - fixes a problem with the parsing of custom zones on Windows
x264_single_frame_flash.diff - don't detect single "flash frames" as scene changes
x264_thread_pool.r1038.diff - use a pool of threads (http://en.wikipedia.org/wiki/Thread_pool_pattern) instead of creating new threads all the time

Decide which of these you need. No idea what all the other patches do ;)

[Audionut]

It's simply a build I did for myself with a patch or 2 or 3. And thought I would share it.

x264 only really needs the ESA patch atm.
Personally I don't use the HRD patch, but most seem to want it.

[Audionut]

No idea what all the other patches do ;)

x264_thread_priority_with_pool.02.diff - Change the priority of threads and thread-input

x264_debug_defines.r1038.diff
x264_fix_stats_file_work.r1038.diff
x264_multithreading_bug_check.r1038.diff
x264_error_memoryleaks.03.r1038.diff

All needed to get thread-pool to patch. Cause I ain't clever enough to fix the patches myself.

x264_log_file.03k.diff - Have x264 generate a log file - (Log-file level information (-1=NONE,0=ERROR,1=WARNING,2=INFO,3=DEBUG) [2] )
x264_mingw_aligned_03.diff - extra aligned memory allocation methods for mingw http://forum.doom9.org/showthread.php?p=1217760#post1217760

[Dark Shikari]

I just wondered regarding the last few posts and this quite long patch-list for this buildGenerally there are reasons why patches aren't in git.

x264_debug_defines.r1038.diffThis is a useless patch.
x264_multithreading_bug_check.r1038.diffThe only purpose of this patch is to fix a bug in the above useless patch.
x264_fix_stats_file_work.r1038.diffI don't even know what this one does.
x264_error_memoryleaks.03.r1038.diffThis one explicitly isn't being committed because its author still hasn't brought it up to spec according to akupenguin's guidelines. This means it should not be included in builds.
x264_thread_pool.r1038.diff
x264_thread_priority_with_pool.02.diffThread pool, last I checked, had nearly no effect on speed except on dual core systems, where it slowed things down.
x264_Cosmetic.02.diffWhy the heck do people include cosmetic patches in public builds? The entire definition of a cosmetic change is one that doesn't modify the output binary!
x264_mingw_aligned_03.diffI see no benefit to this patch.
x264_fix_esa_crash.diffalready committed...

[LoRd_MuldeR]

already committed...

:thanks:

[Audionut]

already committed...

It wasn't before I did my build.

I seen an improvement with the thread priority patch.
Any chance someone could fix this patch to work on it's own.

[MasterNobody]

x264_error_memoryleaks.03.r1038.diffThis one explicitly isn't being committed because its author still hasn't brought it up to spec according to akupenguin's guidelines. This means it should not be included in builds.
Can you show me his guidelines? The only guidelines about this patch was here (http://mailman.videolan.org/pipermail/x264-devel/2008-September/004876.html) and I used it in the version 02 (next post in mailing list). In version 03 I only include fix for incorrect memory allocation of 'z->param' in 'parse_zone'.
x264_error_memoryleaks.03.r1038.diff
Thread pool, last I checked, had nearly no effect on speed except on dual core systems, where it slowed things down.Probably, this is because "--thread-queue == --threads" by default (and not "--threads * 2" which was in original patch which I use as base) and I change this only to make output binary identical to GIT-version.

[MasterNobody]

x264_debug_defines.r1038.diff
x264_fix_stats_file_work.r1038.diff
x264_multithreading_bug_check.r1038.diff
x264_error_memoryleaks.03.r1038.diff

All needed to get thread-pool to patch. Cause I ain't clever enough to fix the patches myself.
May be you are trying to use incorrect version of patch (which I made for my batch). There is version of this patch which can be applied alone: x264_thread_pool.r1038.diff (http://komisar.gin.by/x.patch/BugMaster/20081126/independent/x264_thread_pool.r1038.diff)

[Audionut]

edit: My bad I only looked that it was on Komisar's site.

Yes that does patch fine.

[skystrife]

reasons for the crash could be one of the following:
1. it might be crashing due to the mingw aligned patch, since the function names are different for mingw x64.*1

2. the win zone patch also includes a memory allocation change since 03,
this change is meant to fix possible incorrect allocations, which could rear it's ugly head in data manipulation and when freeing the data which would result in seg faults.
the strtok_r patch does not include the supposed memory allocation fix, as it's never crashed for me in mingw builds, only in msvc builds.

*1
I'm holding on releasing the updated patch, since I'm not sure what's going on with mingw x64 having the necessary aligned memory prototypes commented out in the header file.
(options are that the methods are not implemented or not needed, but i'm not exactly sure which one it is - current patch assumes the latter)

you can try out my build listed in the win x64 support thread to see if it proceeds to crash so i can determine if the patches are ok to release or need some working.

The x64 crash is unrelated to the mingw aligned patch; the git head patched with the custom strtok_r patch will crash at the encode's completion. My current patch set is crash-free on my end.

------------------------------------------------

x264.1061M.exe (http://www.mediafire.com/?qtnktwmqleg) - Alternate Download (http://skystrife.com/x264/x264.1061M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_mingw_aligned_03.diff
x264_mingw_check_strtok_r.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

-----------------------------------------------

x264.1061M.x64.exe (http://www.mediafire.com/?3gj0mmk0kn2) - Alternate Download (http://skystrife.com/x264/x264.1061M.x64.exe)

Patches used:
x264_win64_support.01.r1057.diff
x264_win_zone_parse_fix_04.diff
x264_mingw_aligned_03.diff
x264_hrd_pulldown.09_interlace.diff

gcc 4.4.0 fprofiled build.

[Audionut]

x264-r1061.rar (http://rapidshare.com/files/176590330/x264-r1061.rar)

Patched with,
x264_custom_strtok_r.r1038.diff
x264_fix_stats_file_work.r1038.diff
x264_error_memoryleaks.03.r1038.diff
x264_thread_pool.r1038.diff
x264_thread_priority_with_pool.02.diff
x264_log_file.03k.diff
x264_hrd_pulldown.09_interlace.diff
x264_single_frame_flash.diff
x264_mingw_aligned_03.diff

[kemuri-_9]

x264_mingw_aligned_03.diff
I see no benefit to this patch.

this is a patch that uses mingw built in aligned memory allocation methods instead of letting x264 do it's hand-aligning.

on the average there's a fairly small performance increase...
(i've mostly seen it personally get a 0.3 - 0.8% speed increase)

the latest version is here (http://kemuri9.net/dev/x264/patches/x264_mingw_aligned_04.diff)

[bob0r]

Woohoo Santa Penguin to the resque!
Thanks MasterNobody for making him change a numer! :cool:

[Dark Shikari]

this is a patch that uses mingw built in aligned memory allocation methods instead of letting x264 do it's hand-aligning.

on the average there's a fairly small performance increase...
(i've mostly seen it personally get a 0.3 - 0.8% speed increase)But you have yet to explain why it gives any performance increase--since x264 spends an absolutely negligable amount of time in x264_malloc, and you can't speed up the program by optimizing a function that is almost never called.

We don't commit voodoo patches.

[kemuri-_9]

all i can think of is that the built in aligned free, malloc, and realloc methods are optimized in some way over the x264's custom aligning methods.

the patch affects the x264_malloc, x264_free, and x264_realloc methods.

best i could do is write up some small program that does a huge number of x264_malloc, x264_realloc, and x264_free calls to dramaticize the time differences w/ + w/o the patch.

but i guess that's only if you find it worth the time

[Dark Shikari]

all i can think of is that the built in aligned free, malloc, and realloc methods are optimized in some way over the x264's custom aligning methods.If a function uses X% of total program runtime, you cannot gain more than X% performance by optimizing that function.

[LoRd_MuldeR]

Given that the global memory state is identical and that we want to allocate the same number of bytes, will x264_malloc() and the "native" malloc() return a pointer to the very same memory address ???

If not, this may indirectly effect the performance of other functions - functions that called far more often than the malloc/free functions...

[kemuri-_9]

since when has any malloc been guaranteed to return the same memory address?

the point of the aligning is that the memory is allocated on a 16byte boundary.

i'll get working on some counts of the mem calls sometime soon to start getting some performance values...

[LoRd_MuldeR]

since when has any malloc been guaranteed to return the same memory address?

Well, unless malloc() uses a pseudorandom number generator, it should always allocate the same memory range and return a pointer to the same address, given that you call it at the same point of program execution and given that you allocate the same number of bits. Of course this won't be possible, if your program has some indeterminism due to multi-threading...

the point of the aligning is that the memory is allocated on a 16byte boundary.

Yes, I know. However if different malloc() implementations return different addresses, this may effect the performance of other functions, which use the allocated memory. For example one malloc() implementation may implicitly trigger more/less page faults than another implementation. This is just speculation, of course...

[kemuri-_9]

well, anyways, have some more reliable numbers now:

first, time to see how many times x264_malloc and x264_free were called to get a basis of performance,
running 1000 frames of my 640x480 y4m on 4 threads:

memory calls
x264_malloc: 6067338; x264_free: 6066330; x264_realloc: 0
memory call sizes
x264_malloc: 3247583754 total bytes

(counters were using uint32_t's and the size was using uint64_t, which were 0'd out on program start)
this gives a general idea of how many times the methods are called -> an incredibly large number of times.

and so, wrote this small C program to help with testing the differences between the x264 standard and mingw methods:
test_malloc.c (http://kemuri9.net/dev/x264/other/test_malloc.c)
and the log (http://kemuri9.net/dev/x264/other/mem_test.txt) from the shell.

so unless you want to tell me that time is bugged too, then it shows that the mingw versions are slightly faster
(x264_realloc not particularly tested due to its not particular use at runtime)

@Lord_MuldeR
malloc returns what the OS tells it to as it does request the allocation from the OS layer,
so it's never guaranteed to be the same, as other processes will affect the free physical memory address ranges.

and if the mingw methods didn't work as intended,
people who've been using the patches would have been getting heap corruptions or seg faults when trying to run x264.

[LoRd_MuldeR]

@Lord_MuldeR
malloc returns what the OS tells it to as it does request the allocation from the OS layer,
so it's never guaranteed to be the same, as other processes will affect the free physical memory address ranges.

Yes. But the allocated memory is mapped to the virtual address space of the calling process. And only the virtual address is returned, not the actual physical one. Since each process has got it's own virtual address space, which is independent of and protected from other processes, I see no reason why the allocated memory should be mapped to different locations each time - given the path of execution is identical and the same amount of memory is allocated (in the current call and in all previous calls). Also it was just a thought that different allocation strategies used by different malloc() implementations may indirectly effect the performance of other functions. That at least would be an explanation why using a different malloc() implementation effects overall performance, although the time actually spend in malloc() is negligible.

BTW: I think malloc() is not implemented in the OS Kernel, but in the C standard library. Of course it uses system calls to the OS Kernel, but different strategies can be implemented.
For example on may use a heap -or- only allocated/free entire pages. The latter has more overhead, but freed pages are returned immediately to the system.


memory calls
x264_malloc: 6067338; x264_free: 6066330; x264_realloc: 0

That sounds like a huge number indeed. But without a reference the number doesn't say much. How does it compare to other functions? :confused:

[kemuri-_9]

That sounds like a huge number indeed. But without a reference the number doesn't say much. How does it compare to other functions? :confused:

compile x264 with -fprofile-arcs and -ftest-coverage,
and use gcov to generate line hit (coverage) files (*.gcov) to see how often the lines of code are ran after executing it however many times you did.
will give you what you're looking for.

[akupenguin]

Repeated malloc is used only in ssim and esa. I will not accept any patch which optimizes malloc, because malloc shouldn't be speed-relevant. If malloc runs often enough to even be measurable, then the only proper fix is to eliminate all those excess mallocs.

[kemuri-_9]

Repeated malloc is used only in ssim and esa. I will not accept any patch which optimizes malloc, because malloc shouldn't be speed-relevant. If malloc runs often enough to even be measurable, then the only proper fix is to eliminate all those excess mallocs.

indeed, this is a more logical way of handling the situation,
but does cause more code to be rewritten...

i wrote a quick tracer and noticed that most of the x264_malloc and x264_free calls are
from ssim (2 each) and in hpel_filter (1 each) (totaling 95+% of all calls)

if the malloc/freed buffers were extracted out into more global/static ones
(as the height and width of the video never change so this is a feasible feat),
it would greatly reduce the number of calls to both.

doing this and being thread safe is a small challenge though...

[Dark Shikari]

doing this and being thread safe is a small challenge though...Put it in x264_t...

[kemuri-_9]

Put it in x264_t...

yes, i figured out that would do it since i knew each thread had an x264_t...
but since i wasn't sure of how the threading system was working exactly,
didn't know if i had to handle param calling in some special way outside of the h->{data}

but anywho...

here's a patch, it's gonna need some testing by the devs to make sure it doesn't break something by accident...

but from my quick 640x480 1000 frame encoding runs,
the calls to x264_malloc and x264_free were reduced to
default settings (w/ SSIM): < 1%
default settings + w/o SSIM: about 3%

x264_malloc_reduce.diff (http://kemuri9.net/dev/x264/patches/x264_malloc_reduce.diff)

[Dark Shikari]

Why not just use one buffer? They're never run at the same time, so you can just set the buffer equal to the larger of the two sizes.

And you should malloc in encoder.c on encoder init (same place zigzag_init, etc are called).

Edit: or, wait, you should probably malloc in the thread init.

[kemuri-_9]

Why not just use one buffer? They're never run at the same time, so you can just set the buffer equal to the larger of the two sizes.

i'm mostly just trying to get this to work first,
i should leave the tweaking to the smart guys...
though at quick inspection, most if not all of the time the ssim buffers would be larger than the hpel filter one.

And you should malloc in encoder.c on encoder init (same place zigzag_init, etc are called).

Edit: or, wait, you should probably malloc in the thread init.

x264_t *x264_encoder_open ( x264_param_t *param )
...
for( i = 0; i < h->param.i_threads; i++ )
{
/* here? */
}


if so, try #2 (http://kemuri9.net/dev/x264/patches/x264_malloc_reduce_02.diff)

Edit:
updated the patch for a small change of wrapping the ssim sum mallocs around an if
to actually see if ssim will be calculated (saving on the mallocs if not)

[Audionut]

x264-r1063.rar (http://rapidshare.com/files/178035251/x264-r1063.rar)

Patched with,
x264_custom_strtok_r.r1063.diff
x264_fix_stats_file_work.r1063.diff
x264_no_b_adapt_with_pre_scenecut.r1063.diff
x264_error_memoryleaks.03.r1063.diff
x264_thread_pool.02.r1063.diff
x264_thread_priority_with_pool.02.diff
x264_log_file.03k.diff
x264_hrd_pulldown.09_interlace.diff
x264_single_frame_flash.diff
x264_mingw_aligned_04.diff

[komisar]

Audionut, update you thread-pool patch...
x264_thread_pool.02.r1063.diff (http://komisar.gin.by/x.patch/BugMaster/20081229/independent/x264_thread_pool.02.r1063.diff)

[skystrife]

x264.1065M.exe (http://www.mediafire.com/?mhmwzenzymn) - Alternate Download (http://skystrife.com/x264/x264.1065M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix.04.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

-----------------------------------------------

x264.1065M.x64.exe (http://www.mediafire.com/?zdg1ynmgzya) - Alternate Download (http://skystrife.com/x264/x264.1065M.x64.exe)

Patches used:
x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_04.diff
x264_win64_support.01.r1065.diff (http://skystrife.com/x264/x264_win64_support.01.r1065.diff) <-- fixed patch to work with latest commits, but I know nothing as far as asm code goes, so it's highly possible I completely screwed something up. Use at your own risk.

gcc 4.4.0 fprofiled build.

(switched to using win_zone_parse_fix for sanity between the two builds).

[imk]

x264_win64_support.01.r1065.diff (http://skystrife.com/x264/x264_win64_support.01.r1065.diff) <-- fixed patch to work with latest commits, but I know nothing as far as asm code goes, so it's highly possible I completely screwed something up. Use at your own risk.

It appears to work great. Thanks. :) I was just about to updated it to work with r1065 but decided to check here first to see if someone already had. I compiled a x264 build with ICC using this patch and ran a bunch of profiling runs and all passed perfectly.

[skystrife]

x264.1066M.exe (http://www.mediafire.com/?wydmmmndm42) - Alternate Download (http://skystrife.com/x264/x264.1066M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix.04.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

-----------------------------------------------

x264.1066M.x64.exe (http://www.mediafire.com/?yyym2nmu2ik) - Alternate Download (http://skystrife.com/x264/x264.1066M.x64.exe)

Patches used:
x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_04.diff
x264_win64_support.01.r1065.diff (http://skystrife.com/x264/x264_win64_support.01.r1065.diff)

gcc 4.4.0 fprofiled build.

[skystrife]

Sorry for the double-post; just wanted to make sure the new build was found.
-----------------------------------------------
x264.1069M.exe (http://www.mediafire.com/?wjniyj2mz1x) - Alternate Download (http://skystrife.com/x264/x264.1069M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff (http://skystrife.com/x264/x264_win_zone_parse_fix_05.diff)

gcc 3.4.5 fprofiled build with -march=pentium2.
-----------------------------------------------
x264.1069M.x64.exe (http://www.mediafire.com/?tyn4kfbzymy) - Alternate Download (http://skystrife.com/x264/x264.1069M.x64.exe)

Patches used:
x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff (http://skystrife.com/x264/x264_win_zone_parse_fix_05.diff)
x264_win64_support.01.r1065.diff (http://skystrife.com/x264/x264_win64_support.01.r1065.diff)

gcc 4.4.0 fprofiled build.

For all I know something in the new LZCNT asm may need fixing for win64. I don't have a phenom here so right now it worksforme but I don't know if the new additions work properly.

[kemuri-_9]

For all I know something in the new LZCNT asm may need fixing for win64. I don't have a phenom here so right now it worksforme but I don't know if the new additions work properly.

i'm on a phenom and the win64 asm patch is still working fine.
-> checkasm is reporting no errors

[MasterNobody]

i'm on a phenom and the win64 asm patch is still working fine.
-> checkasm is reporting no errors
It doesn't mean that it fully correct because it doesn't check the safety of volatile registers (rsi, rdi, xmm6-xmm15).

P.S. Happy New Year!
P.P.S. С Новым Годом всех!

[Dark Shikari]

It doesn't mean that it fully correct because it doesn't check the safety of volatile registers (rsi, rdi, xmm6-xmm15).By the way, speaking of which, why don't you just backup/restore the volatile registers at the end of publicly accessible API functions, instead of doing so inside assembly functions? The latter seems like a waste of time, as the rest of x264's internals doesn't require the registers to be non-volatile.

[akupenguin]

By the way, speaking of which, why don't you just backup/restore the volatile registers at the end of publicly accessible API functions, instead of doing so inside assembly functions?
And disable autovectorization. And somehow make sure the compiler doesn't try to store float variables in xmmregs across an asm function call. This is not entirely covered by the mmx/emms separation needed by x86_32, since fpregs are caller-saved so only math and not storage is affected there.
But yes, if you can make it work, anything to better approximate the unix abi will improve performance.

[Audionut]

x264-r1070.rar (http://rapidshare.com/files/179026793/x264-r1070.rar)


Patched with,
x264_custom_strtok_r.r1063.diff
x264_no_b_adapt_with_pre_scenecut.r1063.diff
x264_thread_pool.02.r1063.diff
x264_thread_priority_with_pool.02.diff
x264_hrd_pulldown.09_interlace.diff
x264_single_frame_flash.diff

[Snowknight26]

Who removed the previous commit that fixed some C99ism?

[kemuri-_9]

Who removed the previous commit that fixed some C99ism?

akupenguin did
it was mostly in there to keep MSVC support.
akupenguin no longer cares to maintain MSVC support, so for the time being it's dropped.

see x264-devel email (http://mailman.videolan.org/pipermail/x264-devel/2009-January/005344.html)

[skystrife]

x264.1074M.exe (http://www.mediafire.com/?mje5nwe14lt) - Alternate Download (http://skystrife.com/x264/x264.1074M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff (http://skystrife.com/x264/x264_win_zone_parse_fix_05.diff)

gcc 3.4.5 fprofiled build with -march=pentium2.
-----------------------------------------------
x264.1074M.x64.exe (http://www.mediafire.com/?mwyynnnjjqx) - Alternate Download (http://skystrife.com/x264/x264.1074M.x64.exe)

Patches used:
x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff (http://skystrife.com/x264/x264_win_zone_parse_fix_05.diff)
x264_win64_support.01.r1065.diff (http://skystrife.com/x264/x264_win64_support.01.r1065.diff)

gcc 4.4.0 fprofiled build.

[Snowknight26]

Thanks for the continual x64 builds skystrife.

[Sharktooth]

thanks from me too.
as always, i continue to link them in a more visible thread (https://forum.doom9.org/showthread.php?t=89979) ;)

[Atak_Snajpera]

as always, i continue to link them in a more visible thread
You should add x64 version as well.

[Sharktooth]

done.

[TL0]

How can I tell if I had a problem with this regression?

- Fix regression in r1066
With some combinations of video width and other settings, the scratch buffer was slightly too small.
This caused heap corruption on some systems.


did this cause crashing or corruption in output video?

[Sharktooth]

usually it was a crash.

[Dark Shikari]

Crash, and only after encoding generally, as modifying memory data just barely outside of a malloc usually results in heap corruption, not a segfault.

[ajp_anton]

Explains why, when I batch-encoded a few 100 short clips a week ago, when I went to visit the encoding computer it would randomly have crashed after (successfully) encoding a clip and needed a manual "OK, move on" =)

[skystrife]

x264.1077M.exe (http://www.mediafire.com/?ajqz4ettgam) - Alternate Download (http://skystrife.com/x264/x264.1077M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff (http://skystrife.com/x264/x264_win_zone_parse_fix_05.diff)

gcc 3.4.5 fprofiled build with -march=pentium2.
-----------------------------------------------
x264.1077M.x64.exe (http://www.mediafire.com/?2ahygyjd1zn) - Alternate Download (http://skystrife.com/x264/x264.1077M.x64.exe)

Patches used:
x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff (http://skystrife.com/x264/x264_win_zone_parse_fix_05.diff)
x264_win64_support.01.r1065.diff (http://skystrife.com/x264/x264_win64_support.01.r1065.diff)

gcc 4.4.0 fprofiled build.

[Audionut]

x264-r1077.7z (http://rapidshare.com/files/183042373/x264-r1077.7z)


Patched with,
x264_custom_strtok_r.r1074.diff
x264_fix_stats_file_work.r1074.diff
x264_multithreading_bug_check.r1074.diff
x264_no_b_adapt_with_pre_scenecut.r1074.diff
x264_bm_error_memoryleaks.04.r1074.diff
x264_bm_thread_pool.02.r1074.diff
x264_thread_priority_with_pool.02.diff
x264_log_file.03k.diff
x264_hrd_pulldown.09_interlace.diff
x264_single_frame_flash.diff

[roozhou]

Hey, r1077 does not compile with MSVC since the linker fails to link log2f. Can anyone fix this or just tell me in which library I can link to log2f?

[Gabriel_Bouvigne]

#define log2f(a) (logf(a)/logf(2))

[akupenguin]

And r1076 does compile in MSVC? I though I broke MSVC in r1066.

[Dark Shikari]

And r1065 does compile in MSVC? I thought I broke MSVC in r1060.

[roozhou]

#define log2f(a) (logf(a)/logf(2))
Thanks, now it compiles ok.
And this should run faster.

Index: common/osdep.h
===================================================================
--- common/osdep.h
+++ common/osdep.h
@@ -58,6 +58,7 @@
#endif
#if defined(_MSC_VER) || defined(SYS_SunOS) || defined(SYS_MACOSX)
#define sqrtf sqrt
+#define log2f(x) (logf(x)/1.44269504088896340736f)
#endif
#ifdef _WIN32
#define rename(src,dst) (unlink(dst), rename(src,dst)) // POSIX says that rename() removes the destination, but win32 doesn't.

[Atak_Snajpera]

+#define log2f(x) (logf(x)/1.44269504088896340736f)
I would use multiplication

+#define log2f(x) (logf(x)*0.69314718055994530941f)

[Dark Shikari]

I would use multiplicationNot as if it matters, as this code is only run 16384 times for each QP at most. If anybody cared, I would have made a LUT.

[techouse]

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

Applied patches (current versions):


x264_hrd_pulldown.09_interlace.diff

x264_win_zone_parse_fix_05.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 January 15th 2009, 12:44:54 CET with GCC-4.3.2 on Windows Vista Business SP-1 64-bit.

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

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

[roozhou]

Not as if it matters, as this code is only run 16384 times for each QP at most. If anybody cared, I would have made a LUT.

Will you define them as constants(64k larger executable) or calcultate them at run-time?

[Dark Shikari]

Will you define them as constants(64k larger executable) or calcultate them at run-time?Runtime, of course. No point in wasting executable size calculating a huge table.

[skystrife]

x264.1088M.exe (http://www.mediafire.com/?zoiryjtrikf) - Alternate Download (http://skystrife.com/x264/x264.1088M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff (http://skystrife.com/x264/x264_win_zone_parse_fix_05.diff)

gcc 3.4.5 fprofiled build with -march=pentium2.
-----------------------------------------------
x264.1088M.x64.exe (http://www.mediafire.com/?xjdmzzwtte0) - Alternate Download (http://skystrife.com/x264/x264.1088M.x64.exe)

Patches used:
x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff (http://skystrife.com/x264/x264_win_zone_parse_fix_05.diff)
x264_win64_support.02.r1077.diff

gcc 4.4.0 fprofiled build.

[Mr VacBob]

Thanks, now it compiles ok.
And this should run faster.

The compiler is (probably) capable of this.

[CruNcher]

No one did a build yet with DaKaz threaded slice and lookahead patch ?
i mean forget most other patches since a long time those are the most important ones :)

[Audionut]

So, I spoke too soon - Dark Shikari was able to break the patch on his first try :( Turns out that in b-adapt 2 mode, the slice type decide process takes too long, and all threads enter a deadlock state. To fix this, I am going to have to put the main x264_encoder_encode process into its own thread.... stay tuned.

DaKaZ


Perhaps it's better to wait a little while, don't you think!!

[kemuri-_9]

No one did a build yet with DaKaz threaded slice and lookahead patch ?
i mean forget most other patches since a long time those are the most important ones :)

it's not finished yet...
A. Dark_Shikari broke it on the first try. (as previously mentioned above)
B. they were working on it this morning in the chan and

[11:28] <DaKaZ> I just successfully ran an encode with b-adpat 2 and lookahead ;)
[11:28] <DaKaZ> let me test a little more
[11:31] <DaKaZ> pengvado - thanks for the help... I think we have it!
[11:32] <DaKaZ> damn... seg fault :(


so it's still broken.
this patch is one of the patches that akupenguin/pengvado and Dark_Shikari are looking forward to the most... (the other being holger's)
it'll make the repository once it's tested to be safe.

[CruNcher]

Thx for the info kemuri-9 read the logs now and also DaKaz replied, great stuff if it finally makes it's way into x264 also holgers optimizations of course :)

[Audionut]

x264-r1090.7z (http://rapidshare.com/files/190455492/x264-r1090.7z)

Patched with,
x264_custom_strtok_r.r1089.diff
x264_fix_stats_file_work.r1089.diff
x264_multithreading_bug_check.r1089.diff
x264_no_b_adapt_with_pre_scenecut.r1089.diff
x264_bm_error_memoryleaks.04.r1089.diff
x264_bm_thread_pool.02.r1089.diff
x264_thread_priority_with_pool.02.diff
x264_log_file.03k.diff
x264_hrd_pulldown.09_interlace.diff

[skystrife]

x264.1093M.exe (http://www.mediafire.com/?yzywnyrhzgz) - Alternate Download (http://skystrife.com/x264/x264.1093M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff (http://skystrife.com/x264/x264_win_zone_parse_fix_05.diff)

gcc 3.4.5 fprofiled build with -march=pentium2.
-----------------------------------------------

x264.1094M.x64.exe (http://skystrife.com/x264/x264.1094M.x64.exe)

Patches used:
x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff
x264_win64_support.06.r1093.diff

gcc 4.4.0 fprofiled build.

^-- Provided tentatively. fprofiling with two videos works fine, but with my usual three creates a bad build. There may still be bugs existent in this build--use at your own risk. (fprofiled with two videos, see Win64 x264 thread for more info)

[techouse]

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

Applied patches (current versions):


x264_hrd_pulldown.09_interlace.diff

x264_win_zone_parse_fix_05.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 February 2nd 2009, 17:18:03 CET with GCC-4.3.2 on Windows Vista Business SP-1 64-bit.

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

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

[techouse]

x264_x86_r1101_techouse (http://techouse.digitalpulse.us/builds/x264_x86_r1101_techouse.7z)
Source: x264 r1101 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):


x264_hrd_pulldown.09_interlace.diff

x264_win_zone_parse_fix_05.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 February 5th 2009, 22:48:17 CET with GCC-4.3.2 on Windows Vista Business SP-1 64-bit.

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

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

[ACrowley]

Ive the Feeling that the latest builds are little bit slower on my Quadcore Q6600 ? CPU Load in 2nd Pass is not mostly around 100%.
But i had full CPU Laod on all Coreas withg a bit older builds ?

[Audionut]

CPU load means nothing.

Don't rely on it, or your feeling. Measure it with some benchmarks.

[Sharktooth]

request: skystrife's updated builds ;)

[Audionut]

Can anyone help me to get configure working with the changes Loren made here http://git.videolan.org/?p=x264.git;a=commit;h=1df50b9287c83d5443d19482345b6842b78081c3

edit: how to get make to work in cygwin?

[kemuri-_9]

Can anyone help me to get configure working with the changes Loren made here http://git.videolan.org/?p=x264.git;a=commit;h=1df50b9287c83d5443d19482345b6842b78081c3

edit: how to get make to work in cygwin?

doesn't cygwin already have bash?
but either way, can always join #x264 on irc.freenode.net for help.

request: skystrife's updated builds ;)
until the win64 patch is updated again, can only get up to r1100 working in x64. (r1101 broke it).

[skystrife]

x264.1101M.exe (http://www.mediafire.com/?dejo1zijm2b) - Alternate Download (http://skystrife.com/x264/x264.1101M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff

gcc 3.4.5 fprofiled build with -march=pentium2.
-----------------------------------------------

x264.1100M.x64.exe (http://www.mediafire.com/?dhmz4undgyw) - Alternate Download (http://skystrife.com/x264/x264.1100M.x64.exe)

Patches used:
x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff
x264_win64_support.06.r1093.diff

gcc 4.3.4 fprofiled build.

[Audionut]

http://komisar.gin.by/x.patch/BugMaster/x264_win64_support.07.r1096.diff

[kemuri-_9]

http://komisar.gin.by/x.patch/BugMaster/x264_win64_support.07.r1096.diff

Edit:
there's a newer win64 patch than that:
http://stashbox.org/392450/x264_win64_support.08.r1101.diff

[MasterNobody]

indeed that is the correct latest patch, since ver 06 broke with the asm additions with revision 1096.
The latest is x264_win64_support.08.r1101.diff (http://komisar.gin.by/x.patch/BugMaster/x264_win64_support.08.r1101.diff)

[kemuri-_9]

The latest is x264_win64_support.08.r1101.diff (http://komisar.gin.by/x.patch/BugMaster/x264_win64_support.08.r1101.diff)

yeah i didn't see it until i checked my x264-dev emails just now ;)

Edit:
i do want to point out that ver 06 broke with the asm additions of r1096, so that x64 build skystrife has could likely cause corruptions and crash.

[skystrife]

x264.1101M.x64.exe (http://www.mediafire.com/?njeloooqzlz) - Alternate Download (http://skystrife.com/x264/x264.1101M.x64.exe)

Patches used:
x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff
x264_win64_support.08.r1101.diff

gcc 4.3.4 fprofiled build.

[komisar]

version 1101 of x264 from Komisar (gcc 4.3.3 fprofiled build):
x264.1101.k_GIT.generic.x32.exe (http://komisar.gin.by/x264.1101.k_GIT.generic.x32.exe)
x264.1101.k_GIT.generic.x64.exe (http://komisar.gin.by/x264.1101.k_GIT.generic.x64.exe)

Patches for k_GIT:
x264_win64_support.08.r1101.diff
k.75.cross_compile.01.diff
01_x264_custom_strtok_r.r1089.diff
x264_hrd_pulldown.09_interlace.diff
x264_mingw_aligned_04.diff

(Explain of my builds found in bottom of my page)
(Also my cross-compile toolchain with gcc-4.3.3 found here: tools (http://komisar.gin.by/tools/))

[imk]

Built with ICC v11.0.066 (with profiling):
x264.r1101M.SSE2.x32.imk.exe (http://imk.cx/pc/x264/x264.r1101M.SSE2.x32.imk.exe)
x264.r1101M.SSSE3.x32.imk.exe (http://imk.cx/pc/x264/x264.r1101M.SSSE3.x32.imk.exe)

x264.r1101M.SSE2.x64.imk.exe (http://imk.cx/pc/x264/x264.r1101M.SSE2.x64.imk.exe)
x264.r1101M.SSSE3.x64.imk.exe (http://imk.cx/pc/x264/x264.r1101M.SSSE3.x64.imk.exe)


Patches used:
x264_hrd_pulldown.09_interlace.diff
x264_icc.diff
x264_win_zone_parse_fix_05.diff
x264_win64_support.08.r1101.diff (for the 64-bit build only)

[burfadel]

Hey imk, your SSSE3 and SSE2 versions are both pointed towards the SSE2 versions in the links. Changing the link manually to SSSE3 does show the correct file actually exists! :)

[imk]

Oops. Thanks. :) Corrected.

[XhmikosR]

I did a quick comparison. The results are here:

480p sample

start /high /b x264-1101 --pass 1 --progress --quiet --bitrate 1823 --stats "1.stats" --level 3.1 --bframes 3 --b-pyramid --direct auto --subme 1 --analyse none --threads auto --thread-input --me hex --no-dct-decimate --no-psnr --no-ssim --vbv-bufsize 14000 --vbv-maxrate 17500 --output NUL "test-480p.avs" --aud

start /high /b x264-1101 --pass 2 --progress --quiet --bitrate 1823 --stats "1.stats" --level 3.1 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --weightb --direct auto --subme 7 --trellis 1 --analyse all --8x8dct --vbv-bufsize 14000 --vbv-maxrate 17500 --threads auto --thread-input --me hex --sar 427:360 --no-dct-decimate --no-psnr --no-ssim --output "../run1-480p.mkv" "test-480p.avs" --aud

Results for x264 v0.66.1101 [gcc 3.4.6-x264.nl]
encoded 1419 frames, 147.67 fps, 1835.23 kb/s
encoded 1419 frames, 149.35 fps, 1835.23 kb/s
encoded 1419 frames, 149.12 fps, 1835.23 kb/s
encoded 1419 frames, 148.88 fps, 1835.23 kb/s
encoded 1419 frames, 50.93 fps, 1802.78 kb/s
encoded 1419 frames, 50.67 fps, 1803.55 kb/s
encoded 1419 frames, 50.82 fps, 1804.16 kb/s
encoded 1419 frames, 50.82 fps, 1803.53 kb/s
====================================
Results for x264 v0.66.1101 [ICC11.SSSE3.x32-imk]
encoded 1419 frames, 153.39 fps, 1835.23 kb/s
encoded 1419 frames, 153.92 fps, 1835.23 kb/s
encoded 1419 frames, 153.65 fps, 1835.23 kb/s
encoded 1419 frames, 153.90 fps, 1835.23 kb/s
encoded 1419 frames, 52.67 fps, 1803.50 kb/s
encoded 1419 frames, 52.55 fps, 1803.16 kb/s
encoded 1419 frames, 52.67 fps, 1803.63 kb/s
encoded 1419 frames, 52.19 fps, 1803.60 kb/s


720p sample

start /high /b x264-1101 --quiet --progress --pass 1 --bitrate 3959 --stats "1.stats" --level 4.1 --keyint 24 --min-keyint 1 --bframes 3 --direct auto --subme 1 --analyse none --ipratio 1.4 --pbratio 1.3 --vbv-bufsize 50000 --vbv-maxrate 50000 --qcomp 0.5 --me dia --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output NUL "test-720p.avs" --mvrange 511 --aud --nal-hrd

start /high /b x264-1101 --quiet --progress --pass 2 --bitrate 3959 --stats "1.stats" --level 4.1 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --bframes 3 --weightb --direct auto --subme 7 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.4 --pbratio 1.3 --vbv-bufsize 50000 --vbv-maxrate 50000 --qcomp 0.5 --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "../run1-720p.mkv" "test-720p.avs" --mvrange 511 --aud --nal-hrd

Results for x264 v0.66.1101 [gcc 3.4.5-skystrife]
encoded 1442 frames, 75.15 fps, 3989.43 kb/s
encoded 1442 frames, 76.08 fps, 3989.43 kb/s
encoded 1442 frames, 76.08 fps, 3989.43 kb/s
encoded 1442 frames, 76.27 fps, 3989.43 kb/s
encoded 1442 frames, 20.55 fps, 3940.81 kb/s
encoded 1442 frames, 20.60 fps, 3940.70 kb/s
encoded 1442 frames, 20.62 fps, 3942.12 kb/s
encoded 1442 frames, 20.61 fps, 3939.54 kb/s
====================================
Results for x264 v0.66.1101 [ICC11.SSSE3.x32-imk]
encoded 1442 frames, 79.01 fps, 3989.43 kb/s
encoded 1442 frames, 79.62 fps, 3989.43 kb/s
encoded 1442 frames, 78.87 fps, 3989.43 kb/s
encoded 1442 frames, 79.34 fps, 3989.43 kb/s
encoded 1442 frames, 21.19 fps, 3941.79 kb/s
encoded 1442 frames, 21.18 fps, 3941.50 kb/s
encoded 1442 frames, 21.19 fps, 3940.68 kb/s
encoded 1442 frames, 21.14 fps, 3940.40 kb/s


Intel Core2 Quad Q6600 (G0) 2.40GHz @ 3GHz
2x1GB DDR2 @ 800MHz
Vista Business SP1 32bit

[burfadel]

thats a nice little 4 percent speed boost :)

[imk]

I do maintain some personal benchmarks here:
http://spreadsheets.google.com/pub?key=pbffjdC6iUPWs2HtYHwZ2VQ&hl=sv

You may always do your own.

[menlvd]

thats a nice little 4 percent speed boost :)

cost a little-little reduce of quality
imk - http://pic.ipicture.ru/uploads/090208/4347/thumbs/qUo5dS3dV3.png (http://ipicture.ru/Gallery/Viewfull/12988164.html)
komisar - http://pic.ipicture.ru/uploads/090208/4347/thumbs/iZZwCaZi5C.png (http://ipicture.ru/Gallery/Viewfull/12988056.html)

cmd:
set o1=-p 1 -B 7000 --vbv-maxrate 40000 --vbv-bufsize 62500 -I 240 -i 1 -r 5 -b 3 -f -3,-3 -A all -8 --me tesa -t 2 -m 9 -w --mixed-refs --no-fast-pskip --threads 6 --no-psnr --no-ssim --level 4.1 --progress --aq-mode 1 --aq-strength 1.7 --psy-rd 0.6:0.1 --b-adapt 2 -o NUL %in% --stats "c:\x264_2pass.log" --sar %sar% --direct auto --thread-input --no-dct-decimate --b-pyramid --qpmax 35 --qcomp 1 --qpmin 5 --ratetol 3

set o2=-p 2 -B 7000 --vbv-maxrate 40000 --vbv-bufsize 62500 -I 240 -i 1 -r 5 -b 3 -f -3,-3 -A all -8 --me tesa -t 2 -m 9 -w --mixed-refs --no-fast-pskip --threads 6 --no-psnr --no-ssim --level 4.1 --progress --aq-mode 1 --aq-strength 1.7 --psy-rd 0.6:0.1 --b-adapt 2 -o %out% %in% --stats "c:\x264_2pass.log" --sar %sar% --direct auto --thread-input --no-dct-decimate --b-pyramid --qpmax 35 --qcomp 1 --qpmin 5 --ratetol 3

[imk]

Quote from BugMaster on IRC:
"Probably the difference is due multithreading non determinism with VBV."

[imk]

I just did a comparison myself.

gcc v4.3.3:

yuv4mpeg: 1920x1080@30/1fps, 1:1
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 5.1
x264 [info]: slice I:18 Avg QP:17.70 size:398805 PSNR Mean Y:44.88 U:95.96 V:95.40 Avg:46.64 Global:46.55
x264 [info]: slice P:32 Avg QP:23.85 size:220833 PSNR Mean Y:37.61 U:48.26 V:49.09 Avg:39.20 Global:38.83
x264 [info]: consecutive B-frames: 100.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 0.6% 96.3% 3.1%
x264 [info]: mb P I16..4: 0.1% 30.1% 1.4% P16..4: 21.4% 29.2% 14.3% 2.0% 1.5% skip: 0.0%
x264 [info]: 8x8 transform intra:95.9% inter:56.5%
x264 [info]: ref P L0 92.0% 4.5% 1.4% 0.5% 0.5% 0.3% 0.2% 0.1% 0.1% 0.1% 0.1% 0.0% 0.1% 0.0% 0.0% 0.0%
x264 [info]: SSIM Mean Y:0.9447691
x264 [info]: PSNR Mean Y:40.227 U:65.431 V:65.758 Avg:41.877 Global:40.372 kb/s:68376.64


icc v11.0.074 (gcc compatibility mode):

yuv4mpeg: 1920x1080@30/1fps, 1:1
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 5.1
x264 [info]: slice I:18 Avg QP:17.70 size:398805 PSNR Mean Y:44.88 U:95.96 V:95.40 Avg:46.64 Global:46.55
x264 [info]: slice P:32 Avg QP:23.85 size:220833 PSNR Mean Y:37.61 U:48.26 V:49.09 Avg:39.20 Global:38.83
x264 [info]: consecutive B-frames: 100.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 0.6% 96.3% 3.1%
x264 [info]: mb P I16..4: 0.1% 30.1% 1.4% P16..4: 21.4% 29.2% 14.3% 2.0% 1.5% skip: 0.0%
x264 [info]: 8x8 transform intra:95.9% inter:56.5%
x264 [info]: ref P L0 92.0% 4.5% 1.4% 0.5% 0.5% 0.3% 0.2% 0.1% 0.1% 0.1% 0.1% 0.0% 0.1% 0.0% 0.0% 0.0%
x264 [info]: SSIM Mean Y:0.9447691
x264 [info]: PSNR Mean Y:40.227 U:65.431 V:65.758 Avg:41.877 Global:40.372 kb/s:68376.65


icc v11.0.074:

yuv4mpeg: 1920x1080@30/1fps, 1:1
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 5.1
x264 [info]: slice I:18 Avg QP:17.70 size:398805 PSNR Mean Y:44.88 U:95.96 V:95.40 Avg:46.64 Global:46.55
x264 [info]: slice P:32 Avg QP:23.85 size:220833 PSNR Mean Y:37.61 U:48.26 V:49.09 Avg:39.20 Global:38.83
x264 [info]: consecutive B-frames: 100.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 0.6% 96.3% 3.1%
x264 [info]: mb P I16..4: 0.1% 30.1% 1.4% P16..4: 21.4% 29.2% 14.3% 2.0% 1.5% skip: 0.0%
x264 [info]: 8x8 transform intra:95.9% inter:56.5%
x264 [info]: ref P L0 92.0% 4.5% 1.4% 0.5% 0.5% 0.3% 0.2% 0.1% 0.1% 0.1% 0.1% 0.0% 0.1% 0.0% 0.0% 0.0%
x264 [info]: SSIM Mean Y:0.9447691
x264 [info]: PSNR Mean Y:40.227 U:65.431 V:65.758 Avg:41.877 Global:40.372 kb/s:68376.65


The 0,01 kb/s larger bitrate in the icc builds has to do with the version string being larger, otherwise all numbers are completely identical.

These tests were done with this line:
--bframes 16 --b-pyramid --direct auto --ref 16 --crf 20 --partitions all --weightb --me tesa --subme 9 --mixed-refs --8x8dct --no-fast-pskip --no-dct-decimate --trellis 2 --qpmin 0 --progress --threads auto --frames 50

Using mplayer I dumped the 29th frame out of each resulting encode to a png with mplayer -vo png:z=1. I did a diff between the three PNGs and all three are 100% identical to each other.

[kemuri-_9]

here's a bench i did...
using the following makefile i created for this purpose:
x264bench (http://kemuri9.net/dev/x264/other/x264bench)
the options are taken from the fprofiling paths, so it hits a lot of things...

executing it like so:

$ make -f x264bench BINS="x264_x64_k8.exe x264.r1101M.SSE2.x64.imk.exe" VIDS="foreman_176x144.yuv x264_build1.y4m"


it also checks for gpac, avs, pthread support, and
the ability to use more than 1 zone (nonbroken strtok_r or win_zone_parse_fix_xx.diff)

resulting files are
x264.r1101M.SSE2.x64.imk.exe_bench.log (http://kemuri9.net/dev/x264/other/x264.r1101M.SSE2.x64.imk.exe_bench.log)
x264_x64_k8.exe_bench.log (http://kemuri9.net/dev/x264/other/x264_x64_k8.exe_bench.log)

Some notes are:
1. there's some small kb/s discrepancies which is a result of one of my patches that moves where the post-encoding stats are generated and displayed from.
2. as I'm on a phenom, i don't have SSSE3 and i use -march=k8 when compiling my x64 builds.

[imk]

You don't specify a target architecture with ICC; you specify a minimum target instruction set instead. The SSE2 build will work on anything SSE2 and higher, and the SSSE3 build will work on any processor with SSSE3 support and higher. All builds will still take advantage of whatever your processor supports, I.E. the SSE2 build will still use SSSE3, or SSE4.2, etc.

I have a benchmark script on my site:
http://imk.cx/pc/x264/bench_x264.pl

The only module that you should have to install is Data::Types.
The script works on Linux, Mac OS X, and Windows. I have not tested it with Cygwin on Windows, but if you use ActivePerl, it works with that.
To get it to work with ActivePerl, run "ppm install Data::Types" and then change the $output line inside of the script and run it.

The script will output a single value if you only do 1 run. For 2-5 runs, it will display an average. Anything 6 runs or higher will calculate outliers and filter out data to give a more accurate number.

If you feed it no arguments, it will ask for input, but you may also specify the arguments to have it run directly.

./bench_x264.pl <binary> <input> <test number [0-3]> <threads [0-# or auto]> <number of runs>

Examples:
./bench_x264.pl ./x264-r1101M-icc ./SOCCER_352x288_30_orig_02.yuv 0 0 20
./bench_x264.pl ./x264-r1101M-icc ./SOCCER_352x288_30_orig_02.yuv 1 auto 20

[Fr4nz]

Hello imk, I appreciate your work and I'd have a request for you: is it possibile to implement mp4 output in your build?

Thanks for any answer!

[G_M_C]

Hello imk, I appreciate your work and I'd have a request for you: is it possibile to implement mp4 output in your build?

Thanks for any answer!

There was a thread about MP4 output, that seemed to suggest that x264 has to output an x264 elementary stream, without container etc. Muxing into some form of container has to be left to muxers, not the encoder. This seems very reasonable to me since x264 is primarely designed for encoding, and muxing into a file-format is a different task (and therefore should be left for other applications).

[Fr4nz]

There was a thread about MP4 output, that seemed to suggest that x264 has to output an x264 elementary stream, without container etc. Muxing into some form of container has to be left to muxers, not the encoder. This seems very reasonable to me since x264 is primarely designed for encoding, and muxing into a file-format a different task (and therefore should be left for other applications).

I got the point, thanks for the clarification.

[burfadel]

Wow! nice list of updates an hour ago! It would be interesting to see the cumulative performance benefit over the 4 submissions. One gives slight quality improvement, the others add:

- Up to ~17% faster CABAC RDO, ~36% faster intra-only CABAC RDO. Up to 7% faster overall in extreme cases.
- Faster coeff_last64 on 32-bit
- SSSE3 version of predict_8x8_hu
- SSE2 version of predict_8x8c_p
- SSSE3 versions of both planar prediction functions
- Optimizations to predict_16x16_p_sse2
- Some unnecessary REP_RETs -> RETs.
- SSE2 version of predict_8x8_vr by Holger.
- SSE2 version of predict_8x8_hd.
- Don't compile MMX versions of some of the pred functions on x86_64.
- Remove now-useless x86_64 C versions of 4x4 pred functions.
- Rewrite some of the x86_64-only C functions in asm.

Its a good think its not 1 April, people would think its a cruel April Fool's joke! :)

[G_M_C]

I got the point, thanks for the clarification.

Mind you, the outcome of that poll wasnt clear, probably because the poll-question was "multi-interpretable" ;) But what i wrote above was the direction the discussion was going.

[wyti]

HI, i'm searching for a while for an up to date x264 RDRC patch (ideally compatible with r1096) but i can't find anyone.
And i will be very happy if someone know where to find this patch and have enough time to compile an x264 build (win32) with that patch applied.

[J_Darnley]

There aren't any, public ones at least. Who knows what Dark Shikari has tucked away.

[Sharktooth]

HI, i'm searching for a while for an up to date x264 RDRC patch (ideally compatible with r1096) but i can't find anyone.
And i will be very happy if someone know where to find this patch and have enough time to compile an x264 build (win32) with that patch applied.
come on, are you serious?
RDRC is usefull for debugging. noone wants tu run RDRC in real life encodings. it's too damn slow!!!

[Dark Shikari]

come on, are you serious?
RDRC is usefull for debugging. noone wants tu run RDRC in real life encodings. it's too damn slow!!!You underestimate the amount of time people have on their hands ;)

[imk]

Hello imk, I appreciate your work and I'd have a request for you: is it possibile to implement mp4 output in your build?

That's another mess that I don't really want to play around with. I just use mp4box directly or mkvmerge. :)

[imk]

Built with ICC v11.0.066 (with profiling):
x264.r1106M.SSE2.x32.imk.exe (http://imk.cx/pc/x264/x264.r1106M.SSE2.x32.imk.exe)
x264.r1106M.SSSE3.x32.imk.exe (http://imk.cx/pc/x264/x264.r1106M.SSSE3.x32.imk.exe)

x264.r1106M.SSE2.x64.imk.exe (http://imk.cx/pc/x264/x264.r1106M.SSE2.x64.imk.exe)
x264.r1106M.SSSE3.x64.imk.exe (http://imk.cx/pc/x264/x264.r1106M.SSSE3.x64.imk.exe)


Patches used:
x264_hrd_pulldown.09_interlace.diff
x264_icc.diff
x264_win_zone_parse_fix_05.diff
x264_win64_support.09.r1106.diff (for the 64-bit build only)

[wyti]

come on, are you serious?
RDRC is usefull for debugging. noone wants tu run RDRC in real life encodings. it's too damn slow!!!

Yes i'm serious, i only want to try it by myself, and only after that i will know if this is too slow for me or not.

[kemuri-_9]

Yes i'm serious, i only want to try it by myself, and only after that i will know if this is too slow for me or not.


<blue_misfit> RDRC looks interesting too!!! probably too slow for me to use
<Dark_Shikari> RDRC is not really stable enough for practical use. not only slow and unthreaded, but it dies horribly on fades (because that's what is RD-optimal to do in the case of no weighted prediction)

so you should hold off on it for the time being.

[skystrife]

x264.1109M.exe (http://www.mediafire.com/?nwzijnmnzzy) - Alternate Download (http://skystrife.com/x264/x264.1109M.exe)

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff

gcc 3.4.5 fprofiled build with -march=pentium2.
-----------------------------------------------

x264.1109M.x64.exe (http://www.mediafire.com/?4qd4dmynktz) - Alternate Download (http://skystrife.com/x264/x264.1109M.x64.exe)

Patches used:
x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff
x264_win64_support.09.r1106.diff

gcc 4.3.4 fprofiled build.

[burfadel]

x264 on www.x264.nl is now 2 builds old, its not updating properly... (I realise since its automatic should create a new build even if the build changes aren't relevant for x86)...

[kemuri-_9]

Windows 64-bit support
A "make distclean" is probably required after updating to this revision.


that 2nd line there is probably the cause. it's likely not able to compile correctly it until that is done.

[bob0r]

x264 on www.x264.nl is now 2 builds old, its not updating properly... (I realise since its automatic should create a new build even if the build changes aren't relevant for x86)...

Windows update reboots ftw.
I know it can be turned off, but that computer is standalone and direct online, so better safe than sorry.

Compiling.... :cool:

[burfadel]

Thanks :)

[Snowknight26]

Windows update reboots ftw.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"NoAutoRebootWithLoggedOnUsers"=dword:00000001

[JohannesL]

<Dark_Shikari> RDRC is not really stable enough for practical use. not only slow and unthreaded, but it dies horribly on fades (because that's what is RD-optimal to do in the case of no weighted prediction)
That explains the blur on the treetops in the beginning fade in your BBB encode. (Can't that be solved with a zones setting though?)

[Dark Shikari]

That explains the blur on the treetops in the beginning fade in your BBB encode. (Can't that be solved with a zones setting though?)RDRC doesn't respect zones (I think?). It really should be a fix in the algorithm anyways, not a zone hack.

[skystrife]

x264 r1113 (unpatched) (http://www.mediafire.com/?dbdzwljmykz) - Alternate Download (http://skystrife.com/x264/revision1113/x264.exe)
gcc 4.3.4 fprofiled build.

-------------------------

x264.1113M.x86.exe (http://www.mediafire.com/?t32dn0mzym1) - Alternate Download (http://skystrife.com/x264/x264.1113M.x86.exe) / x264.1113M.x64.exe (http://www.mediafire.com/?xztmzqntwdj) - Alternate Download (http://skystrife.com/x264/x264.1113M.x64.exe)
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff

[bob0r]

skystrife's unpatched builds will be (manually) updated on x264.nl.

Thanks!

[LoRd_MuldeR]

skystrife's unpatched builds will be (manually) updated on x264.nl.

Thanks!

I wonder: Isn't it possible to automatically compile/update the x64 builds, just like you do it with the x86 ones?

[kemuri-_9]

I wonder: Isn't it possible to automatically compile/update the x64 builds, just like you do it with the x86 ones?

he can't profile the x64 ones, so he's using skystrife's which are profiled.

[LoRd_MuldeR]

he can't profile the x64 ones, so he's using skystrife's which are profiled.

I assume the problem is that his machine isn't 64-Bit.

Well, if profiling doesn't measure realtime, but something like "instructions per function call" or "number of calls per function", it could be run inside an emulator.

QEMU should be able to emulate a x86-64 processor on a x86 machine.

The problem I see is that running the profiling inside an emulator may take a very long time... :(

[Egh]

One thing which may be good to add a patch for:

http://forum.doom9.org/showthread.php?p=1250312

Apparently, as I identified, current AVIS code supports AVI files input but doesn't care if they over 2GB so x264 just finishes job successfully when it reaches 2gb limit (no errors shown of course;)). It seems it would be relatively easy to adjust the code to understand OpenDML avi files.

Could someone please take a look at it?

[imk]

Here's a bunch of ICC builds:

x264.r1114M.SSE2.x32.imk.exe (http://imk.cx/pc/x264/x264.r1114M.SSE2.x32.imk.exe)
x264.r1114M.SSE2.x32.mp4.imk.exe (http://imk.cx/pc/x264/x264.r1114M.SSE2.x32.mp4.imk.exe)
x264.r1114M.SSSE3.x32.imk.exe (http://imk.cx/pc/x264/x264.r1114M.SSSE3.x32.imk.exe)
x264.r1114M.SSSE3.x32.mp4.imk.exe (http://imk.cx/pc/x264/x264.r1114M.SSSE3.x32.mp4.imk.exe)

x264.r1114M.SSE2.x64.imk.exe (http://imk.cx/pc/x264/x264.r1114M.SSE2.x64.imk.exe)
x264.r1114M.SSE2.x64.mp4.imk.exe (http://imk.cx/pc/x264/x264.r1114M.SSE2.x64.mp4.imk.exe)
x264.r1114M.SSSE3.x64.imk.exe (http://imk.cx/pc/x264/x264.r1114M.SSSE3.x64.imk.exe)
x264.r1114M.SSSE3.x64.mp4.imk.exe (http://imk.cx/pc/x264/x264.r1114M.SSSE3.x64.mp4.imk.exe)

x264.r1114.SSE2.linux.static.x64.imk.lzma (http://imk.cx/pc/x264/x264.r1114.SSE2.linux.static.x64.imk.lzma)
x264.r1114.SSSE3.linux.static.x64.imk.lzma (http://imk.cx/pc/x264/x264.r1114.SSSE3.linux.static.x64.imk.lzma)


The builds with mp4 in them have mp4 output built in. All I did was compile gpac_lib in MSVC2005 and link x264 against the .lib file. I didn't need any patches or anything for it to work. I personally don't use mp4 output so I haven't tested it. Let me know how it works.

The Linux binaries can be extracted with unlzma. There will be no 32-bit builds of x264 with ICC for Linux since my environment is not multilib (it's 64-bit only).

Older builds, build scripts, information, etc. can all be found here (http://imk.cx/pc/x264/).

[G_M_C]

I'd like to start using the ICC builds, cause i've noticed they seem moderately faster on my XP/SP3 system with 4Gb and C2D 6750. But i just want to make shure; Are there any differences noticed in the output of the ICC builds, compared to the other builds ?

[video_magic]

Hello imk,
thanks for providing the x264 builds. I have failed to understand one of your posts earlier; please would you tell me whether I should be downloading the SSE2 or the SSSE3 version, I have this CPU:
http://processorfinder.intel.com/details.aspx?sSpec=SL9KF

You don't specify a target architecture with ICC; you specify a minimum target instruction set instead. The SSE2 build will work on anything SSE2 and higher, and the SSSE3 build will work on any processor with SSSE3 support and higher. All builds will still take advantage of whatever your processor supports, I.E. the SSE2 build will still use SSSE3, or SSE4.2, etc.
...

Also, is there some sort of DLL file I am meant to put on my system to ensure the ICC build works fully as it should? Thankyou again.

[Audionut]

SSE2 and no to the dll file.

[video_magic]

Thanks!

Are these two statements true then as I hope to have understood it?:

The SSE2 build would be the fastest for me.

There are some SSSE3 chips which don't have SSE2.

[Dark Shikari]

There are some SSSE3 chips which don't have SSE2.Er, no.

[video_magic]

For what reasons might someone prefer to download an SSSE3 build rather than downloading an SSE2 build, from the ICC selection above?

I am only curious so thanks for any simple explanations.

[imk]

For what reasons might someone prefer to download an SSSE3 build rather than downloading an SSE2 build, from the ICC selection above?

I am only curious so thanks for any simple explanations.

The difference just has to do what instruction set was targeted when profiling. Builds targeted for SSE2 will still take advantage of any instruction set your processor uses, and it will work on any SSE2-capable processor. The same goes for the SSSE3 builds. When compiled targeting SSSE3, ICC will take advantage of instructions found in SSSE3.

So if your processor doesn't support anything higher than SSE2, then grab the SSE2 build. If you have a Core 2 Duo or Core 2 Quad, or any other processor with SSSE3 support, then grab the SSSE3 build.

I haven't benchmarked the difference between the builds, but I wouldn't be surprised if there's absolutely no difference between them.

I just build them because it doesn't really require any extra effort. :)


Are there any differences noticed in the output of the ICC builds, compared to the other builds ?

There should be no difference.

[video_magic]

Thanks very much guys.
If the SSE2 build will use the other instructions of my CPU as it needs then that is my query answered I think!

[LoRd_MuldeR]

Thanks very much guys.
If the SSE2 build will use the other instructions of my CPU as it needs then that is my query answered I think!

x264 uses its own runtime CPU detection code anyway. Also most (all?) performance critical functions are written as hand optimized assembler code.

Hence if your CPU supports any instructions that are useful for x264, then x264 will detect and use them, regardless of the compiler settings that were used to make the build.

The compiler optimizations don't effect anything but the plain C code in x264...

[kemuri-_9]

Are there any differences noticed in the output of the ICC builds, compared to the other builds ?

possibly yes, for the x86 builds:
since the ICC builds are using the sse floating point math instruction set rather the the 387 instruction set that gcc uses by default (because gcc doesn't use sse for x86 builds unless told to),
under certain settings you can get different binary outputs between the x86 gcc and above x86 icc versions.

this was pointed out by BugMaster originally for differences between x86 and x64 gcc binary outputs, since 387 is default for x86 and sse is default for x64.

[skystrife]

x264 r1114 (unpatched) (http://www.mediafire.com/?2kdijwzhwxz) - Alternate Download (http://skystrife.com/x264/revision1114/x264.exe)
gcc 4.3.4 fprofiled build.

-------------------------

x264.1114M.x86.exe (http://www.mediafire.com/?2oaynozyuxq) - Alternate Download (http://skystrife.com/x264/x264.1114M.x86.exe) / x264.1114M.x64.exe (http://www.mediafire.com/?in1zo2ilimi) - Alternate Download (http://skystrife.com/x264/x264.1114M.x64.exe)
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff

The 2GB files issue should be fixed, but I didn't test it.

EDIT: Revert to 1113 if you experience the issue below. I'm not sure what caused this, but a rebuild appears to have fixed it so I will update the links when it is finished.

[komisar]

skystrife, sorry, but:
"The image file D:\Temp\movie\.test\vaq.test\x264.1114M.x64.exe is valid, but is for a machine type other than the current machine."
http://komisar.gin.by/img/trash/err1.png
on my AMD Athlon64

[LoRd_MuldeR]

skystrife, sorry, but:
"The image file D:\Temp\movie\.test\vaq.test\x264.1114M.x64.exe is valid, but is for a machine type other than the current machine."

Works on my Core2 under WindowsXP x64-Edition :confused:

[Chengbin]

You underestimate the amount of time people have on their hands ;)

+1

I got too much time on my hands. I would like the RDRC patch too. I seriously don't care about encoding time, as long as it is not more than 4x slower than the current x264, as I can't always leave the computer on overnight, so I must be able to finish encoding a movie in 16 hours.

Any idea when RDRC is stable enough for release? Do you think we can see a functional (threaded), and stable release by early 2010? Does it work in main profile? A decoder doesn't care if the video is encoded with RDRC or 2 pass right?

How long did it take to encode the BBB episode? What processor? What kind of bitrate do you need to get roughly equivalent quality using 2 pass or crf?

Is there a webpage that explains how RDRC works and why the quality is so good?

Oh crap I just saw that RDRC is not threaded. Even if it is the same speed as 2 pass, it would be over my time limit. Looks like until it is threaded, I can only use it on TV episodes and anime, because they're shorter.

[komisar]

For testing (profiled,mp4,pthread, gcc 4.3.4 20090220 prerelease):
x264.1114.kGIT.generic.x32.test.exe (http://komisar.gin.by/test/x264.1114.kGIT.generic.x32.test.exe)
x264.1114.kGIT.generic.x64.test.exe (http://komisar.gin.by/test/x264.1114.kGIT.generic.x64.test.exe)

patches:
01_x264_custom_strtok_r.r1089.diff
x264_hrd_pulldown.09_interlace.diff
x264_mingw_aligned_04.diff

P.S. Also see my post (http://forum.doom9.org/showthread.php?p=1252042#post1252042)

[Dark Shikari]

+1

I got too much time on my hands. I would like the RDRC patch too. I seriously don't care about encoding time, as long as it is not more than 4x slower than the current x264, as I can't always leave the computer on overnight, so I must be able to finish encoding a movie in 16 hours.

Any idea when RDRC is stable enough for release? Do you think we can see a functional (threaded), and stable release by early 2010? Does it work in main profile? A decoder doesn't care if the video is encoded with RDRC or 2 pass right?

How long did it take to encode the BBB episode? What processor? What kind of bitrate do you need to get roughly equivalent quality using 2 pass or crf?

Is there a webpage that explains how RDRC works and why the quality is so good?

Oh crap I just saw that RDRC is not threaded. Even if it is the same speed as 2 pass, it would be over my time limit. Looks like until it is threaded, I can only use it on TV episodes and anime, because they're shorter.RDRC is incredibly simple.

1. Encode the current frame at a certain quantizer. This isn't at all incompatible with AQ and works how you think it would.

2. Encode the next X frames at the quantizers they were encoded at in the first pass.

3. Measure the RD score (bits*lambda+SSD) of all the frames encoded.

4. Pick a new quantizer, GOTO 1. Do this for a whole bunch of quantizers.

5. Pick the best quantizer of all those tried. This is the quantizer for the frame. Encode the frame.

6. Go to the next frame. :devil:

(This is not as slow as you would think it is because this lookahead pass is done with very very very fast encoding settings and with bitstream writing turned off, so you can pretty much calculate the performance of this by making a rough estimate of how many QPs are tried (say, 10) and multiplying times the lookahead size and using the speed equal to the speed of a very fast first pass.)

[Chengbin]

Thank you Dark Shikari.

Obviously RDRC can't be that simple, otherwise it would be released already.

Do you mind answering the other questions in my previous post? I really need to know them in order to know if RDRC is for me, or it is for fun.

Can you can use RDRC and specify a specific size?

[Dark Shikari]

Thank you Dark Shikari.

Obviously RDRC can't be that simple, otherwise it would be released already.Simple does not mean it should be released.
Can you can use RDRC and specify a specific size?No. That could be coded, but it would require some modifications to ratecontrol.

[Chengbin]

Simple does not mean it should be released.

Then why bother coding it?

It works with main profile right?

Assuming you use the same settings in CRF and RDRC, roughly how much more efficient is RDRC? Roughly how much longer will it take?

[Dark Shikari]

Then why bother coding it?Because it's a good platform for testing experimental ratecontrol ideas, much like QNS is a good platform for testing arbitrary quality metrics.
It works with main profile right?It works with any profile.
Assuming you use the same settings in CRF and RDRC, roughly how much more efficient is RDRC?I couldn't give you a number, and RDRC optimizes purely for PSNR (and my modification of it optimizes for SSIM). This may not be the best from a visual standpoint.

MB-tree AQ would be a better way to solve the problem.

[cyberbeing]

MB-tree AQ would be a better way to solve the problem.
The mythical MB-tree patch. :devil:
Did you ever find committed to coding the MB-tree patch, still any chance to make it a project for Google Summer of Code, does it still seem you may have to code it yourself, or are there still more important things which need to be finished first?

[Sagittaire]

RDRC is incredibly simple.

1. Encode the current frame at a certain quantizer. This isn't at all incompatible with AQ and works how you think it would.

2. Encode the next X frames at the quantizers they were encoded at in the first pass.

3. Measure the RD score (bits*lambda+SSD) of all the frames encoded.

4. Pick a new quantizer, GOTO 1. Do this for a whole bunch of quantizers.

5. Pick the best quantizer of all those tried. This is the quantizer for the frame. Encode the frame.

6. Go to the next frame. :devil:



Not possible to make RDRC at macroblock level instead frame level?

1. Encode the current frame at a certain quantizer.

2. Encode the next X frames at the quantizers they were encoded at in the first pass.

3. Measure the RD score (bits*lambda+SSD) at macroblock level of all the frames encoded.

4. Pick a new quantizer, GOTO 1. Do this for a whole bunch of quantizers.

5. Pick the best quantizer for each macroblock of all those tried. Encode the frame.

6. Go to the next frame. :devil:

That's should work like a complexity mask: higher relative quantizer for high complexity block and lower relative quantizer for low complexity block if you choose lower relative lambda for high complexity block (save bit advantage) and higher relative lambda for low complexity block (save quality advantage).

[Dark Shikari]

Not possible to make RDRC at macroblock level instead frame level?

1. Encode the current frame at a certain quantizer.

2. Encode the next X frames at the quantizers they were encoded at in the first pass.

3. Measure the RD score (bits*lambda+SSD) at macroblock level of all the frames encoded.

4. Pick a new quantizer, GOTO 1. Do this for a whole bunch of quantizers.

5. Pick the best quantizer for each macroblock of all those tried. Encode the frame.

6. Go to the next frame. :devil:

That's should work like a complexity mask: higher relative quantizer for high complexity block and lower relative quantizer for low complexity block if you choose lower relative lambda for high complexity block (save bit advantage) and higher relative lambda for low complexity block (save quality advantage).You could only really do this correctly if you did it for each macroblock separately, which would make it about 1000 times slower.

However, this would accurately emulate the effect of MBtree (in fact, it would emulate a completely-optimal MBtree) and might be practical to use on something like QCIF footage for testing.

[Sagittaire]

However, this would accurately emulate the effect of MBtree (in fact, it would emulate a completely-optimal MBtree) and might be practical to use on something like QCIF footage for testing.

Yes and the advantage of RDRC at macroblock level is that you can introduce HVS masking (Spatial and temporal complexity, Luma, constrast ... ) with different lambda at macroblock level. Certainely the Graal for RC ... with very powerfull CPU.

[SZGY]

I did a really small benchmark (1000 frames) on my Q6600 under XP x64 with x264.r1114M w/ avs64. The 64 bit version seems to be less than 4% faster than the 32bit one. But hey, that's a start :)

[lexor]

MeGUI just updated me from 1113 to 1114 skystrife build and the thing now says it is incompatible with my x64 OS. :( (same problem as komisar reported on previous page)

[kemuri-_9]

yeah, it looks like gcc 4.3.4 prerelease builds have some issues, try this 4.3.3 build i did:

http://forum.doom9.org/showthread.php?p=1252595#post1252595

gcc is something you don't want to experiment with unless you want to report bugs, as generally there's lots of them.

Edit:
are you on an AMD chip btw? me and komisar have issues with that build and we're on AMD cpus...

[Fishman0919]

yeah, it looks like gcc 4.3.4 prerelease builds have some issues, try this 4.3.3 build i did:

http://forum.doom9.org/showthread.php?p=1252595#post1252595

gcc is something you don't want to experiment with unless you want to report bugs, as generally there's lots of them.

Edit:
are you on an AMD chip btw? me and komisar have issues with that build and we're on AMD cpus...

skystrife x264.1114M.x64.exe does not work on my AMD 9950 but works fine on my Intel Q6600 and Q9650. This build works fine on my AMD 9950.

[komisar]

Fishman0919, lexor, how about this test builds?
http://forum.doom9.org/showthread.php?p=1252756#post1252756
(his make with new toolchain)

[Fishman0919]

Fishman0919, lexor, how about this test builds?
http://forum.doom9.org/showthread.php?p=1252756#post1252756
(his make with new toolchain)

This one works fine on both my AMD and Intel Quad CPU's

[skystrife]

x264 r1114 02 (unpatched) (http://www.mediafire.com/?ymzozyddyw5) - Alternate Download (http://skystrife.com/x264/revision1114/x264.exe)
gcc 4.3.4 fprofiled build.

-------------------------

x264.1114M.02.x86.exe (http://www.mediafire.com/?icy0m1n2zym) - Alternate Download (http://skystrife.com/x264/x264.1114M.02.x86.exe) / x264.1114M.02.x64.exe (http://www.mediafire.com/?znwjmggo0yn) - Alternate Download (http://skystrife.com/x264/x264.1114M.02.x64.exe)
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff

I had someone who was having difficulty with the other build test the 32-bit version and it is working for him, so if you were having problems before try this build.

I still have no idea what might have caused the issue.

EDIT: x64 still has issues. -_-;

[bob0r]

Have you read the posts about the 64bit not working on some AMD systems, have you tested that?
Else use what komisar recommends.

[ash925]

thanks for new build,previous one failed with message in megui saying wrong parameter.

[skystrife]

Have you read the posts about the 64bit not working on some AMD systems, have you tested that?
Else use what komisar recommends.

It was the same message for 64 and 32 bit, so I'm hoping that I fixed both by recompiling. However, I'd need someone to check since they worked here regardless.

[kemuri-_9]

It was the same message for 64 and 32 bit, so I'm hoping that I fixed both by recompiling. However, I'd need someone to check since they worked here regardless.

x64 still broken on my AMD computers.

[skystrife]

Do you have any idea why that might be? Why would it break on just some architectures? Is it a 4.3.4 thing or ?

[kemuri-_9]

probably that revision of gcc 4.3.4 had some bugs, try a newer revision or use 4.3.3

[lexor]

x264 r1114 02 (unpatched) (http://www.mediafire.com/?ymzozyddyw5) - Alternate Download (http://skystrife.com/x264/revision1114/x264.exe)
gcc 4.3.4 fprofiled build.

-------------------------

x264.1114M.02.x86.exe (http://www.mediafire.com/?icy0m1n2zym) - Alternate Download (http://skystrife.com/x264/x264.1114M.02.x86.exe) / x264.1114M.02.x64.exe (http://www.mediafire.com/?znwjmggo0yn) - Alternate Download (http://skystrife.com/x264/x264.1114M.02.x64.exe)
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff

I had someone who was having difficulty with the other build test the 32-bit version and it is working for him, so if you were having problems before try this build.

I still have no idea what might have caused the issue.

EDIT: x64 still has issues. -_-;
32bit works fine, 64bit doesn't (same error message) on i7.

64bit version kamisar offered to test works fine.

[bob0r]

komisar can you compile a clean x264 1114 git build, 64 bit for x264.nl?

[komisar]

bob0r, test first.

1114 with no patches. (mp4,pthread,gcc434,fprofiled,-mtune=generic)
x264_64.exe (http://komisar.gin.by/x264_64.exe)

skystrife, how you can patch gcc? Maybe you compile for intel emt64? You last x64 build not working for me...

kemuri-_9, 4.3.3 version of gcc have the same issue as for 4.3.4...

[burfadel]

Same for me, Skystrife's x64 build doesn't work. I think he compiled it as 64 bit and not x64, there is a difference. 64 bit, although generally refers to x64, also refers to IA64, which would explain the message! (completely incompatible). Many people don't realise that Server 2008/Vista comes in two different 64 bit versions! IA64 is only really for servers, not sure if Intel are even making IA64 cpu's any more.

[squid_80]

Vista was never released for Itanium. I think HP are the only company still making IA64 based machines.

[burfadel]

Yeah sorry only Server 2008 released with IA64. Either way, it looks as though thats what he COULD be compiling it for?... (or it could be just a bug in the compiler).

http://support.microsoft.com/kb/966319/

Thats a random update I chose that shows the IA64 and Vista x64 versions of the Windows Kernel :) (and its the latest kernel available that I know of for Vista).

[squid_80]

Regardless, Skystrife's build is definitely not mistakenly compiled for IA64.

[burfadel]

Ah ok :) the file size kind of gives that away too, IA64 seems to have significantly lower coding efficiency? ...??

[kemuri-_9]

kemuri-_9, 4.3.3 version of gcc have the same issue as for 4.3.4...

what issue?

[komisar]

kemuri-_9,
1-st: proper configure gcc for use crtfm (read this post (http://forum.doom9.org/showthread.php?p=1251846#post1251846));
2-nd: proper configure gcc for libgcov (to use profiling) (read this post (http://forum.doom9.org/showthread.php?p=1252042#post1252042));
3-rd: for platform-dependant-build use -march and -mtune (libgcc.a/libssp.a/libstdc++.a/etc use this flags) (e.g. for my "generic"-builds i use "-march=pentium2 -mtune=generic" for i686-pc-mingw32 and "-mtune=generic" for x86_64-pc-mingw32).

[kemuri-_9]

kemuri-_9,
1-st: proper configure gcc for use crtfm (read this post (http://forum.doom9.org/showthread.php?p=1251846#post1251846));
2-nd: proper configure gcc for libgcov (to use profiling) (read this post (http://forum.doom9.org/showthread.php?p=1252042#post1252042));
3-rd: for platform-dependant-build use -march and -mtune (libgcc.a/libssp.a/libstdc++.a/etc use this flags) (e.g. for my "generic"-builds i use "-march=pentium2 -mtune=generic" for i686-pc-mingw32 and "-mtune=generic" for x86_64-pc-mingw32).

1 - was the -ffast-math issue, correct? i fix that by manually compiling it.
2 - i've always been doing that.
3 - i don't bother.

[komisar]

kemuri-_9, then you should not be a problem with compiling.

[Rodger]

Please REMOVE the 1114er Release from the "Stable" server.
IT´s NOT! See here.
Difference is really ONLY between the wto builds!!!

http://www.bilder-space.de/thumb/23.02pscBD1HMYIsK2Uo.jpg (http://www.bilder-space.de/show.php?file=23.02pscBD1HMYIsK2Uo.jpg)

Oooppsy :)
The tags are wrong :rolleyes:
Build 1114 is on top
Build 1113 is below (DAMN!)

[DarkZell666]

Please REMOVE the 1114er Release from the "Stable" server.
IT´s NOT! See here.
Difference is really ONLY between the wto builds!!!

http://www.bilder-space.de/thumb/23.02pscBD1HMYIsK2Uo.jpg (http://www.bilder-space.de/show.php?file=23.02pscBD1HMYIsK2Uo.jpg)

Oooppsy :)
The tags are wrong :rolleyes:
Build 1114 is on top
Build 1113 is below (DAMN!)

Do you have more complete error logs ? Btw what software is it you're using ?

[kemuri-_9]

Do you have more complete error logs ? Btw what software is it you're using ?

this is probably referring to the fact that skystrife's r1114 x64 build is known to be broken.

Sharktooth needs to revert megui to r1113 or use someone else's build.

[Rodger]

this is probably referring to the fact that skystrife's r1114 x64 build is known to be broken.

Sharktooth needs to revert megui to r1113 or use someone else's build.
Hmmh? I´m using the usual Megui (32Bit) 0.3.1.1016.
Why should I get any 64bit Build from the stable servers?

===============================================================
@DarkZell....not really. I tried two times with the same results and immediately switched back to Build 1113 which works fine for me.

[kemuri-_9]

Hmmh? I´m using the usual Megui (32Bit) 0.3.1.1016.
Why should I get any 64bit Build from the stable servers?

If you're on an x64 Windows OS (XP, Vista, and 7 all have available x64 versions),
then you'll see a performance increase by getting the x64 build of x264.

i'm not sure how megui is handling this (i don't use it),
but i imagine that you have the x64 build,
as there haven't been any reports of skystrife's r1114 x86 build failing.

the problematic x64 build is exhibiting problems of immediately crashing upon trying to start up on some systems (majority of the reports are coming in from AMD CPU systems).

[Rodger]

How is the x64 Build to identify?
Well it´s right so far, I´m on Vista 64bit.
But It´s a E8400 @3560Mhz.

But since I didn´t do anything but update it still should be the plan to remove the dead build from the servers before too many users are affected.

I should really post in the megui thread a warning.

[DarkZell666]

Ah right, I haven't used MeGUI for a while, I was just wondering where that screenshot was coming from =)

r1114 isn't broken per se from what I understand, it's only some x64 miscompilation issues with GCC, and those aren't even specific to r1114. The x64 code itself actually works :p

@Rodger: As it turns out, your post would have been more appropriate in the MeGUI thread :)
(Edit: was too long to write my post :p)

[burfadel]

On Intel's it says its the wrong machine type, as if you're running a 16 bit windows app under x64, which is why I thought it might have been compiled for IA64 instead of x64 (not sure even if you could compile it for IA64). Either way, isn't there an even more beta GCC 4.4.0? The MPC Homecinema versions on www.xvidvideo.ru and discusses on here in other threads has its x64 version compiled with GCC 4.4.0. This may be a viable (and potentially faster) alternative. The x86 versions are still compiled with 4.3.2, so maybe there's a reason for that?

[kemuri-_9]

On Intel's it says its the wrong machine type, as if you're running a 16 bit windows app under x64, which is why I thought it might have been compiled for IA64 instead of x64 (not sure even if you could compile it for IA64). Either way, isn't there an even more beta GCC 4.4.0? The MPC Homecinema versions on www.xvidvideo.ru and discusses on here in other threads has its x64 version compiled with GCC 4.4.0. This may be a viable (and potentially faster) alternative. The x86 versions are still compiled with 4.3.2, so maybe there's a reason for that?

4.4.0 is more beta and more broken than 4.3.4.

[burfadel]

Well that makes sense! but for some reason it seems to work with MPC? (I haven't tried it and its coming up 5am here so I'm not going to!) but the way I look at it, if you want to maximise performance potential and use a beta that helps you achieve this, despite 4.4.0 being more developmental than 4.3.4, it may be beneficial to use simply because there's the potential that any bugs in it don't directly affect it unlike those in 4.3.4 :)

[kemuri-_9]

we already have tried 4.4.0 for x264, and it failed at doing so correctly at that point in time.

[skystrife]

x264.1114M.03.x64.exe (http://skystrife.com/x264/x264.1114M.03.x64.exe) should work. Ultimately it was unrelated to gcc and my perl script is at fault... though I don't see how.

Weird. Thanks to everyone who noticed this.

[lexor]

x264.1114M.03.x64.exe (http://skystrife.com/x264/x264.1114M.03.x64.exe) should work. Ultimately it was unrelated to gcc and my perl script is at fault... though I don't see how.

Weird. Thanks to everyone who noticed this.

Can confirm working on my i7. :)

[komisar]

skystrife, on amd athlon64 work fine....

[Rodger]

Is there a how to for the x64 Builds?

I guess just replacing a 32bit build with a 64bit build won´t work?!

[LoRd_MuldeR]

I guess just replacing a 32bit build with a 64bit build won´t work?!

You will also need 64-Bit Avisynth -or- pipe the source in from a 32-Bit process.

The latter allows you to use 32-Bit Avisynth, as you are used to it. I made a small tool for that purpose:
http://forum.doom9.org/showthread.php?t=144140

[lexor]

You will also need 64-Bit Avisynth -or- pipe the source in from a 32-Bit process.

The latter allows you to use 32-Bit Avisynth, as you are used to it. I made a small tool for that purpose:
http://forum.doom9.org/showthread.php?t=144140

That tool looks awesome, I'm gonna try it out when I get back home. I wish MeGUI did this kind of piping... but hey, I'm not the one to shy away from juggling tools :)

[LoRd_MuldeR]

That tool looks awesome, I'm gonna try it out when I get back home. I wish MeGUI did this kind of piping...

That shouldn't be too hard to implement in MeGUI.

Anyway, piping the input in from a separate 32-Bit process should only be a temporary workaround until 64-Bit Avisynth becomes more widespread.

Piping has some overhead, at least on the Windows platform...

[lexor]

That shouldn't be too hard to implement in MeGUI.

Anyway, piping the input in from a separate 32-Bit process should only be a temporary workaround until 64-Bit Avisynth becomes more widespread.

Piping has some overhead, at least on the Windows platform...

I thought the problem was not so much Avisynth as it was with the filters (as squid_80 lamented). So I think this method will still be preferred for a long time.

[LoRd_MuldeR]

I thought the problem was not so much Avisynth as it was with the filters (as squid_80 lamented). So I think this method will still be preferred for a long time.

Well, the more people use 64-Bit Avisynth, the more Plugin developers will release 64-Bit Plugins, hopefully...

[Rodger]

HUGE problem for me....a good deinterlacer that would work with avisynth64 (equal to yadif).

[kemuri-_9]

i use avisynth x86 to filter and create a lossless usually in either LAGS or FFVH,
and then open up the lossless with avisynth x64 to pass down to x264 without the need of piping.

my filtering is generally too slow to pass down to x264 directly anyway.

[Rodger]

latest Avisynth64 realease is still the "old one" from squid80?
http://members.optusnet.com.au/squid_80/

[paulvdb]

As far as I know that is still the latest Avisynth64. And the filters there are probably also the only 64 bit filters. At least I'm not aware of any other 64 bit avisynth filters. But then again I haven't really looked for them because squid80's page has all the filters that I normally use.

[TL0]

Did the most recent regression affect the output of first pass stats files, or was it only a minor bug for final pass only?
Does deblocking even matter for first pass stats file?

- Fix regression in r1085
Deblocking was very slightly incorrect with partitions=all.
Bug found by BugMaster.

[Dark Shikari]

Did the most recent regression affect the output of first pass stats files, or was it only a minor bug for final pass only?Final pass only.

[TL0]

Final pass only.

ok, did it cause any possible visual problems with video encoded by versions of x264 with the regression?

My encodes seemed ok from quick scanning but i have not watched them thoroughly.

[skystrife]

x264 r1115 (unpatched) (http://www.mediafire.com/?oy5yjtm1ohi) - Alternate Download (http://skystrife.com/x264/revision1115/x264.exe)
gcc 4.3.4 fprofiled build.

-------------------------

x264.1115M.x86.exe (http://www.mediafire.com/?diuz5nlnmzm) - Alternate Download (http://skystrife.com/x264/x264.1115M.x86.exe) / x264.1115M.x64.exe (http://www.mediafire.com/?zmanrjhgjzw) - Alternate Download (http://skystrife.com/x264/x264.1115M.x64.exe)
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff

[squid_80]

Why do the x64 builds produce non-identical output to the x86 builds?

[Dark Shikari]

Why do the x64 builds produce non-identical output to the x86 builds?I'm going to guess miscompilation, since nothing else makes any sense. This doesn't surprise me given the thread earlier about GCC 4.x miscompiling x264 (reverting to GCC 3.x fixed it).

[kemuri-_9]

I'm going to guess miscompilation, since nothing else makes any sense. This doesn't surprise me given the thread earlier about GCC 4.x miscompiling x264 (reverting to GCC 3.x fixed it).

there's also the fpmath instruction difference that was pointed out a while back by BugMaster in the channel.

when AQ was active, there were several setting sets in which the x86 and x64 generate different binary output.

[LoRd_MuldeR]

Is x264 expected to give identical output for several encodes (with same settings and same source) at all ???

I thought it was mentioned before that there are some indeterministics in the code that make the output slightly different each run...

[Sagekilla]

Threads does make x264 -slightly- non deterministic I believe, but in most cases you can run an encode several dozen times and it will always come out the same.

I tried encoding the same source over and over with --threads auto (=3 threads for me) and the video came out bit-for-bit identical each time.

[LoRd_MuldeR]

I just ran three encodes with 6 threads (--threads auto) and I got three different results:

File Size MD5
test1.mkv 9.358.442 27b48fb76fddcf53183f9c2bb551504b
test2.mkv 9.358.953 46c67e8a40b58c6d78684d4e5b962eb0
test3.mkv 9.358.953 9101a2a8d893ab9689278c75b9aed4ac

Of course the settings were the same. The source is uncompressed YUV samples.

---[EDIT]---

Here some more encodes, this time with only one singly thread:

File Size MD5
test4.mkv 9.322.321 b24840bd6b744c92f01cb8c43246d2bc
test5.mkv 9.322.321 d99a654ad7c544e9aa9e283222ecef6c
test6.mkv 9.322.321 eed5a710ba529b901c433d65d168ab88

This time all files have got the same size, at least. But still not bit-identical.

---[EDIT_2]---

Okay, it seems the container has some random data that prevents proper MD5 comparison.

I now extracted the streams:

File Size MD5

test1.264 9.292.324 1708e8e3a66c551bd4182a5df01f299c
test2.264 9.292.835 338aea99dc8381f3e10606c8dd193b96
test3.264 9.292.835 338aea99dc8381f3e10606c8dd193b96

test4.264 9.256.262 88b8dd3f984f7a2b4e1e0aff9589dcdc
test5.264 9.256.262 88b8dd3f984f7a2b4e1e0aff9589dcdc
test6.264 9.256.262 88b8dd3f984f7a2b4e1e0aff9589dcdc

[squid_80]

I tested with --threads 1 and still get non-identical results. Also since --non-deterministic is a CLI option I would assume the default behaviour is deterministic/repeatable, but I guess Dark Shikari will have to confirm that.
(I am using avs2yuv piped to x264, so the source is identical.)

[Dark Shikari]

there's also the fpmath instruction difference that was pointed out a while back by BugMaster in the channel.

when AQ was active, there were several setting sets in which the x86 and x64 generate different binary output.Ah yes, that as well.

Per the above, x264 is supposed to be exactly deterministic when not using threads. If it isn't, in my experience, it's almost always the fault of some nondeterministic decoder/filter (e.g. using AddGrain in FFDshow).

[MasterNobody]

And with threads it is deterministic while you don't use VBV, --nr and --non-deterministic options.

[imk]

x264.r1115M.SSE2.x32.imk.exe (http://imk.cx/pc/x264/x264.r1115M.SSE2.x32.imk.exe)
x264.r1115M.SSE2.x32.mp4.imk.exe (http://imk.cx/pc/x264/x264.r1115M.SSE2.x32.mp4.imk.exe)
x264.r1115M.SSSE3.x32.imk.exe (http://imk.cx/pc/x264/x264.r1115M.SSSE3.x32.imk.exe)
x264.r1115M.SSSE3.x32.mp4.imk.exe (http://imk.cx/pc/x264/x264.r1115M.SSSE3.x32.mp4.imk.exe)

x264.r1115M.SSE2.x64.imk.exe (http://imk.cx/pc/x264/x264.r1115M.SSE2.x64.imk.exe)
x264.r1115M.SSE2.x64.mp4.imk.exe (http://imk.cx/pc/x264/x264.r1115M.SSE2.x64.mp4.imk.exe)
x264.r1115M.SSSE3.x64.imk.exe (http://imk.cx/pc/x264/x264.r1115M.SSSE3.x64.imk.exe)
x264.r1115M.SSSE3.x64.mp4.imk.exe (http://imk.cx/pc/x264/x264.r1115M.SSSE3.x64.mp4.imk.exe)

x264.r1115.SSE2.linux.static.x64.imk.lzma (http://imk.cx/pc/x264/x264.r1115.SSE2.linux.static.x64.imk.lzma)
x264.r1115.SSSE3.linux.static.x64.imk.lzma (http://imk.cx/pc/x264/x264.r1115.SSSE3.linux.static.x64.imk.lzma)

I changed my build environment from just using the command prompt to using cygwin. It's a pretty different environment, so issues might arise from this.

The Linux binaries can be extracted with unlzma.

Older builds, build scripts, information, etc. can all be found here (http://imk.cx/pc/x264/).

[techouse]

What's the point of making linux binaries?!

[Dark Shikari]

What's the point of making linux binaries?!Most people don't have ICC?

[techouse]

AFAIK ICC for Linux is free for non-commercial use, but yeah I see your point.

@imk: Why not use gzip or bzip2 instead of lzma?

[imk]

lzma has better compression. :)

[LoRd_MuldeR]

lzma has better compression. :)

7-Zip?

[imk]

lzma is what 7-zip uses. I actually get better compression using lzma directly rather than 7z. I'm guessing there's some kind of overhead to 7z? You can open .lzma inside of 7-Zip, too.

[LoRd_MuldeR]

lzma is what 7-zip uses. I actually get better compression using lzma directly rather than 7z. I'm guessing there's some kind of overhead to 7z? You can open .lzma inside of 7-Zip, too.

I know. In fact 7-Zip is the reference implementation of LZMA. That's why I suggested using 7-Zip.

7-Zip archives are very common these days on all platforms, while "raw" .lzma files are not so much...

[imk]

Well, lzma just has a very nice feel to it on linux, just like bzip2.

lzma -9 file
unlzma file.lzma
tar cf - directory | lzma -9 > file.tar.lzma

;)

[Ranguvar]

Tar v1.20 and up has LZMA support built-in. Also, there's a new 'standard' extension for LZMA tar archives: .tar.xz.

[imk]

Tar v1.20 and up has LZMA support built-in. Also, there's a new 'standard' extension for LZMA tar archives: .tar.xz.

Yay, confusion in formats.

It looks like the lzma-utils git changed their tool name to xz to coincide with the extension and format change.

http://tukaani.org/xz/

It took me a second to find where lzma support was at in tar. It's not listed in the manpage, but the switch is -J.

I don't see any support for xz in tar yet, but there is a patch online to add support for it.

[Guest]

Gents, please stay on topic for the thread.

[gigah72]

is it just me or do others also have problem applying x264_hrd_pulldown.09_interlace.diff to latest revisions?

[LoRd_MuldeR]

is it just me or do others also have problem applying x264_hrd_pulldown.09_interlace.diff to latest revisions?

Not surperising with the major changes in r1117:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=3e4946f305317856ed79e0898f25f10859df22ed

Wait for an updated version of the patch...

[Trahald]

must be really recent. 1114 patched ok for me. i'll get on it.

[Trahald]

Ok.. fixed. attached is x264_hrd_pulldown.10_interlace.diff.txt

[imk]

x264.r1120M.SSE2.x32.imk.exe (http://imk.cx/pc/x264/x264.r1120M.SSE2.x32.imk.exe)
x264.r1120M.SSE2.x32.mp4.imk.exe (http://imk.cx/pc/x264/x264.r1120M.SSE2.x32.mp4.imk.exe)
x264.r1120M.SSSE3.x32.imk.exe (http://imk.cx/pc/x264/x264.r1120M.SSSE3.x32.imk.exe)
x264.r1120M.SSSE3.x32.mp4.imk.exe (http://imk.cx/pc/x264/x264.r1120M.SSSE3.x32.mp4.imk.exe)

x264.r1120M.SSE2.x64.imk.exe (http://imk.cx/pc/x264/x264.r1120M.SSE2.x64.imk.exe)
x264.r1120M.SSE2.x64.mp4.imk.exe (http://imk.cx/pc/x264/x264.r1120M.SSE2.x64.mp4.imk.exe)
x264.r1120M.SSSE3.x64.imk.exe (http://imk.cx/pc/x264/x264.r1120M.SSSE3.x64.imk.exe)
x264.r1120M.SSSE3.x64.mp4.imk.exe (http://imk.cx/pc/x264/x264.r1120M.SSSE3.x64.mp4.imk.exe)

x264.r1120.SSE2.linux.static.x264.imk.xz (http://imk.cx/pc/x264/x264.r1120.SSE2.linux.static.x264.imk.xz)
x264.r1120.SSSE3.linux.static.x264.imk.xz (http://imk.cx/pc/x264/x264.r1120.SSSE3.linux.static.x264.imk.xz)

Older builds, build scripts, information, etc. can all be found here (http://imk.cx/pc/x264/).


Edit:
Added links to the Linux binaries. These were built with a newer version of ICC (v11.0.081).
Tar v1.22 came out today supporting xz (-J flag). You'll need XZ Utils (http://tukaani.org/xz/) to extract.

[skystrife]

x264 r1120 (unpatched) (http://www.mediafire.com/?ocvwzcdyi0l) - Alternate Download (http://skystrife.com/x264/revision1120/x264.exe)
gcc 4.3.4 fprofiled build.

-------------------------

x264.1120M.x86.exe (http://www.mediafire.com/?bmd2nyxwmth) - Alternate Download (http://skystrife.com/x264/x264.1120M.x86.exe) / x264.1120M.x64.exe (http://www.mediafire.com/?jmmhd3ymr2z) - Alternate Download (http://skystrife.com/x264/x264.1120M.x64.exe)
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.10_interlace.diff
x264_win_zone_parse_fix_05.diff

[ACrowley]

I used the 1120 Build from techhouse

But i get unrecognised option `--nal-hrd' with this build ?

I was working before 1120 ? i changed nothing instead the x264 Build

It failed in 1st pass :
--pass 1 --bitrate 6500 --stats "F:\Tatort.HDTV\Tatort.Der.Tote.Chinese.HDTV.stats" --level 4.1 --keyint 24 --min-keyint 2 --bframes 3 --b-adapt 2 --weightb --direct auto --deblock -1:-1 --subme 2 --partitions none --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 16500 --vbv-maxrate 16500 --qcomp 0.5 --me dia --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output NUL "F:\Tatort.HDTV\Tatort.Der.Tote.Chinese.HDTV.avs" --mvrange 511 --aud --nal-hrd --sar 1:1

I think it has to do with the patched x264_hrd_pulldown.10_interlace.diff ? Has the Commande for the HRD Flag changed ?

EDIT:
mhh it works with x264 rev1120 from skystrifes. Only techhouse x264 1120 Build doenst recognize `--nal-hrd' anymore

[Trahald]

hmm.. i tried techouse's x86 1120 and its fine. didnt try the x64

[ACrowley]

hmm.. i tried techouse's x86 1120 and its fine. didnt try the x64

i use the x68 Build too it doesnt work here
I use megui with the standalone AVCHD Profile (litte bit modified)

EDIT.
jesus im a Idiot!

I used the x64 Build! So i got a error
Works fine ofcourse with x86 Build!
Sorry for this stupid post!

Other Question :
The x264 Builds from skystrife are also fully patched with all new Features as the Builds fromTechhouse are, correct ?
Maybe i should enable autoupdate in megui for x264 instead of manually downloading the techhouse Builds

[Sharktooth]

The x264 Builds from skystrife are also fully patched with all new Features as the Builds fromTechhouse are, correct ?
the skystrife's patched builds are the builds i upload in the megui auto-update server... so, yes, NAL-HRD patch is included as well as zones parse fix.
Maybe i should enable autoupdate in megui for x264 instead of manually downloading the techhouse Builds
that would be wise...

[techouse]

Mea culpa, mea maxima culpa. I forgot to add the hrd patch to my build initially but I fixed it now. Should be working now ;) Everyone that downloaded my r1120 builds prior to 22:00 CET, please re-download.

[video_magic]

Techouse
Your link to the info text at least on the nwgat mirror is wrong. It points to:
http://x264.nwgat.net/x264_x6x264_x64_r1120_techouse.txt

[techouse]

Techouse
Your link to the info text at least on the nwgat mirror is wrong. It points to:
http://x264.nwgat.net/x264_x6x264_x64_r1120_techouse.txt
I'm not the maintainer of that mirror. :(

[techouse]

I've noticed a very funny thing regarding the ICC builds. In the task manager it shows the ICC built x264.exe using 50% of the entire CPU (probably core no. 1) and svchost.exe using another 50% of the CPU (probably core no. 2). Both use the equal amount of RAM, so I guess the process is split. Another funny thing with this is, that x264.exe is run by the USER while svchost.exe is run by the SYSTEM.

As I am used to using GCC builds, where a single x264.exe run by the USER uses the whole CPU and has only 1 RAM pool, this leaves me wondered.

Here's a pic of the taskmanager processes.
http://www.shrani.si/t/3E/XG/3T2e4Utx/x264icc.jpg (http://www.shrani.si/f/3E/XG/3T2e4Utx/x264icc.png)

OS: Windows Vista Business x64 SP1
CPU: Intel Core 2 Duo E6600 @ 2.4 GHz
RAM: 2 GB

[imk]

This seems to be a very awkward thing with your system?

I can run my builds and svchost never raises in CPU usage. x264 will use 100% (using all cores on its own).

Grab Process Explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx). You can see what inside of the svchost is using CPU.

[techouse]

I used x264.r1120M.SSSE3.x64.mp4.imk.exe, avs2yuv-0.24 and an AVS with avisource(HuffYUV.avi) in that example.

[G_M_C]

I used x264.r1120M.SSSE3.x64.mp4.imk.exe, avs2yuv-0.24 and an AVS with avisource(HuffYUV.avi) in that example.

Avisynth + avs2yuv (one or both on svchost) and x264 on the other core ?

[...]
I can run my builds and svchost never raises in CPU usage. x264 will use 100% (using all cores on its own).
[...]


Works like that for me too on XP/32bits / SP3.

[techouse]

Seems it was some sort of false alarm, cause now everything works just fine (same setup as mentioned above)... The strange thing was, that even though x264.exe was using only 50% of the CPU it had 99% the exact FPS as a GCC built x264.exe.

http://www.shrani.si/t/1t/vQ/4Ymfcwlb/lolwut.jpg (http://www.shrani.si/f/1t/vQ/4Ymfcwlb/lolwut.png)http://www.shrani.si/t/3I/ew/1zxXLZGi/pe.jpg (http://www.shrani.si/f/3I/ew/1zxXLZGi/pe.png)http://www.shrani.si/t/2k/P7/1Vzr7DGt/thread.jpg (http://www.shrani.si/f/2k/P7/1Vzr7DGt/thread.png)

P.S.: The FPS remains the same as to when x264.exe was using only 50% of the CPU and svchost.exe was using the other 50%. Strange....

[squid_80]

Is it just me or is there a typo in the hrd_pulldown patch:
--pulldown <integer> Use 3:2 pulldown
- 32: TBT,BT,BTB,BT pattern
- 64: triple,double *recommended for 720p
Shouldn't it be TBT, BT, BTB, TB ?

[skystrife]

x264 r1123 (unpatched) (http://www.mediafire.com/?t0md1ywdonr) - Alternate Download (http://skystrife.com/x264/revision1123/x264.exe)
gcc 4.3.4 fprofiled build.

-------------------------

x264.1123M.x86.exe (http://www.mediafire.com/?okmit0qnmln) - Alternate Download (http://skystrife.com/x264/x264.1123M.x86.exe) / x264.1123M.x64.exe (http://www.mediafire.com/?qcyyt2tjg2n) - Alternate Download (http://skystrife.com/x264/x264.1123M.x64.exe)
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.10_interlace.diff
x264_win_zone_parse_fix_05.diff

[bob0r]

x264.nl: 08-03-09: x264 64bit is now auto mirrored, using (skystrife's) builds

skystrife's unpatched 64bit builds are now being automatically mirrored via a http2ftp script!

[skystrife]

x264 r1125 (unpatched) (http://www.mediafire.com/?nawjci5wjy2) - Alternate Download (http://skystrife.com/x264/revision1125/x264.exe)
gcc 4.3.4 fprofiled build.

-------------------------

x264.1125M.x86.exe (http://www.mediafire.com/?aigfyu1dtjf) - Alternate Download (http://skystrife.com/x264/x264.1125M.x86.exe) / x264.1125M.x64.exe (http://www.mediafire.com/?jm2nehiymzk) - Alternate Download (http://skystrife.com/x264/x264.1125M.x64.exe)
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.10_interlace.diff
x264_win_zone_parse_fix_05.diff

[techouse]

x264_x86_r1127_techouse (http://techouse.project357.com/builds/x264_x86_r1127_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1127_techouse.txt)
GCC 4.3.3, fprofiled, -march=core2

x264_x64_r1127_techouse (http://techouse.project357.com/builds/x264_x64_r1127_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1127_techouse.txt)
GCC 4.3.4 20090220 (prerelease) (x64.generic.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.10_interlace.diff
x264_win_zone_parse_fix_05.diff

[d0ORk]

Hi, I tried the 64bit version with my Vista 64bit but I'm always getting: x264 [error]: could not open input file 'x:\my.avs'

I works fine with the 32bit version. What could that be? :scared:

[ajp_anton]

Your avisynth is 32-bit.

[nm]

Install 64-bit AviSynth: http://members.optusnet.com.au/squid_80/

[kemuri-_9]

if you do any processing in that avisynth script that isn't supported by the available list of avisynth x64 plugins, you're gonna need to pipe from avs2yuv.

[skystrife]

x264 r1127 x64 (unpatched) (http://www.mediafire.com/?zgwnmwyknxz) - Alternate Download (http://skystrife.com/x264/revision1127/x264.exe)
gcc 4.3.4 fprofiled build.

-------------------------

x264.1127M.x86.exe (http://www.mediafire.com/?jzkwtyz2lu2) - Alternate Download (http://skystrife.com/x264/x264.1127M.x86.exe) / x264.1127M.x64.exe (http://www.mediafire.com/?htmdtmdmlm2) - Alternate Download (http://skystrife.com/x264/x264.1127M.x64.exe)
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.10_interlace.diff
x264_win_zone_parse_fix_05.diff

[puffpio]

is there much of a difference w/ -march=pentium2 vs core2?

and for the 64 bit version, shouldn't the minimum -march be k8 or nocona?

[LoRd_MuldeR]

is there much of a difference w/ -march=pentium2 vs core2?

Nope. Most (all?) performance-critical functions in x264 are written as hand-optimized assembler code.

x264 will detect your CPU capabilities at runtime and it will choose the optimized assembler functions accordingly.

Compiler optimizations matter for the pure C code only...

[komisar]

LoRd_MuldeR, sure, but if gcc-libs compiled with -march -- we get ~1-5 more fps...

puffpio, little latter i compile x264 for generic (pentium2), k8, core2. Minimum for x86_64 -- "-mtune=generic" (without march)

[Dark Shikari]

LoRd_MuldeR, sure, but if gcc-libs compiled with -march -- we get ~1-5 more fps...Yes, because of cmov.

[akupenguin]

1-5 more fps
1-5 out of what? There's a big difference between gaining 5fps if it was 1 before, vs gaining 5 from 1000.
No one should ever post any speed results in the form of a diff without a baseline. The only valid forms are ratios.

[vmrsss]

hi everybody.

In theme of speed differences, would there be much using gcc-4-2.1 rather than gcc-4.3.3 for x86_64? (For -march=core2 rather than nothing I assume the answer is above, that is a few fps due do cmov)

In general, how would I go about timing one build of x264 against another?

Thx.

[vmrsss]

PS. What does make fprofiled do for you?

[J_Darnley]

1 - On nix: use time or modify x264 to print the time
On Windows: modify x264 to print the time

[imk]

r1127M ICC Builds:

SSE2 x32 (http://imk.cx/pc/x264/x264.r1127M.SSE2.x32.imk.exe) (w/MP4 Output (http://imk.cx/pc/x264/x264.r1127M.SSE2.x32.mp4.imk.exe))
SSSE3 x32 (http://imk.cx/pc/x264/x264.r1127M.SSSE3.x32.imk.exe) (w/MP4 Output (http://imk.cx/pc/x264/x264.r1127M.SSSE3.x32.mp4.imk.exe))

SSE2 x64 (http://imk.cx/pc/x264/x264.r1127M.SSE2.x64.imk.exe) (w/MP4 Output (http://imk.cx/pc/x264/x264.r1127M.SSE2.x64.mp4.imk.exe))
SSSE3 x64 (http://imk.cx/pc/x264/x264.r1127M.SSSE3.x64.imk.exe) (w/MP4 Output (http://imk.cx/pc/x264/x264.r1127M.SSSE3.x64.mp4.imk.exe))


Older builds, build scripts, information, etc. can all be found here (http://imk.cx/pc/x264/).

[LoRd_MuldeR]

PS. What does make fprofiled do for you?

It will analyze the code in execution and then apply additional optimizations.

Since "make fprofiled" will encode the specified video clip several time (to cover all x264 options/codepaths) it will take much longer to build...

http://en.wikipedia.org/wiki/Profiler_(computer_science)

[vmrsss]

Thx. What criteria are useful when picking the video clips to feed make fprofiled?

[LoRd_MuldeR]

Thx. What criteria are useful when picking the video clips to feed make fprofiled?

I think you should pick something that equals the kind of video that you are going to encode. A few hundred frames should be enough.

Choosing a "synthetic" clip, like solid black or random noise, wouldn't give optimal profiling results, I guess...

[skystrife]

x264 r1128 x64 (unpatched) (http://www.mediafire.com/?wnjg5utuzin) - Alternate Download (http://skystrife.com/x264/revision1128/x264.exe)
gcc 4.3.4 fprofiled build.

-------------------------

x264.1128M.x86.exe (http://www.mediafire.com/?mytyyrkwchg) - Alternate Download (http://skystrife.com/x264/x264.1128M.x86.exe) / x264.1128M.x64.exe (http://www.mediafire.com/?mmzmmmmnmxt) - Alternate Download (http://skystrife.com/x264/x264.1128M.x64.exe)
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.10_interlace.diff
x264_win_zone_parse_fix_05.diff

[techouse]

x264_x86_r1129_techouse (http://techouse.digitalpulse.us/builds/x264_x86_r1129_techouse.7z) | INFO (http://techouse.digitalpulse.us/nfo/x264_x86_r1129_techouse.txt)
GCC 4.3.3, fprofiled, -march=core2

x264_x64_r1129_techouse (http://techouse.digitalpulse.us/builds/x264_x64_r1129_techouse.7z) | INFO (http://techouse.digitalpulse.us/nfo/x264_x64_r1129_techouse.txt)
GCC 4.3.4 20090220 (prerelease) (x64.generic.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.10_interlace.diff
x264_win_zone_parse_fix_05.diff

[Kurtnoise]

Patches used:

x264_hrd_pulldown.10_interlace.diff
x264_win_zone_parse_fix_05.diff
can I have a link for those, please ?

[LoRd_MuldeR]

can I have a link for those, please ?

http://forum.doom9.org/showpost.php?p=1257673&postcount=1726
http://forum.doom9.org/showpost.php?p=1230476&postcount=1535

:search:

[Sharktooth]

Request: updated skystrife's builds.

[Trahald]

Here is the HRD patch release 11. I rewrote most of the calculations . Because most/all the values calculations are changed, i'd consider 11 an alpha until its been around a bit.

[squid_80]

Still looks like it's got a typo to me (TBT,BT,BTB,BT).

[Trahald]

Still looks like it's got a typo to me (TBT,BT,BTB,BT).

HAH. now fixed.

[bob0r]

Request: updated skystrife's builds.

Hmm, still not active.
Maybe we can use techouse's builds? Or someone else can make them?

Also i would need x264 64bit (gpac/pthreads also 64bit) + fprofiled on the same 64bit system.
If someone can do this, all you need to do is host them on http. Example: http://yourdomain.com/x264/revisionXXXX/
Files inside revisionXXXX should be x264.exe and x264.md5
( To create the md5 for x264.nl: md5sum x264.exe | awk '{print $1}' >x264.md5 )

Then my mirror script checks for the x264.md5 file every hour and mirror it then)

[LoRd_MuldeR]

Why you worry so much? You have a r1128 build up and the differences between r1128 and r1129 are very minor...

[techouse]

Hmm, still not active.
Maybe we can use techouse's builds? Or someone else can make them?

Also i would need x264 64bit (gpac/pthreads also 64bit) + fprofiled on the same 64bit system.
If someone can do this, all you need to do is host them on http. Example: http://yourdomain.com/x264/revisionXXXX/
Files inside revisionXXXX should be x264.exe and x264.md5
( To create the md5 for x264.nl: md5sum x264.exe | awk '{print $1}' >x264.md5 )

Then my mirror script checks for the x264.md5 file every hour and mirror it then)
Sure, you can use mine :) I build&profile them on Vista x64, but i'm not sure how you want me to host the builds on my servers.

Cheers ;)

[techouse]

x264_x86_r1130_techouse (http://techouse.project357.com/builds/x264_x86_r1130_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1130_techouse.txt)
GCC 4.3.3, fprofiled, -march=core2

x264_x64_r1130_techouse (http://techouse.project357.com/builds/x264_x64_r1130_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1130_techouse.txt)
GCC 4.3.4 20090220 (prerelease) (x64.generic.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.11_interlace.diff
x264_win_zone_parse_fix_05.diff



P.S.: I put md5 checksums in the 7-Zip files this time ;)

[Trahald]

@techouse Your x64 link links to the x86 file and vice versa

[techouse]

@techouse Your x64 link links to the x86 file and vice versaThanx! I am in a hurry cause I've got a train to catch.... ttyl ;)

[bob0r]

Sure, you can use mine :) I build&profile them on Vista x64, but i'm not sure how you want me to host the builds on my servers.

Cheers ;)

Very simple: Build x264 64bit (gpac/pthreads 64bit also) from git only, no patches... fprofiled.
And then put the files on any http host, as long as you create the dir: revision1130 with inside x264.exe and x264.md5

so example:
http://techouse.project357.com/builds/revision1130/x264.exe
http://techouse.project357.com/builds/revision1130/x264.md5
Then all i have to do is edit:
fixedurl=http://techouse.project357.com/builds/revision in my script and the files get mirrored to x264.nl.

You can also sent me a private http link if bandwidth is an issue (or ill create a host for you, but i think we have no problems with bandwidth :))

[techouse]

Very simple: Build x264 64bit (gpac/pthreads 64bit also) from git only, no patches... fprofiled.
And then put the files on any http host, as long as you create the dir: revision1130 with inside x264.exe and x264.md5

so example:
http://techouse.project357.com/builds/revision1130/x264.exe
http://techouse.project357.com/builds/revision1130/x264.md5
Then all i have to do is edit:
fixedurl=http://techouse.project357.com/builds/revision in my script and the files get mirrored to x264.nl.

You can also sent me a private http link if bandwidth is an issue (or ill create a host for you, but i think we have no problems with bandwidth :))OK, I'll do it as soon as I get to the campus ;) (that's tomorrow somewhere around 23:00 CET)

P.S.: Do you only need 64bit or both?

[bob0r]

...

P.S.: Do you only need 64bit or both?


Only 64bit, the x264.nl compile system is 32bit.

[techouse]

Only 64bit, the x264.nl compile system is 32bit.Sorry it took so long, but I had some work with tax reports. Anyway, I'll be on the campus around 12:00 CEST, so expect the build somewhere around 13:00 CEST.

Here you go:

http://techouse.project357.com/builds/revision1134/x264.exe
http://techouse.project357.com/builds/revision1134/x264.md5

(unpatched generic & fprofiled 64bit build, GCC 4.3.4 20090220 (prerelease) (x64.generic.Komisar))

[techouse]

x264_x86_r1134_techouse (http://techouse.project357.com/builds/x264_x86_r1134_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1134_techouse.txt)
GCC 4.3.3, fprofiled, -march=core2

x264_x64_r1134_techouse (http://techouse.project357.com/builds/x264_x64_r1134_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1134_techouse.txt)
GCC 4.3.4 20090220 (prerelease) (x64.generic.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.11_interlace.diff
x264_win_zone_parse_fix_05.diff

[Betsy25]

Didn't x264 use all cores by default then ? :confused:

[LoRd_MuldeR]

Didn't x264 use all cores by default then ? :confused:

No, it doesn't and it never did! The default setting is "--threads 1" (that is: multi-threading = OFF).
To use multiple cores, you must either set "--threads auto" or manually specify "--threads n", where n = cores * 3/2.

[ajp_anton]

To use multiple cores, you must either set "--threads auto" or manually specify "--threads n", where n = cores * 3/2.

"--threads auto" = "--threads 0" = "--threads [cores*3/2]"
However, you can specify whatever number you want (you make it sound you *need* cores*3/2 =))

[Betsy25]

"--threads auto" = "--threads 0" = "--threads [cores*3/2]"
However, you can specify whatever number you want (you make it sound you *need* cores*3/2 =))

So, you actually replace an application that could please everyone with some that puts a lot of people in the bare cold ?

[Astrophizz]

I would guess that anyone who wouldn't know about the command line settings would be using a frontend, which would most likely set threads to auto.

[LoRd_MuldeR]

I would guess that anyone who wouldn't know about the command line settings would be using a frontend, which would most likely set threads to auto.

Exactly. If people use x264 from the commandline, they should be intelligent enough to type "x264 --help" and read :sly:

For the average user, who doesn't want to learn about CLI parameters, we have dozens of GUI's available...

[Betsy25]

Exactly. If people use x264 from the commandline, they should be intelligent enough to type "x264 --help" and read :sly:

For the average user, who doesn't want to learn about CLI parameters, we have dozens of GUI's available...

Is there actually anything positive about this change ? By removing the --threads option, does the program run faster ? Anything we don't know ? Or is it just some april fools release ?

[Dark Shikari]

Is there actually anything positive about this change ? By removing the --threads option, does the program run faster ? Anything we don't know ? Or is it just some april fools release ?I have no idea what you're talking about.

[LoRd_MuldeR]

Is there actually anything positive about this change ? By removing the --threads option, does the program run faster ? Anything we don't know ? Or is it just some april fools release ?

What change are you talking about? The "--threads n" parameter works like described above ever since x264 got the ability to do multi-threading.

At least it didn't change in the last ~2 years. And of course that parameter was not removed recently...

[nm]

Didn't x264 use all cores by default then ? :confused:
Are you referring to "-march=core2" in techouse's post? That GCC switch enables compiler optimizations for Intel Core 2 processor architecture. It has nothing to do with multithreading.

[Betsy25]

Are you referring to "-march=core2" in techouse's post? That GCC switch enables compiler optimizations for Intel Core 2 processor architecture. It has nothing to do with multithreading.

Exactly, I was talking about that one. Sorry for the confusion, oh I'm just a newb.:(

[LoRd_MuldeR]

Exactly, I was talking about that one. Sorry for the confusion, oh I'm just a newb.:(

Then please don't mix up compiler switches and x264 switches:
Compiler switches are used when you are building x264, while x264 switches are used when you are running x264.
As a normal user you only need to worry about the latter ones ;)

Some more info can be found here:
http://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping

[skystrife]

x264 r1134 x64 (unpatched) (http://www.mediafire.com/?ntkgqriintz) - Alternate Download (http://skystrife.com/x264/revision1134/x264.exe)
gcc 4.3.4 fprofiled build.

-------------------------

x264.1134M.x86.exe (http://www.mediafire.com/?ygwnybz3gy3) - Alternate Download (http://skystrife.com/x264/x264.1134M.x86.exe) / x264.1134M.x64.exe (http://www.mediafire.com/?wydznnmomma) - Alternate Download (http://skystrife.com/x264/x264.1134M.x64.exe)
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.11_interlace.diff
x264_win_zone_parse_fix_05.diff

[ajp_anton]

Then please don't mix up compiler switches and x264 switches:
Compiler switches are used when you are building x264, while x264 switches are used when you are running x264.
As a normal user you only need to worry about the latter ones ;)As a normal used he doesn't need to worry about either of them =)

BTW... maybe it was just a dream, but wasn't --thread-input made automatically active some time ago? And if not, is there any reason not to?

[techouse]

I think --thread-input is automatically active if you use --threads auto. Correct me if I'm wrong.


P.S.: LoL @ that Core2 confusion :D

[techouse]

Can anyone please run a stability test this build on AMD64 and Core2? Thanx!

http://techouse.project357.com/builds/revision1136/x264.exe
http://techouse.project357.com/builds/revision1136/x264.md5

(unpatched generic & fprofiled 64bit build, GCC 4.3.4 20090328 (prerelease) (x64.generic.Komisar))

[Sharktooth]

I think --thread-input is automatically active if you use --threads auto. Correct me if I'm wrong.
true.

[Egh]

No, it doesn't and it never did! The default setting is "--threads 1" (that is: multi-threading = OFF).
To use multiple cores, you must either set "--threads auto" or manually specify "--threads n", where n = cores * 3/2.

any explanation regarding why the best parameter is 1.5 threads per core? Seems totally random to me, though I discovered that myself (still seems pathetic to me when 2 threads x264 takes only about 70% of two-core cpu and that's with high priority ;)

[LoRd_MuldeR]

any explanation regarding why the best parameter is 1.5 threads per core? Seems totally random to me, though I discovered that myself (still seems pathetic to me when 2 threads x264 takes only about 70% of two-core cpu and that's with high priority ;)

Because testing showed that "threads = 3/2 * cores" works best. And that finding doesn't seem to be random at all ;)

The intuitive solution "threads = cores" would only give optimal performance if no thread ever becomes idle (needs to wait for another thread).

[Egh]

Because testing showed that "threads = 3/2 * cores" works best. And that finding doesn't seem to be random at all ;)

The intuitive solution "threads = cores" would only give optimal performance if no thread ever becomes idle (needs to wait for another thread).

still random. nearly 25% cpu% loss (total % for both cores) just with 2 threads instead of 3. With the same .bat file of course. So you effectively imply in this scenario either one thread is idle 50% of time of both threads idle 25% of time. Suboptimal?

[LoRd_MuldeR]

still random. nearly 25% cpu% loss (total % for both cores) just with 2 threads instead of 3. With the same .bat file of course. So you effectively imply in this scenario either one thread is idle 50% of time of both threads idle 25% of time. Suboptimal?

I don't imply anything. I just say that in a "real life" application you cannot assume that threads are working 100% independently of each other. Threads need to synchronize now and then! And that means that any thread unavoidably will have some idle time while waiting for another thread. Also you must keep in mind that the "look ahead" part of x264 is not multi-threaded. Lookahead needs to run each time a new encoder thread is spawned. Now imagine you were running exactly four threads on a quadcore CPU. When the first thread/frame completes, only three encoder threads are left running in parallel. Now lookahead will need to run again before a new thread is spawned. With lookahead and the three encoder thread still all four cores are busy. But if the second thread/frame completes, while lookahead has not completed yet, only two threads are left running in parallel - one CPU core becomes idle. This easily explains why running more encoder threads than cores makes sense. Last but not least the multi-threading in x264 obviously is pretty optimal: When you configure the number of threads properly (cores * 3/2), then x264 will fully utilize a quadcore CPU and give ~4x speed of a single core.

[skystrife]

x264 r1136 x64 (unpatched) (http://www.mediafire.com/?irjnnnnwtmk) - Alternate Download (http://skystrife.com/x264/revision1136/x264.exe)
gcc 4.3.4 fprofiled build.

-------------------------

x264.1136M.x86.exe (http://www.mediafire.com/?znmzz21lnm5) - Alternate Download (http://skystrife.com/x264/x264.1136M.x86.exe) / x264.1136M.x64.exe (http://www.mediafire.com/?nknmwgtgw2t) - Alternate Download (http://skystrife.com/x264/x264.1136M.x64.exe)
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.11_interlace.diff
x264_win_zone_parse_fix_05.diff

[techouse]

x264_x86_r1136_techouse (http://techouse.project357.com/builds/x264_x86_r1136_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1136_techouse.txt)
GCC 4.3.3, fprofiled, -march=core2

x264_x64_r1136_techouse (http://techouse.project357.com/builds/x264_x64_r1136_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1136_techouse.txt)
GCC 4.3.4 20090328 (prerelease) (x64.generic.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.11_interlace.diff
x264_win_zone_parse_fix_05.diff

[burfadel]

According to the GIT, the last patch was added 32 hours ago (faster CABAC RDO), and yet there are no 1137 builds...

www.x264.nl doesn't seem to be autoupdating it, at least quickly?...

[kemuri-_9]

According to the GIT, the last patch was added 32 hours ago (faster CABAC RDO), and yet there are no 1137 builds...

www.x264.nl doesn't seem to be autoupdating it, at least quickly?...

the latest patch wasn't released until 5 hours ago.
the devs often keep the patches locally for testing and only push to the global repository after testing is complete.
however the times are from the local repository, not from the global.

if you want the actual times it hits the global, you can check the x264-devel mailing list for subjects that start with 'commit: '
like r1137 (http://mailman.videolan.org/pipermail/x264-devel/2009-April/005792.html)

as for x264.nl it could either be on hold or there was a problem somewhere.

[skystrife]

x264 r1137 x64 (unpatched) (http://www.mediafire.com/?z3bnxnm1n14) - Alternate Download (http://skystrife.com/x264/revision1137/x264.exe)
gcc 4.3.4 fprofiled build.

-------------------------

x264.1137M.x86.exe (http://www.mediafire.com/?nmdgndqjmzn) - Alternate Download (http://skystrife.com/x264/x264.1137M.x86.exe) / x264.1137M.x64.exe (http://www.mediafire.com/?0gymdznnwtz) - Alternate Download (http://skystrife.com/x264/x264.1137M.x64.exe)
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.11_interlace.diff
x264_win_zone_parse_fix_05.diff

[burfadel]

the latest patch wasn't released until 5 hours ago.
the devs often keep the patches locally for testing and only push to the global repository after testing is complete.
however the times are from the local repository, not from the global.

if you want the actual times it hits the global, you can check the x264-devel mailing list for subjects that start with 'commit: '
like r1137 (http://mailman.videolan.org/pipermail/x264-devel/2009-April/005792.html)

as for x264.nl it could either be on hold or there was a problem somewhere.


Ah ok! that makes sense :)

[3ngel]

I'm getting this on Phenom with latest

x264.1137M.x86.exe --pass 1 --bitrate 1270 --stats ".stats" --progress --keyint 250 --bframes 16 --qpmin 10 --qpmax 51 --aq-mode 0 --psy-rd 0.8:0 --no-psnr --no-ssim --no-fast-pskip --mixed-refs --b-adapt 0 --trellis 2 --ref 9 --no-deblock --subme 7 --direct auto --me umh --merange 32 --nf --weightb --b-pyramid --partitions all --8x8dct --threads auto --thread-input --no-dct-decimate --level 41 --output NUL "t.avs"

Original image size 844*480

Second Pass has identical parameters

Same result with --no-asm too

http://img10.imageshack.us/img10/4880/glitch.png

EDIT:
About the same glitches (not exactly the same) i obtain with previous versions too back to about 1113

These types of glitches are present randomly on all the video

Tested with CoreAVC, MPC Decoder and with MPC, graphedit etc...

[komisar]

3ngel, what/whose build you use? Can you repeat this "bug" with other builds?

[3ngel]

http://skystrife.com/x264/x264.1137M.x86.exe

[kemuri-_9]

post the sample you're encoding so i can do testing on my phenom computers when i get off work.

[akupenguin]

@3ngel
Your artifacts are definitely produced by a median-predicted lossless codec, such as ffvhuff or lagarith. Either a decoder bug or a corrupt bitstream.
mpeg-like codecs do not have failure modes that look like that.

[3ngel]

Mmm... i see.
I've tested the script in VDub before feeding to encoder, and it's a regular not corrupted lagarith. Moreover playing the .avs (and the lags .avi within) all is regular.
Now i'm doing a new encoding.

[Dark Shikari]

I've seen that before as well--in a broken lagarith decode.

[3ngel]

But if it can be a lagarith issue, why i don't see the same in vdub?
Both VDub and avs use the same decoding routine (and i see both fine).

[LoRd_MuldeR]

But if it can be a lagarith issue, why i don't see the same in vdub?
Both VDub and avs use the same decoding routine (and i see both fine).

Try converting your video to HuffYUV or FFv1 in VirtualDub. Then try to feed that into x264...

[3ngel]

Yes, doing that right now (doing uncompressed).

[techouse]

x264_x86_r1137_techouse (http://techouse.project357.com/builds/x264_x86_r1137_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1137_techouse.txt)
GCC 4.3.3, fprofiled, -march=core2

x264_x64_r1137_techouse (http://techouse.project357.com/builds/x264_x64_r1137_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1137_techouse.txt)
GCC 4.3.4 20090408 (prerelease) (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.11_interlace.diff
x264_win_zone_parse_fix_05.diff

[Egh]

Also you must keep in mind that the "look ahead" part of x264 is not multi-threaded. Lookahead needs to run each time a new encoder thread is spawned. Your explanation is very good, however can you describe in more detail how lookahead works? For instance, how much time or cpu% is spent for lookahead thread. As well, how do the things work in non-multithreaded mode, on single core?

[LoRd_MuldeR]

Your explanation is very good, however can you describe in more detail how lookahead works? For instance, how much time or cpu% is spent for lookahead thread.

Read this please:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob_plain;f=doc/threads.txt;h=3777b516117c6a7dc8e4943dcee0386449dc405c;hb=1fda88277f6b2eda27a0f741d58b31532ad0664d

"New threading method: frame-based" is what x264 uses nowadays. For further information you may want to ask a x264 developer :p

As well, how do the things work in non-multithreaded mode, on single core?

I guess it works the same way. Just that only one encoder thread is created at a time.

[3ngel]

Yes, doing that right now (doing uncompressed).

UPDATE
So apparently, it is a lagarith issue, but indeed is a VDub Issue wich corrupt the video doing a "DirectStream Encoding" from an Integral LAGS Video.
So, source lags is intact, you do a "DirectStream" (like to join two lags avis), and the results is a corrupted lags.
So it's ok on x264.

I take the occasion to ask:

Is it possible to add a switch to set the "priority"?
Now everytime i have to go to taskmanager in order to put it in "Below normal" priority (because in normal priority every application is slowed down).

Thank you very much

[kemuri-_9]

Is it possible to add a switch to set the "priority"?
Now everytime i have to go to taskmanager in order to put it in "Below normal" priority (because in normal priority every application is slowed down).

use
start /belownormal x264 [opts]

[komisar]

3ngel, or use patch k.61.x264_thread_priority.02.diff (http://komisar.gin.by/x.patch/k.61.x264_thread_priority.02.diff) with --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]

[3ngel]

@kemuri-_9
Thanks for the suggestion

@komisar
Thanks, is this patch integrated in the link downloadable in the official thread, or alternative builds?

[komisar]

3ngel, I make this patch for my kMod and kVAQmod builds. Also present variant for thread-pool patch by BugMaster.

[Egh]

"New threading method: frame-based" is what x264 uses nowadays. For further information you may want to ask a x264 developer :p

I guess it works the same way. Just that only one encoder thread is created at a time.

Basically that means threads parameter defines only the number of encoding threads, and there can be one additional input thread and the main thread of application as well which does B-adapt and ratecontrol (not sure if that is what you called "look ahead" thread).

Still not sure yet about timing issues, how much time is taken by lookahead and what kind of scenarios are possible regarding any of the threads committing ealier than the rest. As well does really mean that the threads parameter now specifies how many frames are encoded at once? If I specify it as 10, would it try to encode 10 at once?

[Dark Shikari]

As well does really mean that the threads parameter now specifies how many frames are encoded at once? If I specify it as 10, would it try to encode 10 at once?Yes, it would.

[Manao]

3ngel : lagarith creates those broken frames randomly at decoding. You could encode the same file three times and end up with or without broken frames at different places in the encoded files.

[skystrife]

x264 r1139 x64 (unpatched) (http://www.mediafire.com/?yzt1gyyi5ow) - Alternate Download (http://skystrife.com/x264/revision1139/x264.exe)
gcc 4.3.4 fprofiled build.

-------------------------

x264.1139M.x86.exe (http://www.mediafire.com/?oxzioj2vmym) - Alternate Download (http://skystrife.com/x264/x264.1139M.x86.exe) / x264.1139M.x64.exe (http://www.mediafire.com/?idymnzmkk5y) - Alternate Download (http://skystrife.com/x264/x264.1139M.x64.exe)
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.11_interlace.diff
x264_win_zone_parse_fix_05.diff

[TheRyuu]

hi

pm me if you want a build with threaded slicetype

[kemuri-_9]

x264-r1139 (http://sempai-net.com/ss-trainee/x264-r1139.rar)

Experimental build (gcc 4.3.3, fprofiled) with v14 of the threaded slicetype patch.
(x264-r1134-threaded-slicetype-v14.diff)
This is known to seg fault using too many bframes (>=10) or too high a lookahead (see correlation between bframes and lookahead value below)

I wouldn't use this for any 'serious' encoding. ;)

To use 'threaded slicetype':
--lookahead 30 (I guess good starting point, I really have no idea what this value should be but have seen this in the past)

The higher the lookahead you use, the less bframes it will take to seg fault it. :p

I wouldn't go higher than 8 or 30 for bframes or lookahead values respectively.

You shouldn't have posted a build with the patch as it's known to be broken....
it could distribute across the internet without the 'broken under conditions x,y,z' disclaimer and complaints will only build up.
you should wait until it makes the repository....

but... you also forgot to mention that it only seg faults on the above conditions for b-adapt 2... b-adapt 1 should be fine.

[LoRd_MuldeR]

You shouldn't have posted a build with the patch as it's known to be broken....
it could distribute across the internet without the 'broken under conditions x,y,z' disclaimer and complaints will only build up.
you should wait until it makes the repository....

but... you also forgot to mention that it only seg faults on the above conditions for b-adapt 2... b-adapt 1 should be fine.

May I ask what the status of this patch is? Is threaded look-ahead a work in progress is or this more a rejected/suspended patch?

[kemuri-_9]

May I ask what the status of this patch is? Is threaded look-ahead a work in progress is or this more a rejected/suspended patch?

it's a work in progress....
it gets worked on when Mike (DaKaz on irc) has time, which doesn't come around the most often.
the latest version of the patch was v14; that may help with signifying how much progress has gone into it.

from what i understand, it's been mostly having issues on windows, whereas linux has less (if any) problems....

[techouse]

x264_x86_r1139_techouse (http://techouse.project357.com/builds/x264_x86_r1139_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1139_techouse.txt)
GCC 4.3.3, fprofiled, -march=core2

x264_x64_r1139_techouse (http://techouse.project357.com/builds/x264_x64_r1139_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1139_techouse.txt)
GCC 4.3.4 20090408 (prerelease) (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.11_interlace.diff
x264_win_zone_parse_fix_05.diff

[techouse]

x264_x64_r1140_unpatched (http://techouse.project357.com/builds/revision1140/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1140/x264.md5)
GCC 4.3.4 20090408 (prerelease) (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1140_techouse (http://techouse.project357.com/builds/x264_x86_r1140_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1140_techouse.txt)
GCC 4.3.3, fprofiled, -march=core2

x264_x64_r1140_techouse (http://techouse.project357.com/builds/x264_x64_r1140_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1140_techouse.txt)
GCC 4.3.4 20090408 (prerelease) (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.11_interlace.diff
x264_win_zone_parse_fix_05.diff

[JEEB]

Since I've been building x264 for some time now, posting here as well.

x264 r1143 x86
download (http://jeeb.fiveforty.jp/x264/1143/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1143/relnotes.txt)

built on Apr 19 2009, gcc: 4.3.3
fprofiled, -march=i686


x264 r1143 x64
download (http://jeeb.fiveforty.jp/x264/1143_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1143_x64/relnotes.txt)

built on Apr 19 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


Both patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.11_interlace.diff

[jefrey]

Hi there, i have a strange probleme, since rls 1139, megui or x264.exe didnt show the quant and compressions infos, when the job is done. in megui there is no info tree and cli shows only ready, push any button to continue:(

what could it be?

[nurbs]

Works fine for me with megui and x264 1139.

[jefrey]

very strange! i didnt change anything :(

[techouse]

x264_x64_r1145_unpatched (http://techouse.project357.com/builds/revision1145/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1145/x264.md5)
GCC 4.3.4 20090408 (prerelease) (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1145_techouse (http://techouse.project357.com/builds/x264_x86_r1145_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1145_techouse.txt)
GCC 4.3.3, fprofiled, -march=core2

x264_x64_r1145_techouse (http://techouse.project357.com/builds/x264_x64_r1145_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1145_techouse.txt)
GCC 4.3.4 20090408 (prerelease) (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.11_interlace.diff
x264_win_zone_parse_fix_05.diff

[Sharktooth]

request: skystrife's updated build or
x264 x86 static built with x264_hrd_pulldown.11_interlace.diff and x264_win_zone_parse_fix_05.diff patches, fprofiled, mp4 output, pthreads, GCC 3.4.x, -march=pentium2

[imk]

ICC builds of r1145M (http://imk.cx/pc/x264/x264-r1145M-imk.7z)

Build info can be found here (http://imk.cx/pc/x264/win_build_info.txt) and it's also included in the .7z

[alexins]

request: skystrife's updated build or
x264 x86 static built with x264_hrd_pulldown.11_interlace.diff and x264_win_zone_parse_fix_05.diff patches, fprofiled, mp4 output, pthreads, GCC 3.4.x, -march=pentium2

x264 Video Codec rev. 1145 x86 -march=pentium2, gcc 3.4.5, fprofiled, ... (http://www.xvidvideo.ru/component/option,com_docman/task,doc_download/gid,1633/)

[Sharktooth]

thanx

[turbojet]

Is there a patch that if --level is used and exceeded it would enforce the maximum?

For example: 1920x1080p 23.976 fps input, "x264 --level 4.0 --ref 8 --b-pyramid" would be changed to "x264 --level 4.0 --ref 4 --b-pyramid --vbv-maxrate 25000 --vbv-buffer 25000" instead of x264 warning it would say something like 'L4.0 --ref 4 forced for 1920x1080 resolution and using 25 mbps maximum'

But it shouldn't touch if it's below the maximum such as "x264 --level 4.0 --ref 1 --vbv-maxrate 10000 --vbv-buffer 25000" nothing would be changed.

[JEEB]

x264 r1148 32bit
download (http://jeeb.fiveforty.jp/x264/1148/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1148/relnotes.txt)

built on May 10 2009, gcc: 4.3.3
fprofiled, -march=i686


x264 r1148 64bit
download (http://jeeb.fiveforty.jp/x264/1148_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1148_x64/relnotes.txt)

built on May 10 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


Both patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.11_interlace.diff

[skystrife]

x264 r1148 x64 (unpatched) (http://skystrife.com/x264/revision1148/x264.exe)
gcc 4.3.4 fprofiled build.

-------------------------

x264.1148M.x86.exe (http://skystrife.com/x264/x264.1148M.x86.exe) / x264.1148M.x64.exe (http://skystrife.com/x264/x264.1148M.x64.exe)
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.11_interlace.diff
x264_win_zone_parse_fix_05.diff

[techouse]

x264_x64_r1148_unpatched (http://techouse.project357.com/builds/revision1145/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1148/x264.md5)
GCC 4.3.4 20090408 (prerelease) (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1148_techouse (http://techouse.project357.com/builds/x264_x86_r1148_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1148_techouse.txt)
GCC 4.3.3, fprofiled, -march=core2

x264_x64_r1148_techouse (http://techouse.project357.com/builds/x264_x64_r1148_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1148_techouse.txt)
GCC 4.3.4 20090408 (prerelease) (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.11_interlace.diff
x264_win_zone_parse_fix_05.diff

[komisar]

And my 1148 builds... :)
CLI/VFW, fprofiled, mp4 output, pthread, avis input, gcc 4.3.4 20090408 (prerelease) (xXX.YY.Komisar)
http://komisar.gin.by/
Builds abbreviation:
clear (no patches)
kGIT01_x264_custom_strtok_r.r1089.diff (by BugMaster)
x264_hrd_pulldown.11_interlace.diff
kModkGIT plus:
01_x264_debug_defines.r1089.diff (by BugMaster)
01_x264_fix_float_point_exception.r1089.diff (by BugMaster)
01_x264_fix_stats_file_work.r1089.diff (by BugMaster)
01_x264_multithreading_bug_check.r1089.diff (by BugMaster)
02_bm_x264_error_memoryleaks.04.r1089.diff (by BugMaster)
03_bm_x264_thread_pool.02.r1089.diff (by BugMaster)
k.62.x264_thread_priority_with_pool.02.diff (by Komisar)
k.76.k_Cosmetic.03.diff (by Komisar)
k.66.k_Profile.01.diff (by Komisar)
k.56.x264_log_file.03k.diff (by Komisar)
k.60.x264_restore_console_title.diff (by Komisar)
kAVAQkMod plus:
x264_AutoVAQ.02.diff (new version of VAQ modification by BugMaster)

[DarkZell666]

@komisar & x264 devs : May I dare ask why all those patches aren't in the git ? :o They must have a valid reason for existing don't they ?

[kemuri-_9]

@komisar & x264 devs : May I dare ask why all those patches aren't in the git ? :o They must have a valid reason for existing don't they ?

many of them are features that aren't cared for by the devs or kludge fixes which are also not cared for.

[Trahald]

Hrd patch 12. VFR (pulldown) is considered in the actual buffer size tracker (not planning.) previously just the average rate was used for planning and actual. Average will still be used for planning.
HRD Type II bits (AUD, Sei) are considered in the actual buffer size. Stock x264 has HRD type I compliance which only factors slice data bits in buffer size.

[G_M_C]

Hrd patch 12. VFR (pulldown) is considered in the actual buffer size tracker (not planning.) previously just the average rate was used for planning and actual. Average will still be used for planning.
HRD Type II bits (AUD, Sei) are considered in the actual buffer size. Stock x264 has HRD type I compliance which only factors slice data bits in buffer size.

:thanks:

very much so !

[shon3i]

Thanks Trahald, finally, can this patch finaly included into git?

[Trahald]

Its almost to the point that I'd like it in there (assuming 12 does well when used widely), but not yet. Although I think I'm done with any real changes on it. It just mostly needs code clean up (making sure label conventions are consistent with x264s, etc). Then Its up to the powers that be. Although IIRC, the code end of it wasnt the only objection re: its only needed for bluray.

[shon3i]

its only needed for bluray. This is actually the reason why i ask.

[kemuri-_9]

This is actually the reason why i ask.

does the blu-ray standard not also mandatorily require 4 slices to be used?
with x264 not having used the sliced threading model since ? this is another hit to BD compatibility.

[LoRd_MuldeR]

does the blu-ray standard not also mandatorily require 4 slices to be used?
with x264 not having used the sliced threading model since ? this is another hit to BD compatibility.

If I remember the discussion correctly, then it wasn't 100% sure whether this is more a recommendation or a must.

[Trahald]

4 slice minimum is mandatory . they are to be relatively equal in size.

The additions that the HRD patch makes are the ones that most authoring applications enforce. But yes, a stream must be multi-sliced to truly be compliant.

[shon3i]

I am aware of that, but given that no player has not made a problem. I think we not see slices encoding in x264 that soon :) but will be great to finally make x264 full blu-ray compilant.

[G_M_C]

I am aware of that, but given that no player has not made a problem. I think we not see slices encoding in x264 that soon :) but will be great to finally make x264 full blu-ray compilant.

Yes, when the hrd patch becomes committed, then the "lack of slices" is the last major step for x264 to be able to make fully BD compliant streams.

[skystrife]

x264 r1153 x64 (unpatched) (http://skystrife.com/x264/revision1153/x264.exe)
gcc 4.4.0 (release) fprofiled build.
-------------------------

x264.1153M.lookahead.02.x86.exe (http://skystrife.com/x264/x264.1153M.lookahead.02.x86.exe) / x264.1153M.lookahead.x64.exe (http://skystrife.com/x264/x264.1153M.lookahead.x64.exe)
gcc 4.4.0 (release) fprofiled builds (x86 uses -march=pentium2).

Patches used:

x264-r1134-threaded-slicetype-v14.diff (http://skystrife.com/x264/x264-r1134-threaded-slicetype-v14.diff)
x264_threaded_slicetype_windows_fix.diff (http://skystrife.com/x264/x264_threaded_slicetype_windows_fix.diff)
x264_hrd_pulldown.12_interlace.diff
x264_win_zone_parse_fix_05.diff

Changes from previous releases:

x86 build no longer uses gcc 3.4.5. Reasoning: the threaded slicetype patch does not compile cleanly on windows using the 3.4.x series of gcc, but does with 4.x+.

EDIT: Adding a build without the threaded slicetype patch in a moment, for anyone having issues with this one. (I've had no problems with the windows fix, but that's just me.)

EDIT2: x86 lookeahead build fixed, the pthreads library is now built in. Apologies for the trouble.

[techouse]

x264_x64_r1153_unpatched (http://techouse.project357.com/builds/revision1153/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1153/x264.md5)
GCC 4.3.4 20090408 (prerelease) (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1153_techouse (http://techouse.project357.com/builds/x264_x86_r1153_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1153_techouse.txt)
GCC 4.3.3, fprofiled, -march=core2

x264_x64_r1153_techouse (http://techouse.project357.com/builds/x264_x64_r1153_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1153_techouse.txt)
GCC 4.3.4 20090408 (prerelease) (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.12_interlace.diff
x264_win_zone_parse_fix_05.diff

[burfadel]

X264 r1153 + Autovaq?

Thanks! :)

Oh techouse, how come using 4.3.3/4.3.4 (prerelease) if 4.4.0 is out?
Maybe an extra build with Autovaq patch? ;) Just seems to be a very good thing thats all! admitedly I can use a lower CRF, still have smaller files and have better quality with it! hence why I suggested optimising the distribution of bits to keep the CRF's closer, but its good nonetheless.

Oh, and would the builds on x264.nl benefit from gcc 4.4.0 over 3.4.6?

[skystrife]

x264.1153M.x86.exe (http://skystrife.com/x264/x264.1153M.x86.exe) / x264.1153M.x64.exe (http://skystrife.com/x264/x264.1153M.x64.exe)
gcc 4.4.0 (release) fprofiled builds (x86 uses -march=pentium2).

Patches used:

x264_hrd_pulldown.12_interlace.diff
x264_win_zone_parse_fix_05.diff

Use this if the slicetype patch is giving you issues. I'll also put up an AutoVAQ build here in a bit, as well as a x64 build without the slicetype patch.

EDIT: Oh ffs, I accidentally deleted it... It'll be up in a bit, I swear. -_-

EDIT2: Ok, finally up. Never make clean until after you have your binary elsewhere. -_-;

EDIT3: x64 binary up.

[Underground78]

EDIT: Oh ffs, I accidentally deleted it... It'll be up in a bit, I swear. -_-

The error page is really good ! :p

[skystrife]

The error page is really good ! :p

lol, thanks.

-------------------------

x264.1153M.AutoVAQ.x86.exe (http://skystrife.com/x264/x264.1153M.AutoVAQ.x86.exe) / x264.1153M.AutoVAQ.x64.exe (http://skystrife.com/x264/x264.1153M.AutoVAQ.x64.exe)
gcc 4.4.0 (release) fprofiled builds (x86 uses -march=pentium2).

Patches used:

x264_hrd_pulldown.12_interlace.diff
x264_win_zone_parse_fix_05.diff
x264_AutoVAQ.02.diff (see AutoVAQ thread)

Also note the new x86 build including the lookahead patch (this contains a built-in pthread library, unlike the previous one, my mistake).

[woah!]

lol, thanks.

-------------------------

x264.1153M.AutoVAQ.x86.exe (http://skystrife.com/x264/x264.1153M.AutoVAQ.x86.exe) / x264.1153M.AutoVAQ.x64.exe (http://skystrife.com/x264/x264.1153M.AutoVAQ.x64.exe)
gcc 4.4.0 (release) fprofiled builds (x86 uses -march=pentium2).

Patches used:

x264_hrd_pulldown.12_interlace.diff
x264_win_zone_parse_fix_05.diff
x264_AutoVAQ.02.diff (see AutoVAQ thread)

Also note the new x86 build including the lookahead patch (this contains a built-in pthread library, unlike the previous one, my mistake).

anyone having issues running the 2nd pass with your x86 build? i can complete crf mode and the 1st pass using it, but it just sits hanging at the cpu capabilities info ?

using a prior build 1148 works correctly on exact same script.


update; hmm ok techhouse build 1153 does the same? this is the last one i seem to have no issues with http://forum.doom9.org/showpost.php?p=1283584&postcount=1847

also your 1148 build works ok aswell. what has changed since 1148?

[desta]

anyone having issues running the 2nd pass with your x86 build? i can complete crf mode and the 1st pass using it, but it just sits hanging at the cpu capabilities info ?

using a prior build 1148 works correctly on exact same script.


update; hmm ok techhouse build 1153 does the same? this is the last one i seem to have no issues with http://forum.doom9.org/showpost.php?p=1283584&postcount=1847

also your 1148 build works ok aswell. what has changed since 1148?

Have a look here (http://forum.doom9.org/showthread.php?p=1288666#post1288666).

[kemuri-_9]

to better assist with nailing down problems, please provide more information on the source you're encoding and the settings on each pass you're using.

i've been trying to test the recent patches but haven't yet been able to get them to crash/fail as reported...

[woah!]

ahh good stuff, not a issue with my setup then :)

[woah!]

to better assist with nailing down problems, please provide more information on the source you're encoding and the settings on each pass you're using.

i've been trying to test the recent patches but haven't yet been able to get them to crash/fail as reported...

here's my setup:

-p 1 -B 9046 --stats "X:\264.stats" --aq-strength 1.0 -f -2:-1 --aq-mode 2 --b-adapt 1 --psy-rd "0.0:0.0" -t 1 --level 4.1 --keyint 24 --min-keyint 1 -ref 3 --mixed-refs --bframes 3 --weightb --direct auto --subme 8 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 38000 --qcomp 0.5 --me dia --threads auto --progress --no-psnr --mvrange 511 --aud --nal-hrd --sar 1:1 -o NUL "Y:\BLURAY.avs"
avis [info]: 1920x1080 @ 23.98 fps (1001 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High, level 4.1
x264 [info]: slice I:58 Avg QP:18.38 size:117026
x264 [info]: slice P:411 Avg QP:19.23 size: 76409
x264 [info]: slice B:532 Avg QP:20.56 size: 19960
x264 [info]: consecutive B-frames: 13.7% 26.1% 21.6% 38.6%
x264 [info]: mb I I16..4: 35.9% 60.8% 3.3%
x264 [info]: mb P I16..4: 10.4% 22.2% 1.2% P16..4: 25.9% 6.9% 3.9% 0.0% 0
.0% skip:29.5%
x264 [info]: mb B I16..4: 0.7% 1.2% 0.2% B16..8: 26.2% 0.9% 1.0% direct:
5.9% skip:64.0% L0:25.3% L1:36.9% BI:37.8%
x264 [info]: final ratefactor: 17.90
x264 [info]: 8x8 transform intra:64.0% inter:59.2%
x264 [info]: direct mvs spatial:99.1% temporal:0.9%
x264 [info]: coded y,uvDC,uvAC intra:77.4% 78.2% 54.8% inter:21.7% 22.7% 1.3%
x264 [info]: ref P L0 86.9% 8.1% 5.0%
x264 [info]: ref B L0 97.0% 3.0%
x264 [info]: SSIM Mean Y:0.9831512
x264 [info]: kb/s:9352.8

encoded 1001 frames, 10.42 fps, 9353.56 kb/s

-p 2 -B 9046 --stats "X:\264.stats" --aq-strength 1.0 -f -2:-1 --aq-mode 2 --b-adapt 1 --psy-rd "0.0:0.0" -t 1 --level 4.1 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --bframes 3 --weightb --direct auto --subme 8 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 38000 --qcomp 0.5 --me umh --threads auto -progress --no-psnr --mvrange 511 --aud --nal-hrd --sar 1:1 -o "Y:\STARTREK_VI.264" "Y:\BLURAY.avs"
avis [info]: 1920x1080 @ 23.98 fps (1001 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cach
e64

Y:\>pause
Press any key to continue . . .

avs script:

DGSource("Y:\!bluray_encoding\STARTREK_VI.dga")


thats it heh...

on the second pass the encode stops at cache64, weird as 1st pass is ok.

[kemuri-_9]

on the second pass the encode stops at cache64, weird as 1st pass is ok.

Thank you, I've been able to confirm the crash is resulting in the change from the v11 to v12 of the hrd/interlace patch.

Edit:
so any build with the x264_hrd_pulldown.12_interlace.diff will crash if --vbv-bufsize is given on the command line for the 2nd pass.

[woah!]

just to let you know, crf mode works just fine so it is just a 2 pass bug.

[Trahald]

I havent been able to duplicate it. I am using 1153 with just hrd 12 patch. 2 pass works fine. I am using the old gcc(3.4.5) and i dont have gpac on. I have vbv-bufsize in my cli. does it crash right away or take some time?

[kemuri-_9]

I havent been able to duplicate it. I am using 1153 with just hrd 12 patch. 2 pass works fine. I am using the old gcc(3.4.5) and i dont have gpac on. I have vbv-bufsize in my cli. does it crash right away or take some time?

the crash happens immediately.
I was working from woah!'s command line and it stopped crashing once i removed --vbv-buffsize...

i can even knock off params until i get to the following command line

-p 2 -B 9046 --vbv-bufsize 30000 -o OUTPUT INPUT

and it still crashes.

this is happening in both gcc 3.4.5 and 4.4.0

here's a bt of the error from my end.

Program received signal SIGSEGV, Segmentation fault.

bt
#0 0x77bd1a02 in msvcrt!fclose () from C:\WINDOWS\syswow64\msvcrt.dll
#1 0x003f7410 in ?? ()
#2 0x025d6fe8 in ?? ()
#3 0x0232da40 in ?? ()
#4 0xffffffff in ?? ()
#5 0x0022f3a0 in ?? ()
#6 0x417fca05 in ?? ()
#7 0x0022ffe0 in ?? ()
#8 0x77bc6c74 in msvcrt!_except_handler2 ()
from C:\WINDOWS\syswow64\msvcrt.dll
#9 0x004227bb in vbv_pass2 (h=<incomplete type>)
at encoder/ratecontrol.c:1799
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


here's a bt from a linux machine which may be more useful:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210382656 (LWP 15469)]
0xb7e05dcd in fclose () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7e05dcd in fclose () from /lib/tls/i686/cmov/libc.so.6
#1 0x08097cef in init_pass2 (h=0x80d83b0) at encoder/ratecontrol.c:1799
#2 0x0809941d in x264_ratecontrol_new (h=0x80d83b0) at encoder/ratecontrol.c:575
#3 0x0805443c in x264_encoder_open (param=0xbfb34588) at encoder/encoder.c:811
#4 0x0804aa0a in main (argc=10, argv=0xbfb34864) at x264.c:816

[Trahald]

Ahh. it was some debug code i added and didnt completely delete. Sorry. Still not sure why its not crashing here (it should). here is 13. Thanks aku and kemuri_9 for helping fix it.

[skystrife]

x264.1153M.02.x86.exe (http://skystrife.com/x264/x264.1153M.02.x86.exe) / x264.1153M.02.x64.exe (http://skystrife.com/x264/x264.1153M.02.x64.exe)
gcc 4.4.0 (release) fprofiled builds (x86 uses -march=pentium2).

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff

-------------------------

x264.1153M.AutoVAQ.02.x86.exe (http://skystrife.com/x264/x264.1153M.AutoVAQ.02.x86.exe) / x264.1153M.AutoVAQ.02.x64.exe (http://skystrife.com/x264/x264.1153M.AutoVAQ.02.x64.exe)
gcc 4.4.0 (release) fprofiled builds (x86 uses -march=pentium2).

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff
x264_AutoVAQ.02.diff

[JEEB]

x264 r1158 32bit
download (http://jeeb.fiveforty.jp/x264/1158/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1158/relnotes.txt)

built on May 25 2009, gcc: 4.3.3
fprofiled, -march=i686 (now default in x264)


x264 r1158 64bit
download (http://jeeb.fiveforty.jp/x264/1158_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1158_x64/relnotes.txt)

built on May 25 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


Both patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.13_interlace.diff

[skystrife]

x264.1158M.x86.exe (http://skystrife.com/x264/x264.1158M.x86.exe) / x264.1158M.x64.exe (http://skystrife.com/x264/x264.1158M.x64.exe)
gcc 4.4.0 (release) fprofiled builds (x86 uses -march=pentium2).

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff

-------------------------

x264.1158M.AutoVAQ.x86.exe (http://skystrife.com/x264/x264.1158M.AutoVAQ.x86.exe) / x264.1158M.AutoVAQ.x64.exe (http://skystrife.com/x264/x264.1158M.AutoVAQ.x64.exe)
gcc 4.4.0 (release) fprofiled builds (x86 uses -march=pentium2).

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff
x264_AutoVAQ.02.diff

[XhmikosR]

Hi, skystrife. I downloaded your x264.1158M.x86.exe, and in version it shows:

x264 0.67.1153M 7b6ce6a
built on May 24 2009, gcc: 4.4.0

[Audionut]

Yup, same for VAQ.x86.

[JEEB]

Patches used:

x264_hrd_pulldown.12_interlace.diff
x264_win_zone_parse_fix_05.diff
I really hope that this is just a mistake caused by copypasta since the revision 12 seems to have bugs (which is why there's revision 13 of it out already here (http://forum.doom9.org/showpost.php?p=1288917&postcount=1878)).

Just had to mention that (since some people actually use the nal-hrd stuff, and usually with vbv).

[techouse]

x264_x64_r1159_unpatched (http://techouse.project357.com/builds/revision1159/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1159/x264.md5)
GCC 4.4.0 20090524 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1159_techouse (http://techouse.project357.com/builds/x264_x86_r1159_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1159_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1159_techouse (http://techouse.project357.com/builds/x264_x64_r1159_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1159_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff

[komisar]

Someone confirm the change of the progress indicator?
I see "[-1.$%] 80/144475 frames, 0.00 fps, 169.94 kb/s, eta 2:17:15" in my, techouse and skystrife builds.

Perhaps another bug in gcc 4.4.X profiling...

[kemuri-_9]

Someone confirm the change of the progress indicator?
I see "[-1.$%] 80/144475 frames, 0.00 fps, 169.94 kb/s, eta 2:17:15" in my, techouse and skystrife builds.

Perhaps another bug in gcc 4.4.X profiling...

there's not been any code changes to the progress indication in the last few revisions...
i haven't seen any problems with my 4.4.0 builds
nor have I been able to replicate it now with techouse's or skystrife's

and that does particularly look like an error caused by a floating point exception...

[komisar]

kemuri-_9
I test only 64bit builds. fps and % always as in my previous post.

in some situation x264 crash (gcc 4.4.0 profiled and not-profiled builds) and i seex264 [info]: profile Main, level 3.0
[-47132383076129555000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000.0%] 10/185605 frames, 26.67 fps, 133.86 kb/s, eta 1:55:59
compiled with gcc 4.3.4 work fine.

[techouse]

Hmm, my patched and unpatched 64bit GCC 4.4.0 builds (r1159) work fine for me...

x264 [info]: 1280x534 @ 23.98 fps
x264 [warning]: width or height not divisible by 16 (1280x534), compression will suffer.
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.1
my_movie.avs: 1280x534, 24000/1001 fps, 238873 frames
[0.2%] 590/238873 frames, 2.84 fps, 4986.28 kb/s, eta 23:20:08
I'll keep the thing running and report back any crashes or anything unusual...

EDIT: Have been running the thing for a day now without any crashes or anything.

[juGGaKNot]

1160 autovaq please...

[techouse]

x264_x64_r1160_unpatched (http://techouse.project357.com/builds/revision1160/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1160/x264.md5)
GCC 4.4.0 20090524 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1160_techouse (http://techouse.project357.com/builds/x264_x86_r1160_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1160_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1160_techouse (http://techouse.project357.com/builds/x264_x64_r1160_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1160_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff

________________________________________________________________________________

x264_x86_r1160_AutoVAQ.0.2_techouse (http://techouse.project357.com/builds/x264_x86_r1160_AutoVAQ.0.2_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1160_AutoVAQ.0.2_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1160_AutoVAQ.0.2_techouse (http://techouse.project357.com/builds/x264_x64_r1160_AutoVAQ.0.2_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1160_AutoVAQ.0.2_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_AutoVAQ.02.diff
x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff

[JEEB]

x264 r1162 32bit
download (http://jeeb.fiveforty.jp/x264/1162/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1162/relnotes.txt)

built on May 27 2009, gcc: 4.3.3
fprofiled, -march=i686


x264 r1162 64bit
download (http://jeeb.fiveforty.jp/x264/1162_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1162_x64/relnotes.txt)

built on May 27 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


Both patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.13_interlace.diff


x264 r1162 AutoVAQ patched:

32bit (http://jeeb.fiveforty.jp/x264/1162avaq/x264.exe)
64bit (http://jeeb.fiveforty.jp/x264/1162avaq_x64/x264.exe)

(Built otherwise with the same patches, settings and compilers. x264_AutoVAQ.02.diff version of the AutoVAQ patch used.)

[techouse]

x264_x64_r1163_unpatched (http://techouse.project357.com/builds/revision1163/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1163/x264.md5)
GCC 4.4.0 20090524 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1163_techouse (http://techouse.project357.com/builds/x264_x86_r1163_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1163_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1163_techouse (http://techouse.project357.com/builds/x264_x64_r1163_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1163_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff

________________________________________________________________________________

x264_x86_r1163_AutoVAQ.0.2_techouse (http://techouse.project357.com/builds/x264_x86_r1163_AutoVAQ.0.2_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1163_AutoVAQ.0.2_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1163_AutoVAQ.0.2_techouse (http://techouse.project357.com/builds/x264_x64_r1163_AutoVAQ.0.2_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1163_AutoVAQ.0.2_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_AutoVAQ.02.diff
x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff

[Fr4nz]

I point out a new ICC compiled version of x264, made by IMK for Windows and MacOS systems:
http://imk.cx/pc/x264/x264-r1163M-imk-win.7z
http://imk.cx/pc/x264/x264-r1163M-imk-osx.7z

These versions are very very performant with Intel Core Duo/Quads (maybe also i7?), so I recommend them if you have these CPUs.

[laserfan]

I point out a new ICC compiled version of x264...very very performant with Intel Core Duo/Quads (maybe also i7Sorry but in looking at the build info I see something and have to ask: what means "with MP4 output" i.e. what does that build do that's different?

[LoRd_MuldeR]

Sorry but in looking at the build info I see something and have to ask: what means "with MP4 output" i.e. what does that build do that's different?

You can build x264 with or without GPAC. Without GPAC it won't be able to put out MP4 files. Only MKV files.

That applies to all builds of x264, no matter what compiler is used. Most builds of x264 CLI have GPAC (MP4 output) enabled.

BTW: I highly doubt that his ICC builds are that much faster compared to the usual GCC builds. That's because all the performance-critical functions in x264 are hand-optimized ASM code anyway. Compiler optimizations only effect the plain C code. So maybe the ICC builds are a bit faster than GCC indeed, but not that dramatically faster as one could assume from his post...

[roozhou]

BTW: I highly doubt that his ICC builds are that much faster compared to the usual GCC builds. That's because all the performance-critical functions in x264 are hand-optimized ASM code anyway. Compiler optimizations only effect the plain C code. So maybe the ICC builds are a bit faster than GCC indeed, but not that dramatically faster as one could assume from his post...
Does ICC has something similar to GCC's fprofile and MSVC's PGO? According to my test, profiling does increase performance by ~3% for GCC build and ~5% for MSVC build.

[Fr4nz]

BTW: I highly doubt that his ICC builds are that much faster compared to the usual GCC builds. That's because all the performance-critical functions in x264 are hand-optimized ASM code anyway. Compiler optimizations only effect the plain C code. So maybe the ICC builds are a bit faster than GCC indeed, but not that dramatically faster as one could assume from his post...

Yes, the speedup is not big/enormous but there is indeed a ~4-5% gain.

Example with latest 1163 release encoding SD content (720x480) in MeGUI with "balanced SD" preset at 1000kbps (my system is a E6750 @3,3ghz with 2GB of RAM and WinXP SP3):

- ICC x264 v1163: 141,57 fps 1st pass; 56,42 fps 2nd pass
- Latest megui x264 version (v1162 Jeeb patched build): 136,29 fps 1st pass; 54,83 fps 2nd pass

[roozhou]

Yes, the speedup is not big/enormous but there is indeed a ~4-5% gain.

Example with latest 1163 release encoding SD content (720x480) in MeGUI with "balanced SD" preset at 1000kbps (my system is a E6750 @3,3ghz with 2GB of RAM and WinXP SP3):

- ICC x264 v1163: 141,57 fps 1st pass; 56,42 fps 2nd pass
- Latest megui x264 version (v1162 Jeeb patched build): 136,29 fps 1st pass; 54,83 fps 2nd pass

You are comparing 1163 and 1162, and they are using different patches.

[wyti]

it's the same, the only difference between those 2 builds is the configure file.

[Fr4nz]

You are comparing 1163 and 1162, and they are using different patches.

No, see here:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog

[LoRd_MuldeR]

The problem is not the difference between r1163 and r1162 (that is negligible), but that fact that one of the builds you were comparing is "v1162 Jeeb patched build" ;)

Unofficial patches can do all sorts of things, making the comparison useless. To get a proper comparison, use two vanilla (unpatched) builds or use the same patches for both builds at least!

[laserfan]

Thanks LM re: answering my "with MP4" query. :)

[Fr4nz]

The problem is not the difference between r1163 and r1162 (that is negligible), but that fact that one of the builds you were comparing is "v1162 Jeeb patched build" ;)

Unofficial patches can do all sorts of things, making the comparison useless. To get a proper comparison, use two vanilla (unpatched) builds or use the same patches for both builds at least!

Mulder, if I point out that there's a 4-5% gain, there's a reason...this is not a thing that I noticed yesterday, but since I spotted Imk first compiled builds...

[LoRd_MuldeR]

If I point out that there's a 4-5% gain, there's a reason...this is not a thing that I noticed yesterday, but since I spotted Imk first compiled builds...

Which doesn't change the fact that comparing the speed of builds which use different patches will not give you meaningful results ;)

[Fr4nz]

Which doesn't change the fact that comparing the speed of builds which use different patches will not give you meaningful results ;)

You're completely right, I should prepare a test in order to demonstrate my thesis, but I don't have time :)

So: trust me :D

[kemuri-_9]

yes the ICC builds from imk have most often been fractionally faster than the standard gcc builds as previously stated within this thread,
but they are also are usually compiled with higher mandatory asm requirements...
i imagine he's still doing SSE2 (generally for AMD) and SSSE3 (for Intel) builds of x264.
so older cpu chips can't use such builds....

[CruNcher]

@kemuri-_9
something is strange with your build i tried to get IBBP but i always get IBP from your build --b-adapt 0 -b 2 --scenecut -1 -I 25 the k8 one jarod results in the expected IBBP sequence

[kemuri-_9]

@kemuri-_9
something is strange with your build i tried to get IBBP but i always get IBP from your build --b-adapt 0 -b 2 --scenecut -1 -I 25 the k8 one jarod results in the expected IBBP sequence

ah... hmm... i did manage to replicate and somewhat pinpoint the issue...
seems to be another bug in the threaded slicetype patch...
thanks for pointing it out.

some more testing seems to reveal that b-adapt 0 is mostly broken with the current state of that patch...

[G_M_C]

yes the ICC builds from imk have most often been fractionally faster than the standard gcc builds as previously stated within this thread,
but they are also are usually compiled with higher mandatory asm requirements...
i imagine he's still doing SSE2 (generally for AMD) and SSSE3 (for Intel) builds of x264.
so older cpu chips can't use such builds....

I've ran an encode with IMK's ICC build v. 1163 for x32, and it crashed @ 90.2% of the 2nd pas of the encode. I did OC my system to 3,2 GHz, but the CPU is a it is an QX9650 that hasn't had a problem before at that speed. I've raised the voltage to the CPU slightly, and the 2nd pass of the encode is re-running now.

I'll report back to let you know if the problem has re-occurred (or not).

EDIT:
The encode went fine this time. Seems it was the stabillity of my system that was at fault, the slightly raised voltage did it.

[Atak_Snajpera]

The encode went fine this time. Seems it was the stabillity of my system that was at fault, the slightly raised voltage did it.
You should always check stability in Prime95 MT before encoding.

[G_M_C]

You should always check stability in Prime95 MT before encoding.

It's the first encode that had this error, out a great number. Never had a stabillity problem before.

[Sharktooth]

@Fr4nz: r1162 and r1163 are identical code wise. the only difference is in the configure script (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=3f56e271ac3d8a0e054b8b18e63886a6070ef05e).
so please dont spread bull$hit.

[Fr4nz]

@Fr4nz: r1162 and r1163 are identical code wise. the only difference is in the configure script (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=3f56e271ac3d8a0e054b8b18e63886a6070ef05e).
so please dont spread bull$hit.

Hey Sharkthoot:

1) I never said that the code was different between 1162 and 1163;
2) Read *better* my posts (this is a corollary from point 1);
3) I suggest you to moderate your language, as stated in rule #4.

[imk]

Does ICC has something similar to GCC's fprofile and MSVC's PGO? According to my test, profiling does increase performance by ~3% for GCC build and ~5% for MSVC build.

Yes, I profile each build I make.


yes the ICC builds from imk have most often been fractionally faster than the standard gcc builds as previously stated within this thread,
but they are also are usually compiled with higher mandatory asm requirements...
i imagine he's still doing SSE2 (generally for AMD) and SSSE3 (for Intel) builds of x264.
so older cpu chips can't use such builds....

Correct. I still build separate SSE2 and SSSE3 builds. The SSE2 builds are only built to satisfy AMD users, while the SSSE3 builds are meant for Intel Core 2 Duo's and higher.



As for performance differences, I occasionally update a spreadsheet I have with performance comparisons.

http://spreadsheets.google.com/pub?key=pbffjdC6iUPWs2HtYHwZ2VQ

These are my benchmarks and I try to keep them as detailed as possible so that there's no confusion in the results.

The gains with using ICC can be pretty small, but as long as it produces identical output with no problems, then it might as well be used. ;)

[akupenguin]

btw, I just checked your SSSE3 builds... they use SSSE3 in a grand total of 2 functions (ssd and predict_16x16_dc_top), both of which have asm anyway. If there's a difference in speed, it's due to icc's equivalent of -mtune, not due to the instruction set. Furthermore, there isn't much difference in the timing of scalar instructions between Core2 vs K8, so I have to wonder whether you're gaining anything at all by having separate SSE2 vs SSSE3 builds (that part isn't listed on your spreadsheet).

[imk]

Yeah, I've never actually compared the differences between the SSE2 and SSSE3 builds.

I'm probably going to use a combination of -x and -ax for future builds, which will enable SSE2 as a baseline requirement, while providing optimizations for other processors if available.

[techouse]

x264_x64_r1165_unpatched (http://techouse.project357.com/builds/revision1165/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1165/x264.md5)
GCC 4.4.0 20090524 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1165_techouse (http://techouse.project357.com/builds/x264_x86_r1165_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1165_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1165_techouse (http://techouse.project357.com/builds/x264_x64_r1165_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1165_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff

________________________________________________________________________________

x264_x86_r1165_AutoVAQ.0.2_techouse (http://techouse.project357.com/builds/x264_x86_r1165_AutoVAQ.0.2_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1165_AutoVAQ.0.2_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1165_AutoVAQ.0.2_techouse (http://techouse.project357.com/builds/x264_x64_r1165_AutoVAQ.0.2_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1165_AutoVAQ.0.2_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_AutoVAQ.02.diff
x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff

[JEEB]

x264 r1165 32bit
download (http://jeeb.fiveforty.jp/x264/1165/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1165/relnotes.txt)

built on Jun 11 2009, gcc: 4.3.3
fprofiled, -march=i686


x264 r1165 64bit
download (http://jeeb.fiveforty.jp/x264/1165_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1165_x64/relnotes.txt)

built on Jun 11 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


Both patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.13_interlace.diff


x264 r1165 AutoVAQ patched:

32bit (http://jeeb.fiveforty.jp/x264/1165avaq/x264.exe)
64bit (http://jeeb.fiveforty.jp/x264/1165avaq_x64/x264.exe)

(Built otherwise with the same patches, settings and compilers. x264_AutoVAQ.02.diff version of the AutoVAQ patch used.)

[JEEB]

x264 r1169 32bit
download (http://jeeb.fiveforty.jp/x264/1169/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1169/relnotes.txt)

built on Jun 20 2009, gcc: 4.3.3
fprofiled, -march=i686


x264 r1169 64bit
download (http://jeeb.fiveforty.jp/x264/1169_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1169_x64/relnotes.txt)

built on Jun 20 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


Both patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.13_interlace.diff


x264 r1169 AutoVAQ patched:

32bit (http://jeeb.fiveforty.jp/x264/1169avaq/x264.exe)
64bit (http://jeeb.fiveforty.jp/x264/1169avaq_x64/x264.exe)

(Built otherwise with the same patches, settings and compilers. x264_AutoVAQ.02.diff version of the AutoVAQ patch used.)

[G_M_C]

@imk,

was looking for a new build on you .tk site, but the most recent one was from 4th of June. Could you make a new/recent one please ?

[JEEB]

x264 r1171 32bit
download (http://jeeb.fiveforty.jp/x264/1171/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1171/relnotes.txt)

built on Jun 23 2009, gcc: 4.3.3
fprofiled, -march=i686


x264 r1171 64bit
download (http://jeeb.fiveforty.jp/x264/1171_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1171_x64/relnotes.txt)

built on Jun 23 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


Both patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.13_interlace.diff


x264 r1171 AutoVAQ patched:

32bit (http://jeeb.fiveforty.jp/x264/1171avaq/x264.exe)
64bit (http://jeeb.fiveforty.jp/x264/1171avaq_x64/x264.exe)

(Built otherwise with the same patches, settings and compilers. x264_AutoVAQ.02.mod.diff version of the AutoVAQ patch used.)

[kemuri-_9]

personally, I'm tired of seeing people make two builds for std / 'Auto' VAQ...

modded patch to add 'AutoVAQ' as --aq-mode 2:
x264_AutoVAQ.02.mod.diff
(http://kemuri9.net/dev/x264/patches/x264_AutoVAQ.02.mod.diff)

[Dark Shikari]

personally, I'm tired of seeing people make two builds for std / 'Auto' VAQ...

modded patch to add 'AutoVAQ' as --aq-mode 2:
x264_AutoVAQ.02.mod.diff
(http://kemuri9.net/dev/x264/patches/x264_AutoVAQ.02.mod.diff)I agree, I left that in for a reason...

[JEEB]

Nice. I was getting -.-" of having two different builds as well, and I just didn't want to do any modifications on the code by myself.

Thanks and I guess I'll be using this patch from now. Re-uploaded the "AutoVAQ" enabled binaries so that they have the x264_AutoVAQ.02.mod.diff patch used, and - should there be no problems with the patch - I'll just switch into making one build with all of the patches :3

[burfadel]

Autovaq is a good idea, its algorithm just needs to be adjusted to reflect the filesize of the current VAQ in CRF mode, NOT to reflect the situation where VAQ is disabled!!! It plainly says in the sourcecode, that its tuned to do that, and it shouldn't take too long or be too hard for someone who knows what they are doing to modify it so people don't have to lower their CRF compared to VAQ.

[juGGaKNot]

personally, I'm tired of seeing people make two builds for std / 'Auto' VAQ...

modded patch to add 'AutoVAQ' as --aq-mode 2:
x264_AutoVAQ.02.mod.diff
(http://kemuri9.net/dev/x264/patches/x264_AutoVAQ.02.mod.diff)

Just what i need for testing, a build please ?

[J_Darnley]

juGGaKNot: see JEEB's post.
kemuri-_9: thanks, I should try it at long last.

[juGGaKNot]

Ahh i see, confused by the fact he also built a non autovaq mod version

thnx, one less mb in the bin, aq-mode 2 for autovaq right ?

btw where did aq-sensitivity go ?

[komisar]

juGGaKNot, in AutoVAQ patch no aq-sensitivity. Only aq-strength. aq-sensitivity present in early version of VAQmod patch. Latest version x264_vaqmod.07.r1089.diff (http://komisar.gin.by/x.patch/BugMaster/20090126/independent/x264_vaqmod.07.r1089.diff).

[techouse]

personally, I'm tired of seeing people make two builds for std / 'Auto' VAQ...

modded patch to add 'AutoVAQ' as --aq-mode 2:
x264_AutoVAQ.02.mod.diff
(http://kemuri9.net/dev/x264/patches/x264_AutoVAQ.02.mod.diff)
:thanks:

[MasterNobody]

personally, I'm tired of seeing people make two builds for std / 'Auto' VAQ...

modded patch to add 'AutoVAQ' as --aq-mode 2:
x264_AutoVAQ.02.mod.diff
(http://kemuri9.net/dev/x264/patches/x264_AutoVAQ.02.mod.diff)
Thanks. Patch is OK, but I prefer little clean up: x264_AutoVAQ.03.diff (http://stashbox.org/549826/x264_AutoVAQ.03.diff).

[techouse]

x264_x64_r1171_unpatched (http://techouse.project357.com/builds/revision1171/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1171/x264.md5)
GCC 4.4.0 20090524 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1171_techouse (http://techouse.project357.com/builds/x264_x86_r1171_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1171_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1171_techouse (http://techouse.project357.com/builds/x264_x64_r1171_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1171_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff
x264_AutoVAQ.03.diff

[juGGaKNot]

Building....

Waiting..... ( have to read a guide about compiling some day )

But i guess 02 is the same just not as clean.

@komisar so the latest VAQmod patch does not have sensitivity, better this way ?

BTW how does vaq affect the output ? better dark zones only ? i just watched a movie encoded with r736M with no psyRD but aq 0.5 and sensitivity 13 that looks very very sharp, autovaq with default 1.0 is causing problems in dark places on my source.

Writing library : x264 core 58 svn-736M
Encoding settings : cabac=1 / ref=3 / deblock=0:0:0 / analyse=0x3:0x133 / me=esa / subme=6 / me-prepass=0 / brdo=1 / mixed_ref=1 / me_range=27 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=16 / b_pyramid=1 / b_adapt=1 / b_bias=1 / direct=2 / wpredb=1 / bime=1 / keyint=250 / keyint_min=25 / scenecut=40(pre) / rc=2pass / bitrate=4400 / ratetol=2.0 / rceq='blurCplx^(1-qComp)' / qcomp=1.00 / qpmin=1 / qpmax=40 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:0.5:13.0

[techouse]

Waiting..... ( have to read a guide about compiling some day )

But i guess 02 is the same just not as clean.

@komisar so the latest VAQmod patch does not have sensitivity, better this way ?

BTW how does vaq affect the output ? better dark zones only ? i just watched a movie encoded with ~r800 with no psyRD but aq 0.5 and sensitivity 13 that looks very very sharp, autovaq with default 1.0 is causing problems in dark places on my source.Built. I edited the post above to avoid double posting.

[juGGaKNot]

Built. I edited the post above to avoid double posting.

Better edit this one also.

thnx, testing.


@komisar so the latest VAQmod patch does not have sensitivity, better this way ?

BTW how does vaq affect the output ? better dark zones only ? i just watched a movie encoded with r736M with no psyRD but aq 0.5 and sensitivity 13 that looks very very sharp, autovaq with default 1.0 is causing problems in dark places on my source.

[komisar]

juGGaKNot, x264_AutoVAQ.03.diff not same as x264_vaqmod.07.r1089.diff.
In x264_vaqmod.07.r1089.diff sensitivity enter manually.
In x264_AutoVAQ.03.diff sensitivity calculate automaticaly.

[juGGaKNot]

juGGaKNot, x264_AutoVAQ.03.diff not same as x264_vaqmod.07.r1089.diff.
In x264_vaqmod.07.r1089.diff sensitivity enter manually.
In x264_AutoVAQ.03.diff sensitivity calculate automaticaly.

A patch with both and aq-mode 1 = vaqmod.07 / aq-mode 2 = AutoVAQ.03 is possible ?

calculate automatically is best or near the default 13 ?

[MasterNobody]

A patch with both and aq-mode 1 = vaqmod.07 / aq-mode 2 = AutoVAQ.03 is possible ?
Of course it is possible (here is patch x264_AutoVAQmod.03.diff (http://stashbox.org/549958/x264_AutoVAQmod.03.diff) with --aq-sensitivity from VAQmod but without --aq-metric) but probably nobody is interested in it now.

[juGGaKNot]

Of course it is possible (here is patch x264_AutoVAQmod.03.diff (http://stashbox.org/549958/x264_AutoVAQmod.03.diff) with --aq-sensitivity from VAQmod but without --aq-metric) but probably nobody is interested in it now.

I guess so, i will check out a compilation guide and use the normal one until then.

thnx, cheers.

One more question :

BTW how does vaq affect the output ? better dark zones only ? i just watched a movie encoded with r736M with no psyRD but aq 0.5 and sensitivity 13 that looks very very sharp, autovaq with default 1.0 is causing problems in dark places on my source.

[Dark Shikari]

I guess so, i will check out a compilation guide and use the normal one until then.

thnx, cheers.

One more question :

BTW how does vaq affect the output ? better dark zones only ? i just watched a movie encoded with r736M with no psyRD but aq 0.5 and sensitivity 13 that looks very very sharp, autovaq with default 1.0 is causing problems in dark places on my source.AutoVAQ is like the old "mode 1" of VAQ; it adapts per-frame to avoid VAQ affecting ratecontrol.

This may not be entirely a good thing, as it means that the powerful bias that VAQ adds to dark frames is no longer there.

[Fr4nz]

New Imk x264 "ICC compiled" 1171 version (for x86/x64) here:

http://imk.cx/pc/x264/x264-r1171M-imk-win.7z

[G_M_C]

New Imk x264 "ICC compiled" 1171 version (for x86/x64) here:

http://imk.cx/pc/x264/x264-r1171M-imk-win.7z

:thanks:

[JEEB]

x264 r1173 32bit
download (http://jeeb.fiveforty.jp/x264/1173/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1173/relnotes.txt)

built on Jun 26 2009, gcc: 4.3.3
fprofiled, -march=i686


x264 r1173 64bit
download (http://jeeb.fiveforty.jp/x264/1173_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1173_x64/relnotes.txt)

built on Jun 26 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


Both patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.13_interlace.diff
x264_AutoVAQ.03.diff


(the AutoVAQ patch version 3 only adds the 'AutoVAQ' behavior when --aq-mode is set to '2'. Therefore it should not change default behavior, which makes the point moot to build two separate builds. Life just got easier.)

[techouse]

x264_x64_r1173_unpatched (http://techouse.project357.com/builds/revision1173/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1173/x264.md5)
GCC 4.4.0 20090524 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1173_techouse (http://techouse.project357.com/builds/x264_x86_r1173_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1173_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1173_techouse (http://techouse.project357.com/builds/x264_x64_r1173_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1173_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff
x264_AutoVAQ.03.diff

[juGGaKNot]

Build request whenever anyone has the time :

Patches needed :

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff
x264_open_gop_hrd.2.diff
x264_AutoVAQ.03.diff

THNX in advance.

[Sharktooth]

opengop patch is not yet ready...

[juGGaKNot]

opengop patch is not yet ready...

Not functional or messy ?

[Sharktooth]

have you read the thread?

[Fr4nz]

New Imk x264 "ICC compiled" 1173 version (for Intel x86/x64) here:

http://imk.cx/pc/x264/x264-r1173M-imk-win.7z

[juGGaKNot]

Sorry for posting here, didn't want a new thread @ newbies, where can i find "x264 core 67 r1153M 7b6ce6a" ? i need it to see if the M stands for autovaq because the aq is set at 1:1.00 and autovaq 0.3 diff was not made @ 1153.

[shon3i]

Not functional or messy ?
For short gops ie bluray preset (1-24, 1-18) works perfectly from my tests.

[J_Darnley]

Sorry for posting here, didn't want a new thread @ newbies, where can i find "x264 core 67 r1153M 7b6ce6a" ? i need it to see if the M stands for autovaq because the aq is set at 1:1.00 and autovaq 0.3 diff was not made @ 1153.
Not necessarily. The 'M' just means modified. Look at the details posted for the file you downloaded.

[juGGaKNot]

Not necessarily. The 'M' just means modified. Look at the details posted for the file you downloaded.

I know but what was the modification, thats what i ask

Writing library : x264 core 67 r1153M 7b6ce6a aq=1:1.00

Its not a new autovaq 0.3 build to have 2:1.00 but it could be a 0.2 build or not at all autovaq, this is the problem, the M stands for what in this particular build ?

[Sharktooth]

M = Modified.

[microchip8]

Could someone update x264_hrd_pulldown.13_interlace.diff ?

Patching fails on latest x264 with the presets system added

[JEEB]

http://pastebin.ca/1486671

Applied nal-hrd onto an unpatched source tree, applied the failing parts by hand. diff -NdurwBE 'd it. Took the x264.c parts and put them into a patch. Should work, but I've yet to test. The changes are minor so I guess it should >_>

And now to the issue of the fprofile failing...

[komisar]

Adapted for 1178 x264_hrd_pulldown.13_interlace.1178.diff (http://komisar.gin.by/x.patch/x264_hrd_pulldown.13_interlace.1178.diff) (change TAB to SPACE, remove trailing space)

edit: option "--no-ssim --no-psnr --progress -w -8" in MAKEFILE for profiling fail...

edit: fixing fprofile x265_profile_fix.1178.diff (http://komisar.gin.by/x.patch/x265_profile_fix.1178.diff)

[JEEB]

Since with rev1179 all of it seems to have calmed down, more or less - here's a build. 32bit only for now, as VMware server doesn't want to connect to localhost it seems.

x264 r1179 32bit
download (http://jeeb.fiveforty.jp/x264/1179/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1179/relnotes.txt)

built on Jul 7 2009, gcc: 4.3.3
fprofiled, -march=i686


x264 r1179 64bit
download (http://jeeb.fiveforty.jp/x264/1179_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1179_x64/relnotes.txt)

built on Jul 10 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.13_interlace_modified.diff (http://pastebin.ca/1486671)
x264_AutoVAQ.03.diff

[techouse]

x264_x64_r1179_unpatched (http://techouse.project357.com/builds/revision1179/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1179/x264.md5)
GCC 4.4.0 20090524 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1179_techouse (http://techouse.project357.com/builds/x264_x86_r1179_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1179_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1179_techouse (http://techouse.project357.com/builds/x264_x64_r1179_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1179_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.13_interlace_modified.diff
x264_win_zone_parse_fix_05.diff
x264_AutoVAQ.03.diff

[JEEB]

x264 r1181 32bit
download (http://jeeb.fiveforty.jp/x264/1181/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1181/relnotes.txt)

built on Jul 11 2009, gcc: 4.3.3
fprofiled, -march=i686


x264 r1181 64bit
download (http://jeeb.fiveforty.jp/x264/1181_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1181_x64/relnotes.txt)

built on Jul 11 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.13_interlace_modified.diff (http://pastebin.ca/1486671)
x264_AutoVAQ.03.diff

[G_M_C]

/me is hoping for an update of IMK's ICC / SSE4.x build :)

[juGGaKNot]

/me is hoping for an update of IMK's ICC / SSE4.x build :)

What does it bring to the table so special ? intel cpus ?

[G_M_C]

What does it bring to the table so special ? intel cpus ?

I find that ICC builds are slightly faster on my QX9650.

[Fr4nz]

I find that ICC builds are slightly faster on my QX9650.

Unfortunately we'll have to wait because his video card is broken...read here (I received this message from him via Youtube yesterday):

However, the video card in my computer died and I'm $120 short of a new one. Until I can replace that video card I can't compile any new builds. I'm pretty broke at the moment, so it could take a month or more until I set aside $120 for a card. I'll let you know when I get it replaced.

We'll wait :(

[G_M_C]

Unfortunately we'll have to wait because his video card is broken...read here (I received this message from him via Youtube yesterday):



We'll wait :(

I'll wait too. Bummer the Video card broke. Never had one break in my system, but i dont OC videocards (only CPU's, which is easy with an unlocked "Extreme edition" ;) ).

[rack04]

What is the difference between -march=i686 and -march=core2?

[LoRd_MuldeR]

What is the difference between -march=i686 and -march=core2?

The C compiler is instructed to optimize the build either for an i686-family CPU or for an Intel Core2.
While the former allows the compiler to use the "PentiumPro" instruction set, the latter allows the compiler to use also SSE instructions (everything up to SSSE3).
Furthermore with -"march=core2" the compiler will optimize for different CPU timings...

In short: The "-march=i686" build should run on every CPU, except for some archaic ones. The "-march=core2" build should run a bit faster on a Core2 Duo.

See for details:
http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options

Note that this only effects the plain C code in x264. All the "hand-optimized" assembler code is not effected by compiler optimizations at all!
Also note that x264 uses it's own runtime CPU detection to decide which assembler functions will be used (or not used).

Compiler optimizations can squeeze out a bit more performance (ICC more than GCC), but the important speed-up happens in the assembler part of x264 ;)

[kemuri-_9]

pengvado (either here or on irc) stated that it's not icc's C compilation that is causing the speed up...
the cause is the icc equivalent to gcc's -mtune

[G_M_C]

pengvado (either here or on irc) stated that it's not icc's C compilation that is causing the speed up...
the cause is the icc equivalent to gcc's -mtune

[...]
Note that this only effects the plain C code in x264. All the "hand-optimized" assembler code is not effected by compiler optimizations at all!
Also note that x264 uses it's own runtime CPU detection to decide which assembler functions will be used (or not used).

Compiler optimizations can squeeze out a bit more performance (ICC more than GCC), but the important speed-up happens in the assembler part of x264 ;)

That's why I said that they' re only slightly faster. But on clips with > 200.000 frames even "slightly" counts to be a measurable timesaving ;)

I find that ICC builds are slightly faster on my QX9650.

[IgorC]

That's why I said that they' re only slightly faster. But on clips with > 200.000 frames even "slightly" counts to be a measurable timesaving ;)
1% is still tiny speed up for 100 or 10000 or any other number of frames.
This percentage is hardly noticeble for even >200.000 frames. If encoder gets 10 hours to encode then 1% will present only 6 minutes. It is nothing comparing to 10 hours.
It's still 1%.

[akupenguin]

pengvado stated (http://forum.doom9.org/showthread.php?p=1294634#post1294634) that it's not icc's C compilation that is causing the speed up...
the cause is the icc equivalent to gcc's -mtune
-mtune affects only C compilation.
I said that any difference between icc-sse2 and icc-ssse3 must be due to the -mtune part rather than the -march part, because icc-ssse3 didn't actually use any ssse3 (but it did include plenty of asm differences in non-sse code). This was not meant to explain any comparison between icc and some other compiler.

[Fr4nz]

1% is still tiny speed up for 100 or 10000 or any other number of frames.
This percentage is hardly noticeble for even >200.000 frames. If encoder gets 10 hours to encode then 1% will present only 6 minutes. It is nothing comparing to 10 hours.
It's still 1%.

Well, IIRC sometimes there's a difference of 4-5% in favor of ICC build, which would save 20-30 minutes...not much, but also better than nothing :)

Changing the subject, I have on question: my father has an AMD Phenom X4 9550 CPU and if I use the "DXVA-HQ preset" in MeGUI first pass is slightly slower than second pass (this does not happen on my Intel E6750 @3,3 ghz , on which the first pass is ~2.3x faster than the second pass)...how's it possible?

[nm]

Changing the subject, I have on question: my father has an AMD Phenom X4 9550 CPU and if I use the "DXVA-HQ preset" in MeGUI first pass is slightly slower than second pass (this does not happen on my Intel E6750 @3,3 ghz , on which the first pass is ~2.3x faster than the second pass)...how's it possible?
B-adapt 2 slows it down, probably. Frametype decision (which is done only in the first pass) is single-threaded, so it acts as a bottleneck on multi-core CPUs.

[Fr4nz]

B-adapt 2 slows it down, probably. Frametype decision (which is done only in the first pass) is single-threaded, so it acts as a bottleneck on multi-core CPUs.

This makes sense, but how's possibile that the Phenom is slowed down so much??

In order to give you an idea, if in the first pass i have 10-11fps/sec with my E6750@3,3ghz, with Phenom I have merely 5fps/sec...

[Dark Shikari]

This makes sense, but how's possibile that the Phenom is slowed down so much??Phenom has 4 cores, Core 2 Duo has only two?

[Fr4nz]

Phenom has 4 cores, Core 2 Duo has only two?

Intel E6750 has only 2 cores.

Furthermore, in order to give you a better idea of the "situation", second pass is faster on Phenom 9550 than on E6750.

[Dark Shikari]

Intel E6750 has only 2 cores.That's what I just said. What don't you understand? More cores means the penalty for using settings that cripple multithreading will hurt speed more.

[Fr4nz]

That's what I just said. What don't you understand? More cores means the penalty for using settings that cripple multithreading will hurt speed more.

Ok, what I don't understand is: is frametype decision (which is single threaded and indicated as the "culprit" by nm) so "heavy" in respect to other algorithms used by x264 so that Phenom 9550 is brutally outperformed (~2x) by an Intel E6750 in the first pass?

[nm]

One core of your overclocked E6750 outperforms one core of the Phenom by almost 2x. If b-adapt 2 dominates the encoding time because of fast first-pass parameters, this means that overall encoding is also twice as fast on the E6750. Just check x264's CPU usage during the first pass. I guess it's less than 50 % on the Phenom.

[kemuri-_9]

$ ./x264 -o NUL test.y4m --frames 1000 -b16
yuv4mpeg: 640x480@30/1fps, 0:0
x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT
x264 [info]: profile High, level 3.0
x264 [info]: slice I:6 Avg QP:13.84 size: 9284
x264 [info]: slice P:570 Avg QP:21.80 size: 7107
x264 [info]: slice B:424 Avg QP:24.58 size: 1312
x264 [info]: consecutive B-frames: 37.5% 22.5% 4.5% 7.6% 15.6% 11.5% 0.7% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

encoded 1000 frames, 92.89 fps, 1119.34 kb/s
~92% CPU across 4 cores

$ ./x264 -o NUL test.y4m --frames 1000 -b5 --b-adapt 2
x264 [info]: slice I:6 Avg QP:13.97 size: 8909
x264 [info]: slice P:507 Avg QP:21.69 size: 6518
x264 [info]: slice B:487 Avg QP:24.01 size: 1869
x264 [info]: consecutive B-frames: 22.2% 23.3% 47.4% 1.2% 1.0% 4.8%

encoded 1000 frames, 54.47 fps, 1024.58 kb/s
~70% CPU across 4 cores

$ ./x264 -o NUL test.y4m --frames 1000 -b16 --b-adapt 2
x264 [info]: slice I:6 Avg QP:13.97 size: 8906
x264 [info]: slice P:500 Avg QP:21.71 size: 6543
x264 [info]: slice B:494 Avg QP:23.96 size: 1853
x264 [info]: consecutive B-frames: 21.6% 23.3% 47.1% 1.2% 1.0% 1.8% 2.1% 0.8% 0.0% 1.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

encoded 1000 frames, 13.72 fps, 1017.91 kb/s
~37% CPU across 4 cores

b-adapt 2 reduces threading improvement as you increase the number of bframes:
5 being noticeable on default settings...
with 16 nearly destroying all threading speedup...

[Fr4nz]

b-adapt 2 reduces threading improvement as you increase the number of bframes:
5 being noticeable on default settings...
with 16 nearly destroying all threading speedup...

I see, thank you for the clarification! I didn't know that b-adapt is computationally so "heavy"...

[imk]

Dead video card is still dead. Using an old 1MB ATI All-in-Wonder PCI card for the time being. 1024x768 VGA mode is great. :(

Anyway...
x264-r1181M-imk-win.7z (http://imk.cx/pc/x264/x264-r1181M-imk-win.7z)
win_build_info.txt (http://imk.cx/pc/x264/win_build_info.txt)

[G_M_C]

Dead video card is still dead. Using an old 1MB ATI All-in-Wonder PCI card for the time being. 1024x768 VGA mode is great. :(

Anyway...
x264-r1181M-imk-win.7z (http://imk.cx/pc/x264/x264-r1181M-imk-win.7z)
win_build_info.txt (http://imk.cx/pc/x264/win_build_info.txt)

Thx for taking the time to build this, despite of the troubles !

[Fr4nz]

Dead video card is still dead. Using an old 1MB ATI All-in-Wonder PCI card for the time being. 1024x768 VGA mode is great. :(

Anyway...
x264-r1181M-imk-win.7z (http://imk.cx/pc/x264/x264-r1181M-imk-win.7z)
win_build_info.txt (http://imk.cx/pc/x264/win_build_info.txt)

Thank you! :D

[Zachs]

Is the threaded slicetype patch stable enough to be included yet? specifically v15: http://mailman.videolan.org/pipermail/x264-devel/2009-July/005988.html

Thanks.

[Underground78]

There is a v16 : http://mailman.videolan.org/pipermail/x264-devel/2009-July/006022.html ...

[Zachs]

@imk

Would greatly appreciate it if you could include x264-r1179-threaded-slicetype-v16-fix.diff

found here - http://kemuri9.net/dev/x264/patches/

[G_M_C]

@imk

Would greatly appreciate it if you could include x264-r1179-threaded-slicetype-v16-fix.diff

found here - http://kemuri9.net/dev/x264/patches/

Hmmm, i'd prefer only using patches that are known to be stable. Hopefully DS will be able to review this patch :)

[kemuri-_9]

Hmmm, i'd prefer only using patches that are known to be stable. Hopefully DS will be able to review this patch :)

DS has reviewed the v16 patch, and the -fix i made is the result to fix the crash he found...
other things that need fixing are non-critical...
1. removing changes to osdep.h
2. possibly removing/altering the section that sets the lookahead thread's priority (as it breaks BeOS compilation and from discussion from pengvado, negative values for priority should only work on linux and as root)

not to mention it's not official yet as i'm not the patch maintainer...
He's been busy with his job and hasn't yet come back to irc discuss the slight change i made from v16

but I've been using the patch as it's progressed along and have had no issues using it.

[Zachs]

Hmm. I gave kemuri-9's build a spin but didn't notice any difference at all using --rc-lookahead auto vs without. I would've thought that patch is to enable x264 to utilize multicores in first pass more effectively when --b-adapt 2 is used? With or without --rc-lookahead, my dual core 2.13GHz CPU stays at around 75%.

[Dark Shikari]

Yes, I'm not sure what's up with that; it seems to give far less benefit than I expected.

Either:

1. There is some major inefficiency in the patch (quite possible).
2. B-adapt 2 needs internal multithreading (I'll do this once threaded slicetype is committed).

[kemuri-_9]

$ ./x264-o NUL test.y4m --frames 1000 -b5 --b-adapt 2 --rc-lookahead auto
encoded 1000 frames, 57.30 fps, 1024.59 kb/s

$ ./x264 -o NUL test.y4m --frames 1000 -b16 --b-adapt 2 --rc-lookahead auto
encoded 1000 frames, 14.18 fps, 1017.92 kb/s

the difference from no lookahead to automatic on this quadcore is:
5 bframes: 54.47 fps -> 57.30 fps
16 bframes: 13.72 fps -> 14.18 fps

the speedup is there, it's just not very much from the level of how much b-adapt 2 can destroy threading performance currently.

my builds are also set to "-march=AMD", since that's what all 4 of my pcs+laptop are.
so if you're on an intel chip, you probably will get slightly lower speeds with my build compared to everyone else's "-march=intel" builds

2. B-adapt 2 needs internal multithreading (I'll do this once threaded slicetype is committed).
yes, this is very much needed from what I've seen.

[komisar]

threaded-slicetype speed result for Intel core i7 with settings "--preset placebo --tune touhou"
lookahead=0: 8.42 fps
lookahead=30: 8.95 fps
lookahead=60: 9.20 fps
lookahead=90: 9.26 fps
lookahead=120: 9.15 fps
lookahead=150: 9.19 fps
lookahead=180: 9.28 fps
lookahead=210: 9.10 fps
lookahead=240: 9.22 fps

Edit -> kemuri-_9, sure :) this is my inattention

[kemuri-_9]

lookahead=30: 8.95 fps (default for "auto")

that seems incorrect, auto sets the value to (bframes + threads) * 2
placebo has 16 bframes, so even without the thread value the automatic lookahead size is already > 30.
iirc, the i7 has 4 real and 4 ht cores, so auto threads should set it to 12,
so (12 + 16) * 2 = 56 is what lookahead auto should be setting the lookahead size to.

[Zachs]

An idea for a patch:

The Intel TBB (Threading Building Blocks) Allocator patch, using cache_aligned_allocator etc instead of x264_malloc. From my own experience using it in other projects, the tbb allocator is about 15% faster than HeapAlloc (called by malloc) and even faster when there's 2 or more threads are allocating / freeing at the same time, especially across different cores.

This should be fairly straight forward considering x264_malloc() / x264_free() already centralizes all allocations / free ops. If I have some time to setup the build environment with all the tools to merge diffs and stuff, I'd probably make one myself using MSVC2005.

[Dark Shikari]

An idea for a patch:

The Intel TBB (Threading Building Blocks) Allocator patch, using cache_aligned_allocator etc instead of x264_malloc. From my own experience using it in other projects, the tbb allocator is about 15% faster than HeapAlloc (called by malloc) and even faster when there's 2 or more threads are allocating / freeing at the same time, especially across different cores.

This should be fairly straight forward considering x264_malloc() / x264_free() already centralizes all allocations / free ops. If I have some time to setup the build environment with all the tools to merge diffs and stuff, I'd probably make one myself using MSVC2005.x264 allocates all memory at initialization. The time spent in malloc and free isn't even measurable.

[Zachs]

Yeah that's true. Even the frames in frame.c are recycled...

Would TBB help in anyway though? Like parallel loops and stuff?

[Dark Shikari]

Yeah that's true. Even the frames in frame.c are recycled...

Would TBB help in anyway though? Like parallel loops and stuff?x264 is already heavily threaded. There are no individual loops that run long enough without inter-iteration dependencies to make threading worth it.

[ACoolie]

If we're free to post ideas here, I tried working on it but don't really have the experience to get it done. An option --encoder-fps would tune your options every so many frames to try to match fps to --encoder-fps value. Bframes would be lowered or raised, refs decreased or increased, etc. It would be very useful if performing faster than a certain speed is crucial. The only issues I'd foresee is that certain options (like bframes) probably can't be changed very easily in the middle of encoding.