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

[burfadel]

I didn't mean to connect it in that sense :) it could be also suggested to have --me-prepass enabled when UMH mode is selected (no point for ESA I believe?...), just as a matter of principle, since mode 7 or UMH are usually selected for quality.

[Terranigma]

I still think --me-prepass should be added as a default option.
Yes, I agree. Aku, any chance we'll ever see this in the svn? I could care less now about imh, but prepass, otoh, is pretty useful with esa as you've shown from your graphical comparisons. :)

[DeathTheSheep]

How the heck do you apply this diff to the source? What program?!

I always get crap like this every time I apply these patches:

$ patch -u -p1 < subme7.diff
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: encoder/me.c
|===================================================================
|--- encoder/me.c (revision 676)
|+++ encoder/me.c (working copy)
--------------------------
File to patch: encoder/me.c
patching file `encoder/me.c'
Hunk #1 succeeded at 28 (offset 1 line).
Hunk #2 succeeded at 853 (offset 51 lines).
patch unexpectedly ends in middle of line
Hunk #3 FAILED at 912.
1 out of 3 hunks FAILED -- saving rejects to encoder/me.c.rej

Then I manually patch. And that's just for subme.. Take a look at prepass:

$ patch -u -p1 < me-prepass.diff
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: common/common.c
|===================================================================
|--- common/common.c (revision 675)
|+++ common/common.c (working copy)
--------------------------
File to patch: common/common.c
patching file `common/common.c'
Hunk #1 succeeded at 444 (offset 3 lines).
Hunk #2 succeeded at 882 with fuzz 2 (offset 1 line).
can't find file to patch at input line 26
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: encoder/me.c
|===================================================================
|--- encoder/me.c (revision 675)
|+++ encoder/me.c (working copy)
--------------------------
File to patch: encoder/me.c
patching file `encoder/me.c'
Hunk #1 succeeded at 65 (offset 4 lines).
patch: **** malformed patch at line 142: + }

And nothing happens at all. No .rej is created to manually patch off of like for subme, so I have to go through line by line and type it all in by hand.

I think I'm going to memorize this algorithm by heart by the time I'm through with these darn patch problems!

Again, how do you guys do it?! I'm in msys 1.0 using the standard $ patch program... the settings I used are shown above...

[DeathTheSheep]

And what exactly happened to cost_mv_hpel? You go right from cost_mv to cost_mv_hpel2... It's still used, but its define is gone? :p

Maybe you just have some odd organization and moved it somewhere else in the code so the patch's context is off. I'm glad I caught that, though--I just wonder what other crucial instructions I've unwittingly overwritten as I blindly followed the patch?! :D

[Dark Shikari]

And what exactly happened to cost_mv_hpel? You go right from cost_mv to cost_mv_hpel2... It's still used, but its define is gone? :p

Maybe you just have some odd organization and moved it somewhere else in the code so the patch's context is off. I'm glad I caught that, though--I just wonder what other crucial instructions I've unwittingly overwritten as I blindly followed the patch?! :D
Hpel is in the original code, so it doesn't need to be defined again :p

[DeathTheSheep]

True, but in the context of your patch, it jumps right from cost_mv (which is already defined) to cost_mv_hpel2. Meaning when I insert it over the context (first and last lines in your patch), it is no longer in the original source!

Meaning, of course, when I Ctrl+A to select all the code for each code block in the patch and paste that block into the .c, I simply start from the first context line and overwrite everything in the original until the last context line, meaning everything in between is overwritten with the lines of the patch.

I then go in and delete all the little "+" signs next to the added lines and manually remove all the lines marked with "-." I know hpel is not "removed" as in marked with the "-", but if you look at your patch's context lines...
So you can understand why the patch threw me off :).

Index: encoder/me.c
===================================================================
--- encoder/me.c (revision 675)
+++ encoder/me.c (working copy)
@@ -61,6 +61,23 @@
COPY3_IF_LT( bpred_cost, cost, bpred_mx, mx, bpred_my, my ); \ (this is the first line I overwrote, extending to the end...)
}

<but hpel was in here, so it disappeared when I overwrote it with this patch, since it's obviously not here now!>

+#define COST_MV_HPEL2( mx, my, cost ) \
+{ \
+ int stride = 16; \
+ uint8_t *src = h->mc.get_ref( m->p_fref, m->i_stride[0], pix, &stride, mx, my, bw, bh ); \
+ cost = h->pixf.fpelcmp[i_pixel]( m->p_fenc[0], FENC_STRIDE, src, stride ) \
+ + p_cost_mvx[ mx ] + p_cost_mvy[ my ]; \
+}

:p

[Dark Shikari]

Sorry if my diffing skills are nonexistent :p

[DeathTheSheep]

Lol, no problem. But next time could you put up the whole function (or source code?) instead of the diff? Much easier to manually apply that way. :D

Oh, I noticed the new prepass beefs up the filesize along with the SSIM at constant quantization. Is this normal, or is something b0rked for me?

And quality remains constant (and filesize increases!) as merange is increased... FtW? :p Tested with esa, of course... Satd.

[edit]Yes, as I suspected there is something hideously wrong here. Without any prepass at all, differs drastically from an old build without it. Yeah, some patched sources would help like crazy. XD

[Dark Shikari]

Lol, no problem. But next time could you put up the whole function (or source code?) instead of the diff? Much easier to manually apply that way. :D

Oh, I noticed the new prepass beefs up the filesize along with the SSIM at constant quantization. Is this normal, or is something b0rked for me?

And quality remains constant (and filesize increases!) as merange is increased... FtW? :p Tested with esa, of course... Satd.

[edit]Yes, as I suspected there is something hideously wrong here. Without any prepass at all, differs drastically from an old build without it. Yeah, some patched sources would help like crazy. XD
Here is the beginning of my source up to the start of ME-DIA and such:

/*****************************************************************************
* me.c: h264 encoder library (Motion Estimation)
*****************************************************************************
* Copyright (C) 2003 Laurent Aimar
* $Id: me.c,v 1.1 2004/06/03 19:27:08 fenrir Exp $
*
* Authors: Laurent Aimar <fenrir@via.ecp.fr>
* Loren Merritt <lorenm@u.washington.edu>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA.
*****************************************************************************/

#include "common/common.h"
#include "me.h"
#include <limits.h>

/* presets selected from good points on the speed-vs-quality curve of several test videos
* subpel_iters[i_subpel_refine] = { refine_hpel, refine_qpel, me_hpel, me_qpel }
* where me_* are the number of EPZS iterations run on all candidate block types,
* and refine_* are run only on the winner. */
//The --subme 7 values are much higher because since they get the motion search
//closer to the optimal value, they actually tend to save time in the more intensive
//RD search that follows.
static const int subpel_iterations[][4] =
{{1,0,0,0},
{1,1,0,0},
{0,1,1,0},
{0,2,1,0},
{0,2,1,1},
{0,2,1,2},
{0,0,2,2},
{0,0,4,10}};

static void refine_subpel( x264_t *h, x264_me_t *m, int hpel_iters, int qpel_iters, int *p_halfpel_thresh, int b_refine_qpel );

#define BITS_MVD( mx, my )\
(p_cost_mvx[(mx)<<2] + p_cost_mvy[(my)<<2])

#define COST_MV( mx, my )\
{\
int cost = h->pixf.fpelcmp[i_pixel]( m->p_fenc[0], FENC_STRIDE,\
&p_fref[(my)*m->i_stride[0]+(mx)], m->i_stride[0] )\
+ BITS_MVD(mx,my);\
COPY3_IF_LT( bcost, cost, bmx, mx, bmy, my );\
}

#define COST_MV_HPEL( mx, my ) \
{ \
int stride = 16; \
uint8_t *src = h->mc.get_ref( m->p_fref, m->i_stride[0], pix, &stride, mx, my, bw, bh ); \
int cost = h->pixf.fpelcmp[i_pixel]( m->p_fenc[0], FENC_STRIDE, src, stride ) \
+ p_cost_mvx[ mx ] + p_cost_mvy[ my ]; \
COPY3_IF_LT( bpred_cost, cost, bpred_mx, mx, bpred_my, my ); \
}

#define COST_MV_HPEL2( mx, my, cost ) \
{ \
int stride = 16; \
uint8_t *src = h->mc.get_ref( m->p_fref, m->i_stride[0], pix, &stride, mx, my, bw, bh ); \
cost = h->pixf.fpelcmp[i_pixel]( m->p_fenc[0], FENC_STRIDE, src, stride ) \
+ p_cost_mvx[ mx ] + p_cost_mvy[ my ]; \
}

#define COST_MV_HPEL3( mx, my) \
{ \
int stride = 16; \
uint8_t *src = h->mc.get_ref( m->p_fref, m->i_stride[0], pix, &stride, mx, my, bw, bh ); \
int cost = h->pixf.fpelcmp[i_pixel]( m->p_fenc[0], FENC_STRIDE, src, stride ) \
+ p_cost_mvx[ mx ] + p_cost_mvy[ my ]; \
COPY3_IF_LT( bestcost, cost, bestx, mx, besty, my ); \
}

#define COST_MV_X3_DIR( m0x, m0y, m1x, m1y, m2x, m2y, costs )\
{\
uint8_t *pix_base = p_fref + bmx + bmy*m->i_stride[0];\
h->pixf.fpelcmp_x3[i_pixel]( m->p_fenc[0],\
pix_base + (m0x) + (m0y)*m->i_stride[0],\
pix_base + (m1x) + (m1y)*m->i_stride[0],\
pix_base + (m2x) + (m2y)*m->i_stride[0],\
m->i_stride[0], costs );\
(costs)[0] += BITS_MVD( bmx+(m0x), bmy+(m0y) );\
(costs)[1] += BITS_MVD( bmx+(m1x), bmy+(m1y) );\
(costs)[2] += BITS_MVD( bmx+(m2x), bmy+(m2y) );\
}

#define COST_MV_X4( m0x, m0y, m1x, m1y, m2x, m2y, m3x, m3y )\
{\
uint8_t *pix_base = p_fref + omx + omy*m->i_stride[0];\
h->pixf.fpelcmp_x4[i_pixel]( m->p_fenc[0],\
pix_base + (m0x) + (m0y)*m->i_stride[0],\
pix_base + (m1x) + (m1y)*m->i_stride[0],\
pix_base + (m2x) + (m2y)*m->i_stride[0],\
pix_base + (m3x) + (m3y)*m->i_stride[0],\
m->i_stride[0], costs );\
costs[0] += BITS_MVD( omx+(m0x), omy+(m0y) );\
costs[1] += BITS_MVD( omx+(m1x), omy+(m1y) );\
costs[2] += BITS_MVD( omx+(m2x), omy+(m2y) );\
costs[3] += BITS_MVD( omx+(m3x), omy+(m3y) );\
COPY3_IF_LT( bcost, costs[0], bmx, omx+(m0x), bmy, omy+(m0y) );\
COPY3_IF_LT( bcost, costs[1], bmx, omx+(m1x), bmy, omy+(m1y) );\
COPY3_IF_LT( bcost, costs[2], bmx, omx+(m2x), bmy, omy+(m2y) );\
COPY3_IF_LT( bcost, costs[3], bmx, omx+(m3x), bmy, omy+(m3y) );\
}

#define COST_MV_X4_ABS( m0x, m0y, m1x, m1y, m2x, m2y, m3x, m3y )\
{\
h->pixf.fpelcmp_x4[i_pixel]( m->p_fenc[0],\
p_fref + (m0x) + (m0y)*m->i_stride[0],\
p_fref + (m1x) + (m1y)*m->i_stride[0],\
p_fref + (m2x) + (m2y)*m->i_stride[0],\
p_fref + (m3x) + (m3y)*m->i_stride[0],\
m->i_stride[0], costs );\
costs[0] += p_cost_mvx[m0x<<2]; /* no cost_mvy */\
costs[1] += p_cost_mvx[m1x<<2];\
costs[2] += p_cost_mvx[m2x<<2];\
costs[3] += p_cost_mvx[m3x<<2];\
COPY3_IF_LT( bcost, costs[0], bmx, m0x, bmy, m0y );\
COPY3_IF_LT( bcost, costs[1], bmx, m1x, bmy, m1y );\
COPY3_IF_LT( bcost, costs[2], bmx, m2x, bmy, m2y );\
COPY3_IF_LT( bcost, costs[3], bmx, m3x, bmy, m3y );\
}

/* 1 */
/* 101 */
/* 1 */
#define DIA1_ITER( mx, my )\
{\
omx = mx; omy = my;\
COST_MV_X4( 0,-1, 0,1, -1,0, 1,0 );\
}

#define DIA2_ITER( mx, my )\
{\
omx = mx; omy = my;\
COST_MV_X4( 0,-2, 0,2, -2,0, 2,0 );\
}

#define CROSS( start, x_max, y_max )\
{\
i = start;\
if( x_max <= X264_MIN(mv_x_max-omx, omx-mv_x_min) )\
for( ; i < x_max-2; i+=4 )\
COST_MV_X4( i,0, -i,0, i+2,0, -i-2,0 );\
for( ; i < x_max; i+=2 )\
{\
if( omx+i <= mv_x_max )\
COST_MV( omx+i, omy );\
if( omx-i >= mv_x_min )\
COST_MV( omx-i, omy );\
}\
i = start;\
if( y_max <= X264_MIN(mv_y_max-omy, omy-mv_y_min) )\
for( ; i < y_max-2; i+=4 )\
COST_MV_X4( 0,i, 0,-i, 0,i+2, 0,-i-2 );\
for( ; i < y_max; i+=2 )\
{\
if( omy+i <= mv_y_max )\
COST_MV( omx, omy+i );\
if( omy-i >= mv_y_min )\
COST_MV( omx, omy-i );\
}\
}

#define ME_HEX(X,Y,range)\
{\
static const int mod6[8] = {5,0,1,2,3,4,5,0};\
bmx = X;\
bmy = Y;\
dir = -2;\
COST_MV_X3_DIR( -2,0, -1, 2, 1, 2, costs );\
COST_MV_X3_DIR( 2,0, 1,-2, -1,-2, costs+3 );\
COPY2_IF_LT( bcost, costs[0], dir, 0 );\
COPY2_IF_LT( bcost, costs[1], dir, 1 );\
COPY2_IF_LT( bcost, costs[2], dir, 2 );\
COPY2_IF_LT( bcost, costs[3], dir, 3 );\
COPY2_IF_LT( bcost, costs[4], dir, 4 );\
COPY2_IF_LT( bcost, costs[5], dir, 5 );\
if( dir != -2 ) {\
static const int hex2[8][2] = {{-1,-2}, {-2,0}, {-1,2}, {1,2}, {2,0}, {1,-2}, {-1,-2}, {-2,0}};\
bmx += hex2[dir+1][0];\
bmy += hex2[dir+1][1];\
for( i = 1; i < range && CHECK_MVRANGE(bmx, bmy); i++ )\
{\
const int odir = mod6[dir+1];\
COST_MV_X3_DIR( hex2[odir+0][0], hex2[odir+0][1],\
hex2[odir+1][0], hex2[odir+1][1],\
hex2[odir+2][0], hex2[odir+2][1],\
costs );\
dir = -2;\
COPY2_IF_LT( bcost, costs[0], dir, odir-1 );\
COPY2_IF_LT( bcost, costs[1], dir, odir );\
COPY2_IF_LT( bcost, costs[2], dir, odir+1 );\
if( dir == -2 ) break;\
bmx += hex2[dir+1][0];\
bmy += hex2[dir+1][1];}\
if(dir == -2 || bcost > bestCost) {}\
else{\
for( i = 1; i < range && CHECK_MVRANGE(bmx, bmy); i++ )\
{\
const int odir = mod6[dir+1];\
COST_MV_X3_DIR( hex2[odir+0][0], hex2[odir+0][1],\
hex2[odir+1][0], hex2[odir+1][1],\
hex2[odir+2][0], hex2[odir+2][1],\
costs );\
dir = -2;\
COPY2_IF_LT( bcost, costs[0], dir, odir-1 );\
COPY2_IF_LT( bcost, costs[1], dir, odir );\
COPY2_IF_LT( bcost, costs[2], dir, odir+1 );\
if( dir == -2 ) break;\
bmx += hex2[dir+1][0];\
bmy += hex2[dir+1][1];}}}\
omx = bmx; omy = bmy;\
COST_MV_X4( 0,-1, 0,1, -1,0, 1,0 );\
COST_MV_X4( -1,-1, -1,1, 1,-1, 1,1 );\
}\

void x264_me_search_ref( x264_t *h, x264_me_t *m, int (*mvc)[2], int i_mvc, int *p_halfpel_thresh )
{
int cost;
const int bw = x264_pixel_size[m->i_pixel].w;
const int bh = x264_pixel_size[m->i_pixel].h;
const int i_pixel = m->i_pixel;
int i_me_range = h->param.analyse.i_me_range;
int bmx, bmy, bcost;
int bpred_mx = 0, bpred_my = 0, bpred_cost = COST_MAX;
int omx, omy, pmx, pmy;
uint8_t *p_fref = m->p_fref[0];
DECLARE_ALIGNED( uint8_t, pix[16*16], 16 );

int i, j;
int dir;
int costs[6];

int mv_x_min = h->mb.mv_min_fpel[0];
int mv_y_min = h->mb.mv_min_fpel[1];
int mv_x_max = h->mb.mv_max_fpel[0];
int mv_y_max = h->mb.mv_max_fpel[1];
int mv_x_min4 = h->mb.mv_min_fpel[0]<<2;
int mv_y_min4 = h->mb.mv_min_fpel[1]<<2;
int mv_x_max4 = h->mb.mv_max_fpel[0]<<2;
int mv_y_max4 = h->mb.mv_max_fpel[1]<<2;

#define CHECK_MVRANGE(mx,my) ( mx >= mv_x_min && mx <= mv_x_max && my >= mv_y_min && my <= mv_y_max )
#define CHECK_MVRANGE4(mx,my) ( mx >= mv_x_min4 && mx <= mv_x_max4 && my >= mv_y_min4 && my <= mv_y_max4 )

const int16_t *p_cost_mvx = m->p_cost_mv - m->mvp[0];
const int16_t *p_cost_mvy = m->p_cost_mv - m->mvp[1];

bmx = x264_clip3( m->mvp[0], mv_x_min*4, mv_x_max*4 );
bmy = x264_clip3( m->mvp[1], mv_y_min*4, mv_y_max*4 );
pmx = ( bmx + 2 ) >> 2;
pmy = ( bmy + 2 ) >> 2;
bcost = COST_MAX;

/* try extra predictors if provided */
if( h->mb.i_subpel_refine >= 3 )
{
COST_MV_HPEL( bmx, bmy );
if(!h->param.analyse.i_me_prepass)
{
for( i = 0; i < i_mvc; i++ )
{
const int mx = x264_clip3( mvc[i][0], mv_x_min*4, mv_x_max*4 );
const int my = x264_clip3( mvc[i][1], mv_y_min*4, mv_y_max*4 );
if( mx != bpred_mx || my != bpred_my )
COST_MV_HPEL( mx, my );
}
}
else
{
for( i = 0; i < i_mvc; i++ )
{
const int mx = x264_clip3( mvc[i][0], mv_x_min*4, mv_x_max*4 );
const int my = x264_clip3( mvc[i][1], mv_y_min*4, mv_y_max*4 );
int doSearch = 1;
int j;
for(j = 0; j < i; j++)
{
if(mvc[i][0] == mvc[j][0] && mvc[i][1] == mvc[j][1]) doSearch = 0;
}
if( ( mx != bpred_mx || my != bpred_my ) && doSearch)
{
int bestcost;
int bestx = mx;
int besty = my;
COST_MV_HPEL2( mx, my, bestcost );
COPY3_IF_LT( bpred_cost, bestcost, bpred_mx, bestx, bpred_my, besty );
if(bestcost < 2*bpred_cost)
{
int n;
int dir = -2;
COST_MV_HPEL2(bestx-4,besty,costs[0]);
COST_MV_HPEL2(bestx-2,besty+4,costs[1]);
COST_MV_HPEL2(bestx+2,besty+4,costs[2]);
COST_MV_HPEL2(bestx+4,besty,costs[3]);
COST_MV_HPEL2(bestx+2,besty-4,costs[4]);
COST_MV_HPEL2(bestx-2,besty-4,costs[5]);
COPY2_IF_LT( bestcost, costs[0], dir, 0 );
COPY2_IF_LT( bestcost, costs[1], dir, 1 );
COPY2_IF_LT( bestcost, costs[2], dir, 2 );
COPY2_IF_LT( bestcost, costs[3], dir, 3 );
COPY2_IF_LT( bestcost, costs[4], dir, 4 );
COPY2_IF_LT( bestcost, costs[5], dir, 5 );
if( dir != -2 )
{
static const int hex2[8][2] = {{-2,-4}, {-4,0}, {-2,4}, {2,4}, {4,0}, {2,-4}, {-2,-4}, {-4,0}};
bestx += hex2[dir+1][0];
besty += hex2[dir+1][1];
for( n = 1; n < i_me_range && CHECK_MVRANGE4(bestx, besty); n++ )
{
static const int mod6[8] = {5,0,1,2,3,4,5,0};
const int odir = mod6[dir+1];
COST_MV_HPEL2(hex2[odir+0][0]+bestx,hex2[odir+0][1]+besty,costs[0]);
COST_MV_HPEL2(hex2[odir+1][0]+bestx,hex2[odir+1][1]+besty,costs[1]);
COST_MV_HPEL2(hex2[odir+2][0]+bestx,hex2[odir+2][1]+besty,costs[2]);
dir = -2;
COPY2_IF_LT( bestcost, costs[0], dir, odir-1 );
COPY2_IF_LT( bestcost, costs[1], dir, odir );
COPY2_IF_LT( bestcost, costs[2], dir, odir+1 );
if( dir == -2 )
break;
bestx += hex2[dir+1][0];
besty += hex2[dir+1][1];
}
}
COST_MV_HPEL3(bestx+2,besty-2);
COST_MV_HPEL3(bestx+2,besty);
COST_MV_HPEL3(bestx+2,besty+2);
COST_MV_HPEL3(bestx,besty-2);
COST_MV_HPEL3(bestx,besty+2);
COST_MV_HPEL3(bestx-2,besty-2);
COST_MV_HPEL3(bestx-2,besty);
COST_MV_HPEL3(bestx-2,besty+2);
COPY3_IF_LT(bpred_cost,bestcost,bpred_mx,bestx,bpred_my,besty);
}
}
}
}
bmx = ( bpred_mx + 2 ) >> 2;
bmy = ( bpred_my + 2 ) >> 2;
COST_MV( bmx, bmy );
}
else
{
/* check the MVP */
COST_MV( pmx, pmy );
/* I don't know why this helps */
bcost -= BITS_MVD(bmx,bmy);

for( i = 0; i < i_mvc; i++ )
{
const int mx = x264_clip3( ( mvc[i][0] + 2 ) >> 2, mv_x_min, mv_x_max );
const int my = x264_clip3( ( mvc[i][1] + 2 ) >> 2, mv_y_min, mv_y_max );
if( mx != bmx || my != bmy )
COST_MV( mx, my );
}
}

COST_MV( 0, 0 );

[DeathTheSheep]

This is with subme7 patch and satd, obviously, which is good. Any other patches in here that would cause conflicts? And I assume this is r680?

If this is all clear, this is ready and rearin' to go!! :)

[Dark Shikari]

This is with subme7 patch and satd, obviously, which is good. Any other patches in here that would cause conflicts? And I assume this is r680?

If this is all clear, this is ready and rearin' to go!! :)
r676, but I don't think anything since then has changed this part of the file.

[DeathTheSheep]

Nice.

PS: Only 3 more posts to go, Dark Shikari... :)

[morph166955]

easiest way to create a diff:

1) make distclean (if needed)
2) svn diff > mydiff.diff

DONE! Thats how I build my patches. To apply I use "patch -Np0 -i mydiff.diff"

[Inventive Software]

F***. I have no internet for a few days, and this happens! So many patches, so little time to investigate all their merits and caveats and speed boosts and quality improvements and I'm exhausted typing this sentence already!

Back to simplicity for now! F***! :D

Good work morph166955 on compiling the list so it's at least more readable. Good work Dark Shikari on firstly explaining the patches well, and on getting 1000 posts. :)

Suggestion to the mods: STICKY!!! ;)

And I hit 1000 posts a while ago and I didn't notice! :D

[akupenguin]

1) make distclean (if needed)
Superfluous. None of the generated files is in the repository, so svn diff knows to ignore them.

[morph166955]

fair enough...wasnt sure and i figured it couldnt really hurt matters to do a distclean before generating the diff.

[dirio49]

No idea if it is the right thread.
but can anybody tell what do i need to cross compile x264 for win
i have gcc-minge32 4.2.1 installed (on gentoo)
thanks
what command(2) to i need to run

later

P.S. if it is in the wrong thread please move it.

[TheRyuu]

How would one go about updating the Subme 7 patch to be compatible with rev. 680?

or, would someone please do it? :)
I want to try it out but it's not patching correctly with rev 680.

Thanks.

[foxyshadis]

No idea if it is the right thread.
but can anybody tell what do i need to cross compile x264 for win
i have gcc-minge32 4.2.1 installed (on gentoo)
thanks
what command(2) to i need to run

later

P.S. if it is in the wrong thread please move it.

Check this thread: https://forum.doom9.org/showthread.php?t=92726

[TheRyuu]

Ok, did some fiddling around and built it with the subme7 patch, faster dai patch, thread pool patch, and aq patch.

Those 4 patches I think are probably the 4 most use full patches that there are right now.

http://www.sendspace.com/file/oo3j2l

Thats the build. It's generic (cpu needs mmx support though, which should basically be all of us).
Has build options of enable avis input, pthread, and mp4 output.

I have no idea if it works, all the patches were applied successfully except for the subme7 patch, which I had to manually copy and paste over (and delete lines), but it built, so I assume I did it correctly.

If you want me to try and build any other combination of patches, ask me and I might have free time to do it.

[Raere]

Ok, did some fiddling around and built it with the subme7 patch, faster dai patch, thread pool patch, and aq patch.

Those 4 patches I think are probably the 4 most use full patches that there are right now.

http://www.sendspace.com/file/oo3j2l

Thats the build. It's generic (cpu needs mmx support though, which should basically be all of us).
Has build options of enable avis input, pthread, and mp4 output.

I have no idea if it works, all the patches were applied successfully except for the subme7 patch, which I had to manually copy and paste over (and delete lines), but it built, so I assume I did it correctly.

If you want me to try and build any other combination of patches, ask me and I might have free time to do it.

Are you using r680?

Maybe you could make another build with imh and me-prepass? I use those, so they're useful for me. If they're not hard to implement, why not? Also, I don't know what they're calling hadamard these days, but can that be implemented too? As far as I know that's still somewhat useful. And maybe an SSE2 build, as I think most everyone who's encoding x264 at least has SSE2. I dunno, just a thought if you have time. Thanks!

[Terranigma]

Are you using r680?
Also, I don't know what they're calling hadamard these days, but can that be implemented too?
--hadamard has been renamed to --fpel-cmp followed by satd (Sum of Absolute Hadamard Transformed Differences)
(Default, it uses Sum of Absolute Differences/SAD).
so, an e.g. would be
--fpel-cmp satd
satd is hadamard, and iirc, it made it in the svn.

[Sharktooth]

--fpel-cmp is not in the svn.

[Terranigma]

--fpel-cmp is not in the svn.
You're right, I just tested using rev. 680 from x264.nl:
http://i24.tinypic.com/f4henl.png

:p

[TheRyuu]

Are you using r680?

Maybe you could make another build with imh and me-prepass? I use those, so they're useful for me. If they're not hard to implement, why not? Also, I don't know what they're calling hadamard these days, but can that be implemented too? As far as I know that's still somewhat useful. And maybe an SSE2 build, as I think most everyone who's encoding x264 at least has SSE2. I dunno, just a thought if you have time. Thanks!

x264's main stuff is written in asm so using a build that used sse2 in it would pretty much be useless in terms of speed increase (considering only 1 part of x264 uses code that the compiler generates that way).

http://www.sendspace.com/file/ei6xlw

That is x264 with the following patches:
-thread pool
-AQ
-IMH
-Faster dai
-Subme7
-me-prepass
-fpel (hadamard, or however you spell it)

Causes x264.exe to weigh in it a hefty 1.03mb :p
I have absolutely no idea if it'll work. It built fine without errors, so it should work. Have fun trying it out :)
All the patches together might in some way screw something up. I have no idea, but all the patches applied, applied without errors, those that did give errors were patched manually by hand.

[foxyshadis]

Seems to work okay for me. SATD halving the speed while raising quality the tiniest bit. :p The other patches seem to be working okay too.

[Raere]

x264's main stuff is written in asm so using a build that used sse2 in it would pretty much be useless in terms of speed increase (considering only 1 part of x264 uses code that the compiler generates that way).

http://www.sendspace.com/file/ei6xlw

That is x264 with the following patches:
-thread pool
-AQ
-IMH
-Faster dai
-Subme7
-me-prepass
-fpel (hadamard, or however you spell it)

Causes x264.exe to weigh in it a hefty 1.03mb :p
I have absolutely no idea if it'll work. It built fine without errors, so it should work. Have fun trying it out :)
All the patches together might in some way screw something up. I have no idea, but all the patches applied, applied without errors, those that did give errors were patched manually by hand.

Awesome, thanks! Works for me. I really have no idea about processor optimizations, so thanks for the info.

[TheRyuu]

SATD halving the speed while raising quality the tiniest bit. :p

Thats normal right? :)

[TheRyuu]

Another question:
What patches are worth while to actually use (like don't effect speed at all, or only effect speed a little, and obviously increase the quality).

So far I think that these are worthwhile:
-faster dia
-subme7 patch
-AQ
-thread pool (not really effecting quality but still a needed patch)

I'm curious about the following patches:
-fpel patch (heard this was really slow)
-me-prepass
-IMH (vs. exhaustive vs UMH)

btw, what do the bchanges and bssd patch do?

Thanks

[Dark Shikari]

-faster dia
Not worthwhile. Proven to give dubious benefits in only some cases.

-fpel patch (heard this was really slow)
The --fpel patch with ESA is not much slower than regular ESA and somewhat better, so its "worthwhile" as an insane option.
-me-prepassUseful as a higher-end option in place of using absurd numbers of refs. Can give a roughly 1-3% quality boost with the most recent version.
-IMH (vs. exhaustive vs UMH)Pretty much useless with ESA now threaded.

[Gabriel_Bouvigne]

btw, what do the bchanges and bssd patch do?


http://mailman.videolan.org/pipermail/x264-devel/2007-August/003559.html

bssd:
when using --direct auto in multipass mode, in case of tie between direct auto and direct temporal, use SSD as an extra criterion to choose direct mode

[Sagekilla]

Not worthwhile. Proven to give dubious benefits in only some cases.


The --fpel patch with ESA is not much slower than regular ESA and somewhat better, so its "worthwhile" as an insane option.
Useful as a higher-end option in place of using absurd numbers of refs. Can give a roughly 1-3% quality boost with the most recent version.
Pretty much useless with ESA now threaded.

But IMH would be better then ESA if you want a sort of middle ground with not too huge of a speed loss, correct?

[Sharktooth]

no... IMH is practically useless. the difference in speed is so small it isnt worthwhile.

[Terranigma]

no... IMH is practically useless. the difference in speed is so small it isnt worthwhile.

I agree with these guys here. Sharktooth and Shikari made me realize that it's virtually useless when you now have esa multithreaded. :D

[Sagekilla]

Wow good point.. I just tried out the threaded esa and I must say it's insanely fast!

[Raere]

Will esa's multithreading be useful on single-cores, or is it only good for multi-cores?

[Sharktooth]

Multicores as usual.

[Raere]

So, imh is still useful on single-cores then?

[Terranigma]

So, imh is still useful on single-cores then?

Sorta, but who has a single-core processor nowadays?

[lexor]

Sorta, but who has a single-core processor nowadays?

Aw, my pride...

Lots of people still use single core, I'd hazard a guess, majority is still on single core. (majority in the world, not just on these boards)

[Sharktooth]

single core ppl should not bother using ESA or IMH...
They should stick to saner settings unless they dont care about encoding speed at all...

[Unearthly]

So, imh is still useful on single-cores then?

Not really. The reason IMH was useful before was because it offered higher quality than UMH, but was multi-threaded. At the time, ESA was only single threaded, so the speed difference on a mutli-core systems was very large.

In other words, IMH was never really useful on single core machines. Just use ESA if you want more than UMH.

[SpAwN_gUy]

i'm sorry...
is there somebody who will update first-post, so all changes to the patches would be more "in one place" and i'd be happy to use them with 681 (as seen on x264.nl)

reason for this: i've noticed some chat about changing option names in Dark Shikari's patches..

[fields_g]

Another idea to add to the OP is limitations of the patch and/or an explanation of why it hasn't been added to SVN. Really help point out the maturity and support of each patch. This might need the help of akupenguin.

[Dark Shikari]

Another idea to add to the OP is limitations of the patch and/or an explanation of why it hasn't been added to SVN. Really help point out the maturity and support of each patch. This might need the help of akupenguin.Subme7 is ready to add to SVN, hopefully it'll be done soon.

ME-Prepass is next.

[Inventive Software]

From the x264 changelog:
use hex instead of dia for rdo mv refinement. ~0.5% lower bitrate at subme=7.
patch by Dark Shikari.

That the patch you're on about?

[Dark Shikari]

From the x264 changelog:
That the patch you're on about?Yup, that's it.

[morph166955]

i'm sorry...
is there somebody who will update first-post, so all changes to the patches would be more "in one place" and i'd be happy to use them with 681 (as seen on x264.nl)

reason for this: i've noticed some chat about changing option names in Dark Shikari's patches..

If someone gives me a list of them I'll be happy to update my post.

[bob0r]

x264.736.modified.01.exe (http://files.x264.nl/x264.736.modified.01.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_aq_var.48.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.4.MatMaul.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-January/004015.html
x264_hrd_pulldown.04.diff
- HRD and pulldown for HD compatibility

Edit:
Link to x264 patches collected: http://files.x264.nl/x264_patches/

[bob0r]

x264.736.modified.02.exe (http://files.x264.nl/x264.736.modified.02.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_aq_var.48.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.4.MatMaul.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3521
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Edit:
Link to x264 patches collected: http://files.x264.nl/x264_patches/