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

[Dark Shikari]

Originally Posted by komisar

Yes, --no-cabac broken. I find "broker"... Not work from 928 revision...

Worksforme. "Its broken" is a completely useless bug report, by the way; unless its very obvious what you think is broken, I have no idea what you're talking about.

[komisar]

Sorry. I talked about my build. The problem arises when I use make fprofiled with gcc version 4.4.0 20080822 (experimental) (GCC). Standard build raises the same error. I try update my gcc from svn...

[Dark Shikari]

Originally Posted by komisar

Sorry. I talked about my build. The problem arises when I use make fprofiled with gcc version 4.4.0 20080822 (experimental) (GCC). Standard build raises the same error. I try update my gcc from svn...

Ah. Have you pinpointed exactly where gcc is miscompiling the code? It'd be useful to know just as a warning for where to potentially look in the future, as the absolute most nightmarish of bugs are the ones caused by miscompilation.

[komisar]

I found only one problem before with profiling VFW-version of x264. After profiling in "common/common.c" in function "x264_log"

h->param.pf_log( h->param.p_log_private, i_level, psz_fmt, arg );

changed to

x264_log_default( h->param.p_log_private, i_level, psz_fmt, arg );

for correct profiling i use ugly hack: http://komisar.gin.by/x.patch/last.u...dummy-log.diff

P.S. This misunderstanding has helped find BugMaster.

[kemuri-_9]

no wonder, i tried compiling some stuff with gcc 4.4.0 and kept getting seg faults from the cpu id asm method when trying to run it.
definitely shouldn't use it right now, imo.

quarkfusion: I haven't been able to reproduce such lack of playback on any of those settings, granted i don't really have any video files of that resolution for that length.

[komisar]

This is a bug from gcc. I reproduce this bug on any source and settings... :-( I would dig deeper...

[Sharktooth]

then use a stable GCC version...

[komisar]

This is a matter of principle. I want to find the cause of the error. No matter where, gcc or x264...

[kemuri-_9]

with the huge list of regressions 4.4.0 has right now, i doubt you'll find it.

[Sharktooth]

komisar, then you need to start a new thread and discuss gcc 4.4 problems there since it's not a x264 problem...
also, your statement made ppl think it was a x264 problem while it was a gcc one... that means confusion...
you should provide those info to the GCC devs not the x264 devs.

[komisar]

Originally Posted by Sharktooth

komiisar, then you need to start a new thread and discuss gcc 4.4 problems there since it's not a x264 problem...
also, your statement made ppl think it was a x264 problem while it was a gcc one... that means confusion...
you should provide those info to the GCC devs not the x264 devs.

Why do you think that this problem can not be discussed here? Initially, the problem concerned the my x264 build. It is now clear that this is a compiler problem. Where described recommendations for the use of tools?
I believe that the correct spelling of code for different versions of compilers are also important.

Originally Posted by Dark Shikari

Ah. Have you pinpointed exactly where gcc is miscompiling the code? It'd be useful to know just as a warning for where to potentially look in the future, as the absolute most nightmarish of bugs are the ones caused by miscompilation.

[Sharktooth]

coz gcc 4.4 is still not released... it's beta or whatever you wanna call it so it's not a matter of "code spelling" but just a plain compiler bug and that has nothing in common with x264.

[kemuri-_9]

altered to to include kb/s like in r957 and fix rejections:
apply via
patch -p 1 -i x264_progress.indication_r957.diff
x264_progress.indication_r957.diff

[skystrife]

x264.957.modified.exe - Alternate Download

Patches used:

x264_psy_rdo_0.6_r956.diff <-- One line change from r953's patch to get rid of that oh-so-scary fuzz warning.
x264_new_bframe_decision_04.7.diff <-- Enable with --b-adapt 2. Random code removal fixed in this patch.
x264_hrd_pulldown.09_interlace.diff
x264_progress.indication_r957.diff <-- Thanks, kemuri.

gcc 3.4.5 fprofiled build.

[Ranguvar]

Thanks to kemuri for the fixed progress indication patch!

Home

Direct download, Mirrors

x264 r957 from Git (patched).
Compiled by Ranguvar on September 3rd, 2008, with GCC 4.3.2 on Windows XP Professional x64 SP2.
I have removed the non-AMD build, because the AMD build is of equal speed or faster than the non-AMD one 
in all of my tests so far - even on non-AMD hardware. Why? Who knows. But you don't need to worry about it.

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 them 
(NOT for AviDemux - get those 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 (included, unchanged, in the patches folder):

patch -p1 < ../x264diffs/x264_dll_alignment_fix.01.diff
patch     < ../x264diffs/x264_progress.indication_r957.diff
patch -p1 < ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p1 < ../x264diffs/x264_psy_rdo_0.6_r953.diff
patch -p1 < ../x264diffs/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

[techouse]

x264_x86_r957_techouse

Source: x264 r957 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):

x264_progress.indication_r957.diff

x264_psy_rdo.0.6_r957.diff

x264_hrd_pulldown.09_interlace.diff

x264_new_bframe_decision_04.7.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 3rd 2008, 09:39:49 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

P.S.: Love ya, kemuri

[burfadel]

Originally Posted by komisar

Why do you think that this problem can not be discussed here? Initially, the problem concerned the my x264 build. It is now clear that this is a compiler problem. Where described recommendations for the use of tools?
I believe that the correct spelling of code for different versions of compilers are also important.

Any luck with the 02 Sep release? Its good to test it at least, the 4.4.0 does make fast builds (encoding performance is fractionally better than any other GCC)

[komisar]

Originally Posted by burfadel

Any luck with the 02 Sep release? Its good to test it at least, the 4.4.0 does make fast builds (encoding performance is fractionally better than any other GCC)

I know... But on my system "02 Sep" svn release building with error. And I switch to gcc 4.3.2... When I make worked build of gcc 4.4 -- I continue my finding.

[TL0]

I am just wondering if the x264_fix_extended_zones.diff by VFR maniac is still needed or is the problem with using zone option he mentioned fixed?

diff --git a/common/common.h b/common/common.h
index ca555d1..4b18486 100644
--- a/common/common.h
+++ b/common/common.h
@@ -584,6 +584,12 @@ struct x264_t
 
     } stat;
 
