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.