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

[Dark Shikari]

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]

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 tox264_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.used/k.vfw.01.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]

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.
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 (http://kemuri9.net/dev/x264/patches/x264_progress.indication_r957.diff)

[skystrife]

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

Patches used:

x264_psy_rdo_0.6_r956.diff (http://skystrife.com/x264/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 (http://sites.google.com/site/ranguvar13/x264-builds)

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

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 (http://techouse.project357.com/builds/x264_x86_r957_techouse.7z)
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]

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]

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

[DarkZell666]

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

... you mean the improvement is that big ? 50% faster ? o_O

[Ranguvar]

Those stats aren't very useful, no offense komisar. 20 frames only? No comparison to non-fprofiled stable?

[komisar]

Ranguvar
Indeed, not quite correctly. I make new tests...

[komisar]

Speed test gcc 346 vs gcc433 vs gcc440...

Source: avis [info]: 640x480 @ 60.00 fps (600 frames)

I make new tests.... This is not x264 speed test but gcc...

http://komisar.gin.by/test/gcc_speed_test.png

we all know gcc 4.3 produces slower x264 binaries than 3.4...
I do not know, but now I know more...

[Sharktooth]

compare to gcc 3.4... we all know gcc 4.3 produces slower x264 binaries than 3.4...

[komisar]

I have no gcc 3.4... But ok, I grab 3.4...
You may grab x264 binary from here: http://komisar.gin.by/test/

[gigah72]

here're some builds to play with, regardin speed, etc.
http://www.mediafire.com/?wgcgdjd9gem


patches
--------
x264_hrd_pulldown.09_interlace.diff
x264_new_bframe_decision_04.7.diff
x264_progress.indication_r957.diff
x264_psy_rdo_0.6_r956.diff
-----
builds
-------
x264_957_g345_c1_athlon.exe
x264_957_g345_c1_axp.exe
x264_957_g345_c1_k8.exe
x264_957_g345_c1_p2.exe
x264_957_g345_c2_athlon.exe
x264_957_g345_c2_axp.exe
x264_957_g345_c2_k8.exe
x264_957_g345_c2_p2.exe
x264_957_g345_x2_athlon.exe
x264_957_g345_x2_axp.exe
x264_957_g345_x2_k8.exe
x264_957_g345_x2_p2.exe
x264_957_g432_c1_athlon.exe
x264_957_g432_c1_axp.exe
x264_957_g432_c1_k8.exe
x264_957_g432_c1_p2.exe
x264_957_g432_x2_athlon.exe
x264_957_g432_x2_axp.exe
x264_957_g432_x2_k8.exe
-------
c1=CoreDuo 2300
c1=Core2Duo 4300
x2= AMD Athlon64 X2 5200+
all are build in same msys w2k/vmware on the above pc's

[Sharktooth]

... again with CPU optimizations ... x264 do not require them. the heavy stuff is coded in asm and already optimized...

[gigah72]

don't want it, don't try it. it's only for who's interested.

[Sharktooth]

just stop it and search before posting (follow the forum rules!). this has been already done... several times. so stop posting for just increasing your post count (again, follow the forum rules) and stop your aggressive behaviour (again, follow the forum rules) or you will get apples for apples...
so it appears you violated 3 forum rules in 15 minutes...

[Ranguvar]

I agree with gigah... don't want it, don't try it.

Seeing as how -march=athlon is noticeably faster than -march=pentium2 on AMD CPUs, for little reason apparently, despite Sharktooth's logic, anything that could potentially lead to another slight gain for a specific CPU is worthwhile. When you encode at brutally insane settings, every % counts.

[Sharktooth]

that's not the point... the point is it's not necessary to test that since it has been already done (last time it was a week ago or so... just look at the previous pages of this thread...). also he didnt post the cflags used, if the builds are fprofiled or not... etc... a well configured and generic build may be faster than or equal in speed to his cpu optimized builds...
however there are already conclusions about CPU optimizations with x264 (just look some pages back). if every user comes here posting 19 (!!! FYI building on different HW doesnt produce different binaries...) different builds will only add confusion for the ppl looking for the correct information and will spawn idiots that do not use the search function, that will test those builds adding tons of posts (most of the time they dont even know how to correctly benchmark too...) creating even more confusion...
i wish to remember you this thread is about patches... not discussion about or test of compiler optimizations.

[Audionut]

just stop it and search before posting (follow the forum rules!). this has been already done... several times. so stop posting for just increasing your post count (again, follow the forum rules) and stop your aggressive behaviour (again, follow the forum rules) or you will get apples for apples...
so it appears you violated 3 forum rules in 15 minutes...


Really!! It's only you who is aggressive. Your opinion, whether true or not, is not the be all and end all. As soon as someone posts something, that you do not agree with, it is you who flies of the rail.

[Sharktooth]

read my previous post (reply to ranguvar)... i was not referring to my opinion but to the conclusions that were drawn some pages back in this same thread.

[Audionut]

Just ignore it. He simply posted some different builds to play with. He didn't claim they were best or any other claims. Just a simple post.

BTW, People looking for correct information should read the stickies.

Perhaps your sticky could be edited, to make it more clear, to those of us that don't browse these forums every day, and know better, that those builds, are considered stable.
Any other builds are considered beta.

Honestly, while you and I and most others here will know better, it will help stop,
different builds will only add confusion for the ppl looking for the correct information and will find idiots that dont use the search function that will test those builds adding tons of posts

It just seems to me, that your pushing shit up hill. There are idiots everywhere. Always have been, always will be.

[Sharktooth]

i already state (in the sticky) the the vanilla git builds are the more stable than the patched builds (coz they include experimental patches...)

[Ranguvar]

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

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

x264 r964 from Git (patched, fprofiled).
Compiled by Ranguvar on September 5rd, 2008, with GCC 4.3.2.
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 -i ../x264diffs/x264_dll_alignment_fix.01.diff
patch -p1 -i ../x264diffs/x264_progress.indication_r957.diff
patch -p1 -i ../x264diffs/x264_hrd_pulldown.09_interlace.diff
patch -p1 -i ../x264diffs/x264_psy_rdo_0.6_r956.diff
patch -p1 -i ../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

[skystrife]

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

Patches used:

x264_psy_rdo_0.6_r956.diff
x264_new_bframe_decision_04.7.diff
x264_hrd_pulldown.09_interlace.diff
x264_progress.indication_r957.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

(my previous builds have all included -march=pentium2 as well but apparently it's "in" to have builds with different -march's so I'll specify this. Also, lol @ the gcc 4 and gcc 3 builds posts being so close together.)

[gav1577]

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

Patches used:

x264_psy_rdo_0.6_r956.diff
x264_new_bframe_decision_04.7.diff
x264_hrd_pulldown.09_interlace.diff
x264_progress.indication_r957.diff

gcc 3.4.5 fprofiled build with -march=pentium2.

(my previous builds have all included -march=pentium2 as well but apparently it's "in" to have builds with different -march's so I'll specify this. Also, lol @ the gcc 4 and gcc 3 builds posts being so close together.)

Im having serious visual problems with this build can some one confirm /reproduce ?

--pass 1 --bitrate 4500 --stats "C:\Documents and Settings\me\Desktop\123.stats" --level 4.1 --keyint 24 --min-keyint 2 --bframes 3 --direct auto --subme 1 --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 "C:\Documents and Settings\me\Desktop\123.avs" --mvrange 511 --aud --nal-hrd --sar 1:1

--pass 2 --bitrate 4500 --stats "C:\Documents and Settings\me\Desktop\123.stats" --level 4.1 --keyint 24 --min-keyint 2 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 16500 --vbv-maxrate 16500 --qcomp 0.5 --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "C:\Documents and Settings\me\Desktop\123.mp4" "C:\Documents and Settings\me\Desktop\123.avs" --mvrange 511 --aud --nal-hrd --sar 1:1

megui profile HD AVCHD Source sample logs avs provided below Thanks
http://www.mediafire.com/?sharekey=36267983da746bb4d2db6fb9a8902bda

screen shot of output

http://img33.picoodle.com/data/img33/3/9/5/f_x264964Patcm_3697313.png (http://www.picoodle.com/view.php?img=/3/9/5/f_x264964Patcm_3697313.png&srv=img33)

[skystrife]

I just did a quick test (same settings, different source) and the output was fine. Downloading your source and avs now.

EDIT: With your source something definitely borked. I don't know what.

EDIT2: Both r964 builds are affected.

[gav1577]

I just did a quick test (same settings, different source) and the output was fine. Downloading your source and avs now.

Ok thanks BTW previous versions work fine with the source sample :)

[gav1577]

I just did a quick test (same settings, different source) and the output was fine. Downloading your source and avs now.

EDIT: With your source something definitely borked. I don't know what.

If thats the case how come previous builds work fine ? source is cut from original blu ray. Do you have the same problem with older builds?

[kemuri-_9]

DirectShowSource() <--- is the devil, don't use it.
use neuron2's DGAVCIndex

[skystrife]

DirectShowSource() <--- is the devil, don't use it.
use neuron2's DGAVCIndex

Well even then, if the avs is playing fine when I preview it in MPC it shouldn't be doing anything like this when I encode it, right?

(Also, in case my EDIT2 was missed, both Ranguvar and my builds are affected, so beware for bugs in both.)

[gav1577]

DirectShowSource() <--- is the devil, don't use it.
use neuron2's DGAVCIndex

same outcome from FFmpeg r14675 when muxed to mkv havent tried DGAVCIndex yet


Thanks for confirming skystrife

[skystrife]

Vanilla r964 build has the issue here for me, so this is most likely not related to the patching. What setting exactly is fuxing the output though is beyond me, I'm slowly removing every setting and not getting anywhere.

Any ideas?

[gav1577]

Vanilla r964 build has the issue here for me, so this is most likely not related to the patching. What setting exactly is fuxing the output though is beyond me, I'm slowly removing every setting and not getting anywhere.

Any ideas?

Same here i tried everything i could think of before i posted :confused:

[kemuri-_9]

well i tried working at it and in different players, the frames were definitely miscolored, so maybe one of the new updates had a regression where the chroma gets corrupted.

tried on something else and got similar massive corruption.

when reverting back to my r956 build, there were no problems.

[gigah72]

Im having serious visual problems with this build can some one confirm /reproduce ?

--pass 1 --bitrate 4500 --stats "C:\Documents and Settings\me\Desktop\123.stats" --level 4.1 --keyint 24 --min-keyint 2 --bframes 3 --direct auto --subme 1 --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 "C:\Documents and Settings\me\Desktop\123.avs" --mvrange 511 --aud --nal-hrd --sar 1:1

--pass 2 --bitrate 4500 --stats "C:\Documents and Settings\me\Desktop\123.stats" --level 4.1 --keyint 24 --min-keyint 2 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 16500 --vbv-maxrate 16500 --qcomp 0.5 --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "C:\Documents and Settings\me\Desktop\123.mp4" "C:\Documents and Settings\me\Desktop\123.avs" --mvrange 511 --aud --nal-hrd --sar 1:1

megui profile HD AVCHD Source sample logs avs provided below Thanks
http://www.mediafire.com/?sharekey=36267983da746bb4d2db6fb9a8902bda

screen shot of output

http://img33.picoodle.com/data/img33/3/9/5/f_x264964Patcm_3697313.png (http://www.picoodle.com/view.php?img=/3/9/5/f_x264964Patcm_3697313.png&srv=img33)




now with 964 i get the same nice green with my mpeg2source sample and crf settings??
957 works fine.

EDIT:
coreavc in mpc decodes the broken scene, powerdvd in mpc just skipps over the broken scene...
maybe this does say something to someone?

EDIT2:
964 broken: http://www.mediafire.com/?i9h3tshdlcs
957 ok: http://www.mediafire.com/?1llhbmrsjdy

[kemuri-_9]

i went through git revisions one by one starting from r958 to find which one caused the problem...

revision 963 caused the problem, meaning from r962 to r963, the problematic code occurs.