+    struct
+    {
+        int b_interlaced_esa;
+        int b_interlaced_temporal;
+    } warn;
+
     /* CPU functions dependents */
     x264_predict_t      predict_16x16[4+3];
     x264_predict_t      predict_8x8c[4+3];
diff --git a/encoder/encoder.c b/encoder/encoder.c
index ad7151c..42c16fb 100644
--- a/encoder/encoder.c
+++ b/encoder/encoder.c
@@ -328,7 +328,7 @@ static void x264_bitstream_check_buffer( x264_t *h )
  *
  ****************************************************************************/
 
-static int x264_validate_parameters( x264_t *h )
+static int x264_validate_parameters( x264_t *h, int b_zone )
 {
 #ifdef HAVE_MMX
     if( !(x264_cpu_detect() & X264_CPU_MMXEXT) )
@@ -363,7 +363,8 @@ static int x264_validate_parameters( x264_t *h )
     if( h->param.i_threads > 1 )
     {
 #ifndef HAVE_PTHREAD
-        x264_log( h, X264_LOG_WARNING, "not compiled with pthread support!\n");
+        if ( !b_zone )
+            x264_log( h, X264_LOG_WARNING, "not compiled with pthread support!\n");
         h->param.i_threads = 1;
 #else
         if( h->param.i_scenecut_threshold >= 0 )
@@ -375,12 +376,20 @@ static int x264_validate_parameters( x264_t *h )
     {
         if( h->param.analyse.i_me_method >= X264_ME_ESA )
         {
-            x264_log( h, X264_LOG_WARNING, "interlace + me=esa is not implemented\n" );
+            if ( !h->warn.b_interlaced_esa )
+            {
+                x264_log( h, X264_LOG_WARNING, "interlace + me=esa is not implemented\n" );
+                h->warn.b_interlaced_esa = 1;
+            }
             h->param.analyse.i_me_method = X264_ME_UMH;
         }
         if( h->param.analyse.i_direct_mv_pred > X264_DIRECT_PRED_SPATIAL )
         {
-            x264_log( h, X264_LOG_WARNING, "interlace + direct=temporal is not implemented\n" );
+            if ( !h->warn.b_interlaced_temporal )
+            {
+                x264_log( h, X264_LOG_WARNING, "interlace + direct=temporal is not implemented\n" );
+                h->warn.b_interlaced_temporal = 1;
+            }
             h->param.analyse.i_direct_mv_pred = X264_DIRECT_PRED_SPATIAL;
         }
     }
@@ -424,7 +433,7 @@ static int x264_validate_parameters( x264_t *h )
     h->param.rc.i_qp_min = x264_clip3( h->param.rc.i_qp_min, 0, h->param.rc.i_qp_max );
 
     if( ( h->param.i_width % 16 || h->param.i_height % 16 )
-        && h->param.i_height != 1080 && !h->mb.b_lossless )
+        && h->param.i_height != 1080 && !h->mb.b_lossless && !b_zone )
     {
         // There's nothing special about 1080 in that the warning still applies to it,
         // but chances are the user can't help it if his content is already 1080p,
@@ -491,7 +500,7 @@ static int x264_validate_parameters( x264_t *h )
     if( h->param.rc.f_aq_strength <= 0 )
         h->param.rc.i_aq_mode = 0;
     /* VAQ effectively replaces qcomp, so qcomp is raised towards 1 to compensate. */
-    if( h->param.rc.i_aq_mode == X264_AQ_GLOBAL )
+    if( h->param.rc.i_aq_mode == X264_AQ_GLOBAL && !b_zone )
         h->param.rc.f_qcompress = x264_clip3f(h->param.rc.f_qcompress + h->param.rc.f_aq_strength / 0.7, 0, 1);
     h->param.analyse.i_noise_reduction = x264_clip3( h->param.analyse.i_noise_reduction, 0, 1<<16 );
 
@@ -604,7 +613,7 @@ x264_t *x264_encoder_open   ( x264_param_t *param )
     /* Create a copy of param */
     memcpy( &h->param, param, sizeof( x264_param_t ) );
 
-    if( x264_validate_parameters( h ) < 0 )
+    if( x264_validate_parameters( h, 0 ) < 0 )
     {
         x264_free( h );
         return NULL;
@@ -798,6 +807,10 @@ int x264_encoder_reconfig( x264_t *h, x264_param_t *param )
     COPY( analyse.b_dct_decimate );
     COPY( analyse.b_fast_pskip );
     COPY( analyse.b_mixed_references );
+    // COPY( rc.f_ip_factor );
+    // COPY( rc.f_pb_factor );
+    COPY( rc.i_aq_mode );
+    COPY( rc.f_aq_strength );
     // can only twiddle these if they were enabled to begin with:
     if( h->pps->b_transform_8x8_mode )
         COPY( analyse.b_transform_8x8 );
@@ -807,7 +820,7 @@ int x264_encoder_reconfig( x264_t *h, x264_param_t *param )
 
     mbcmp_init( h );
 
-    return x264_validate_parameters( h );
+    return x264_validate_parameters( h, 1 );
 }
 
 /* internal usage */
diff --git a/encoder/ratecontrol.c b/encoder/ratecontrol.c
index 1d41200..c0a61fb 100644
--- a/encoder/ratecontrol.c
+++ b/encoder/ratecontrol.c
@@ -569,7 +569,8 @@ int x264_ratecontrol_new( x264_t *h )
 static int parse_zone( x264_t *h, x264_zone_t *z, char *p )
 {
     int len = 0;
-    char *tok, *saveptr;
+    int i, j = 0;
+    char *tok, *buff;
     z->param = NULL;
     z->f_bitrate_factor = 1;
     if( 3 <= sscanf(p, "%u,%u,q=%u%n", &z->i_start, &z->i_end, &z->i_qp, &len) )
@@ -586,11 +587,32 @@ static int parse_zone( x264_t *h, x264_zone_t *z, char *p )
     p += len;
     if( !*p )
         return 0;
+
+    /* Parse some options. */
+    if( p[0] != ',' )
+        return -1;
+    else
+        buff = ++p;
     z->param = malloc( sizeof(x264_param_t) );
     memcpy( z->param, &h->param, sizeof(x264_param_t) );
-    while( (tok = strtok_r( p, ",", &saveptr )) )
+    while( *buff )
     {
-        char *val = strchr( tok, '=' );
+        char *val;
+        tok = x264_malloc( strlen(buff)+1 );
+        memset( tok, 0, sizeof(tok) );
+        for( i = 0; p[j] != ',' && *buff; i++ )
+        {
+            tok[i] = p[j++];
+            buff++;
+        }
+        if ( !*tok )
+        {
+            x264_free( tok );
+            return -1;
+        }
+        tok[i] = '\0';
+        j++;
+        val = strchr( tok, '=' );
         if( val )
         {
             *val = '\0';
@@ -599,9 +621,10 @@ static int parse_zone( x264_t *h, x264_zone_t *z, char *p )
         if( x264_param_parse( z->param, tok, val ) )
         {
             x264_log( h, X264_LOG_ERROR, "invalid zone param: %s = %s\n", tok, val );
+            x264_free( tok );
             return -1;
         }
-        p = NULL;
+        x264_free( tok );
     }
     return 0;
 }

http://www.esnips.com/web/VFRmaniac-Softwares

[komisar]

Problem with --no-cabac in profiling gcc 4.4.0 solved (Thnx BugMaster). GCC 4.4.0 wrong inline function bs_write_vlc in cavlc.c. I change this with define:

#define bs_write_vlc(a,b) bs_write(a, b.i_size, b.i_bits)
/*static inline void bs_write_vlc( bs_t *s, vlc_t v )
{
    bs_write( s, v.i_size, v.i_bits );
}*/

and all OK now.
Comparing gcc profiling:

x264.gcc433.pf.exe --crf 26 --no-cabac --trellis 2 --ref 4 --bframes 3 --subme 6 --me umh --threads 1 --thread-input
encoded 20 frames, 6.96 fps, 4719.71 kb/s

x264.gcc440.pf.exe --crf 26 --no-cabac --trellis 2 --ref 4 --bframes 3 --subme 6 --me umh --threads 1 --thread-input
encoded 20 frames, 10.49 fps, 4719.71 kb/s