Yes, the v14 patch plus the following works fine for me on windows.<br>Only compiles correctly with gcc 4.x+ but then again, I don't think people should be using the older 3.4 anyway.<br><br>following:<br>diff --git a/encoder/slicetype.c b/encoder/slicetype.c<br>
index f795d4c..a2d62cd 100644<br>
--- a/encoder/slicetype.c<br>
+++ b/encoder/slicetype.c<br>
@@ -364,8 +364,8 @@ static int x264_slicetype_path_cost( x264_t *h,<br>
x264_mb_analysis_t *a, x264_fram<br>
/* Find the location of the next P-frame. */<br>
while( path[next_p] && path[next_p] != 'P' )<br>
next_p++;<br>
- /* Return if the path doesn't end on a P-frame. */<br>
- if( path[next_p] != 'P' )<br>
+ /* Return if the path doesn't end on a P-frame or reaches max length */<br>
+ if( path[next_p] != 'P' || next_p > MAX_LENGTH )<br>
return cost;<br>
<br>
/* Add the cost of the P-frame found above */<br>
@@ -422,7 +422,7 @@ static void x264_slicetype_path( x264_t *h,<br>
x264_mb_analysis_t *a, x264_frame_t<br>
<br>
static int x264_slicetype_path_search( x264_t *h, x264_mb_analysis_t<br>
*a, x264_frame_t **frames, int length, int bframes, int buffer )<br>
{<br>
- char best_paths[MAX_LENGTH][MAX_<div id=":1o" class="ii gt">LENGTH] = {"","P"};<br>
+ char best_paths[MAX_LENGTH+1][MAX_LENGTH] = {"","P"};<br>
int n;<br>
for( n = 2; n < length-1; n++ )<br>
x264_slicetype_path( h, a, frames, n, bframes, buffer, best_paths );</div><br><br><div class="gmail_quote">On Sun, May 10, 2009 at 10:02 AM, Mike Kazmier <span dir="ltr"><<a href="mailto:DaKaZ@zenbe.com">DaKaZ@zenbe.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Thu, Apr 16, 2009 at 11:35 AM "Steven Walters" <<a href="mailto:kemuri9@gmail.com">kemuri9@gmail.com</a>> wrote:<br>
>><br>
> > No, the v14 patch runs perfectly on linux.<br>
> ><br>
> > --DaKaZ<br>
> ><br>
><br>
> that made me suspicious so i compiled it in my gcc 4.3.3 (x64) and<br>
> without the fix it silently closes without tossing out a complaint<br>
> (but).<br>
> it took the previous mentioned fix to have<br>
><br>
> ./x264.exe --lookahead 10 --b-adapt 2 -b16 --crf 18 -o NUL<br>
> ../foreman_cif_352x288.yuv --me tesa -m9 --pass 1 --threads 4 -v 2><br>
> verbose.txt<br>
><br>
> result in<br>
><br>
> x264 [info]: slice I:2 Avg QP:18.33 size: 30960 PSNR Mean<br>
> Y:43.80 U:46.40 V:47.92 Avg:44.65 Global:44.28<br>
> x264 [info]: slice P:128 Avg QP:20.78 size: 6730 PSNR Mean<br>
> Y:40.60 U:43.92 V:46.01 Avg:41.61 Global:41.42<br>
> x264 [info]: slice B:170 Avg QP:23.92 size: 1915 PSNR Mean<br>
> Y:38.70 U:42.96 V:45.18 Avg:39.85 Global:39.69<br>
><br>
> which seems to be the proper consensus among properly working versions.<br>
><br>
> looks like i'll have to find/make an x86 version of mingw 4.3.3 and<br>
> confirm it works there and see if it's a failure of gcc 3.4.x...<br>
<br>
</div>Steven, all windows users: I really want to get this patch into the main GIT repository so that other work can begin on items like lookahead VBV and b-adapt 2 threading. Is the consensus that this patch (with Steven's) works properly? if so, I will incorporate the two ASAP and get them submitted for inclusion.<br>
<br>
--DaKaZ<br>
<div><div></div><div class="h5">_______________________________________________<br>
x264-devel mailing list<br>
<a href="mailto:x264-devel@videolan.org">x264-devel@videolan.org</a><br>
<a href="http://mailman.videolan.org/listinfo/x264-devel" target="_blank">http://mailman.videolan.org/listinfo/x264-devel</a><br>
</div></div></blockquote></div><br>