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

[mopurist]

Hrd 15.

Sorry, maybe I misunderstand, but is this version supposed to fix the error described in post 2036?

I just recompiled x264 with this patch and I get the same failure. (Linux 64-bit, if it matters)

x264: encoder/set.c:644: x264_sei_picture_timing_write: Assertion `dpb_output_delay < pow( 2, sps->vui.nal_hrd_parameters.i_dpb_output_delay_length )' failed.

Thanks.

[Trahald]

whats your command line.

[imk]

x264-r1193M-imk-win.7z (http://imk.cx/pc/x264/x264-r1193M-imk-win.7z)
win_build_info.txt (http://imk.cx/pc/x264/win_build_info.txt)

[mopurist]

whats your command line.

When I run with the same options XhmikosR described, it does work. I hadn't updated x264 for several months, and now that I have, a script I used previously without issue dies with the assertion failed.

If I trim the command used by the script down as far as the following, the assertion still fails:
/usr/bin/wine /home/mopurist/.wine/drive_c/Program\ Files/avs2yuv.exe /home/mopurist/test.avs -raw - | x264 --bitrate 7000 --level 4.1 --nal-hrd --vbv-maxrate 50000 --vbv-bufsize 50000 --output test.264 - 1440x1080 --fps 29.970

The actual command the script uses is:
/usr/bin/wine "${avs2yuvdir}/avs2yuv.exe" "${workdir}/${1}.avs" -raw -| /usr/bin/x264 --b-adapt 2 --pass 1 --psy-rd 1.0:0.2 --aq-strength 1.3 --bitrate $2 --stats "${workdir}/${1}.stats" --level 4.1 --nal-hrd --ref 4 --mixed-refs --bframes 4 --b-pyramid --no-fast-pskip --weightb --me umh --direct auto --keyint 300 --min-keyint 30 --vbv-maxrate 62500 --vbv-bufsize 62500 --mvrange 511 --aud --subme 7 --trellis 2 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --threads auto --thread-input --deblock 0,1 --sar 4:3 --output "${twosixfourdir}/${1}_final.264" - 1440x1080 --fps 29.970

So, obviously I don't know what the assertion is testing, nor do I understand how it is determined or what the purpose of the change is, that now results in an assertion failed.

Any help in understanding and fixing the issue would be appreciated.

Thanks.

[ACoolie]

In a vanilla icc-compiled x264 r1193 build i get the following error around 300 frames into the second pass of an encode. CFLAGS and LDFLAGS are just "-openmp."
x264: encoder/analyse.c:1175: x264_mb_analyse_inter_p16x16: Assertion `a->l0.me16x16.mv[1] <= h->mb.mv_max_spel[1] || h->param.i_threads == 1' failed.
x264 -B 1264 -o 1.h264 -p2 --merange 24 --level 4.1 --fps 24000/1001 --sar 32/27 -b 12 -f -2,-2 --frames 52560 --psy-rd 1.3:0.15 --aq-strength 1.0 --aq-mode 2 --stats .stats - 708x348 --preset slower --no-fast-pskip --b-pyramid -m10
A gcc-compiled x264 works perfectly. If I set subme to 9 and use the icc build, it works as well.

[Dark Shikari]

.... I'm a complete idiot, it seems... adding more subme values and not increasing the size of the array... I'm shocked it worked at all.

Fix committed.

[Dark Shikari]

OK, now this is brilliant.

static const int subpel_iterations[][4] =
{{0,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,2,2},
{0,0,4,10},
{0,0,4,10}};

/* (x-1)%6 */
static const int mod6m1[8] = {5,0,1,2,3,4,5,0};

Accessing the array positions subpel_iterations[10][2] and subpel_iterations[10][3] gave "1,2", a reasonable enough hpel/qpel value, which resulted in me never noticing the problem.

Of course, on a compiler that didn't happen to arrange the data adjacently in memory...

[Trahald]

@mopurist
Hmm... i couldnt duplicate the issue, but i'll keep trying.

Except for wasting a few bits.. rev 13 of the patch is fine to use.

[techouse]

x264_x64_r1195_unpatched (http://techouse.project357.com/builds/revision1195/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1195/x264.md5)
GCC 4.4.0 20090524 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1195_techouse (http://techouse.project357.com/builds/x264_x86_r1195_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1195_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1195_techouse (http://techouse.project357.com/builds/x264_x64_r1195_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1195_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.15_interlace.diff
x264_win_zone_parse_fix_05.diff

[MythCreator]

x264_x86_r1195_MythCreator

Download (http://www.filefront.com/14148645/x264-r1195-patched.exe)

GCC 4.4.1 released (MythCreator build), fprofiled

Patches used:

x264_hrd_pulldown.15_interlace.diff
x264_win_zone_parse_fix_05.diff

[mopurist]

@mopurist
Hmm... i couldnt duplicate the issue, but i'll keep trying.

Except for wasting a few bits.. rev 13 of the patch is fine to use.

Thanks for taking a look.

Unfortunately, 13 doesn't apply cleanly to latest git (x264.c changes) and my work schedule will leave me only an hour or so each day to check it out.

I did notice that if I don't specify --fps (with version 15 of the patch) I don't get the assertion failure. But it assumes 25fps, which is incorrect, and seems to encode at about 1/4th the rate that I was previously getting with x264+hrd version 9 from several months ago.

[imk]

x264-r1195M-imk-win.7z (http://imk.cx/pc/x264/x264-r1195M-imk-win.7z)
win_build_info.txt (http://imk.cx/pc/x264/win_build_info.txt)

[Trahald]

@mopurist
http://forum.doom9.org/showthread.php?p=1306166#post1306166 <-the 13 in this post. it was modified by one of the other builders to patch post preset era x264.

[JEEB]

x264 r1195 64bit unpatched:
download (http://jeeb.fiveforty.jp/x264/revision1195/x264.exe) ; hash (http://jeeb.fiveforty.jp/x264/revision1195/x264.md5)

built on Jul 29 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, otherwise defaults

________________________________________________________________________________

x264 r1195 32bit
download (http://jeeb.fiveforty.jp/x264/1195/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1195/relnotes.txt)

built on Jul 29 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


x264 r1195 64bit
download (http://jeeb.fiveforty.jp/x264/1195_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1195_x64/relnotes.txt)

built on Jul 29 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.15_interlace.diff

[moviefan]

I'm using Techouse's build r1195 and I'm still getting the same error "This application has requested the Runtime to terminate in an unusual way. Please contact the application's support team for more information." using subme 10. Something is seriously wrong... The last working revision for me was r1187 (I think).

[Dark Shikari]

I'm using Techouse's build r1195 and I'm still getting the same error "This application has requested the Runtime to terminate in an unusual way. Please contact the application's support team for more information." using subme 10. Something is seriously wrong... The last working revision for me was r1187 (I think).I can't do anything without a gdb backtrace, sorry.

[moviefan]

Do I need to compile x264 for performing the backtrace with gdb? I have never done this before... Or is it too difficult do it right away for the first time?

[kemuri-_9]

x264 w/ debug symbols (http://kemuri9.net/dev/x264/x264_debug.exe)
you can use this with mingw's gdb and provide a backtrace upon the crash (if it does still crash)

[moviefan]

OK, what's this? ".../gdb/dwarf2read.c:985: gdb-internal-error: read_comp_unit_head: dwarf from non elf file" "An internal GDB error was detected. This may make further debugging unreliable."

[kemuri-_9]

A. if you aren't already, be sure to be using mingw gdb 6.8-3
B. if you are, then post a sample that you can consistently crash with and the command line you're using to cause the crash.

[Dark Shikari]

Do I need to compile x264 for performing the backtrace with gdb? I have never done this before... Or is it too difficult do it right away for the first time?gdb --args ./x264_debug_build --all --your --normal --options

...

<it crashes>

bt

[LoRd_MuldeR]

OK, what's this? ".../gdb/dwarf2read.c:985: gdb-internal-error: read_comp_unit_head: dwarf from non elf file" "An internal GDB error was detected. This may make further debugging unreliable."

Maybe a problem with "SJLJ" -vs- "Dwarf-2" Unwinding?

[moviefan]

A. is the problem. I used the current gdb version of DevCpp which is old. Do I have to run x264 in the gdb environment with my current x264 settings? So is this like a normal encode only under supervision of gdb?

[LoRd_MuldeR]

A. is the problem. I used the current gdb version of DevCpp which is old. Do I have to run x264 in the gdb environment with my current x264 settings? So is this like a normal encode only under supervision of gdb?

Do it like proposed here:
http://forum.doom9.org/showpost.php?p=1309773&postcount=2071

BTW: You may need to type "run" or "c" to make the program start/resume until it crashes...

[moviefan]

Do it like proposed here:
http://forum.doom9.org/showpost.php?p=1309773&postcount=2071

Sorry, parallel posting :rolleyes:

I'll report back when results have arrived.

Edit: Sorry, it's strange... Now gdb says, "gdb: unrecognized option --threads"
Edit2: Oh, @DarkShikari: --args was meant literally... now it works, but I get massive output in the console. Does it terminate and show the error, when there is an abnormal termination? kemuri-_9's debug build does not include the --nal-hrd patch, so the situation is not identical to my crash situation.
Edit3: I got to go to bed, exam tomorrow, but I'll post the results in about 8 hours. Encoding is slow, duplicating the encoding situation (1 fps...), but it'll probably have crashed by tomorrow morning (if it crashes).

[LoRd_MuldeR]

Edit2: Oh, @DarkShikari: --args was meant literally... now it works, but I get massive output in the console. Does it terminate and show the error, when there is an abnormal termination? kemuri-_9's debug build does not include the --nal-hrd patch, so the situation is not identical to my crash situation.

Yes, Avisynth spams the gdb console with debugging messages ;)

But if x264 crashes, gdb will interrupt, show an error message and return to the propmpt. Then you can type "bt" to get a stacktrace, so we see where exactly it crashed.

If that doesn't happen, the crash simply doesn't occur with kemuri's debug build.

Edit3: I got to go to bed, exam tomorrow, but I'll post the results in about 8 hours.

Good luck !!!

[moviefan]

x264 crashed.

"Program received signal SIGSEGV, Segmentation fault. [Switchting to thread 2268.0x20c] 0x6fb775f6 in libavcodec!dspuitl_init () from ...\DGAVCDec\libavcodec.dll"

Hm, it seems, that x264 is OK and DGAVCDec is the problem, right? Strange, since I had done encodes with exactly the same .dga-file and exactly this DGAVCDec version.

Good luck !!!
Thanks, I hope it'll be good. Stochastic processes...:cool:

[LoRd_MuldeR]

When the "Segmentation fault" happens, type bt to get a Stacktrace and post the result back here...

[moviefan]

Hm, I did type bt at that point, but it didn't reveal any new information. There were some thread messages (or whatever they are) and the message about libavcodec. What should have been written there? In case, I missed something, I will repeat the backtrace.

[Dark Shikari]

Hm, I did type bt at that point, but it didn't reveal any new information. There were some thread messages (or whatever they are) and the message about libavcodec. What should have been written there? In case, I missed something, I will repeat the backtrace.You were able to backtrace but you can't paste the results here so we can read them? :rolleyes:

[moviefan]

Ehm, basically... yes ;-). OK... I will redo the tracing. I closed the terminal this morning, but the information were as I mentioned. I started another encode with imk's build using DirectShowSource of the same source this morning and up to now there have not been any errors. Do you definitely expect more information than I posted, so that I missed something? In that case I do the tracing again.

Edit: Actually, the DirectShowSource encode failed too, but for other, unknown reasons... I've just started the backtrace again.
Edit: OK, an error occurred again. I now paste exactly what is shown in the terminal:
This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.
warning: Process detach: hModule = 0x10000000, gRefCnt = 2

Program exited with code 03.
(gdb) bt
No stack.

This message is different to the one from this morning. However, there is an error and I hope this helps with debugging.

Edit: The issue might have been caused by using SetMTMode(2) at the very beginning of the avs-script, especially before AVCSource/DirectShowSource. When I put it after source loading, the encodes seem to be stable. I have already encoded about 33000 frames and the crashes were always at a few 1000 frames.

[juGGaKNot]

I want to modify x264.c to make a custom profile

cmd now :

--profile high --preset placebo --tune animation --bitrate %btratex264% --stats %myx264stats% --level %mylevel% --fullrange on --no-fast-pskip --bframes 4 --psy-rd 1.0:00 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 20000 --vbv-maxrate 20000 --qcomp 1.0 --aq-mode 2 --aq-strength 1.0 --nal-hrd --sar 1:1 --aud --no-dct-decimate

cmd after

--profile high --preset juggaknot --bitrate %btratex264% --stats %myx264stats% --level %mylevel%

so i want to include all these settings

--fullrange on --no-fast-pskip --bframes 4 --psy-rd 1.0:00 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 20000 --vbv-maxrate 20000 --qcomp 1.0 --aq-mode 2 --aq-strength 1.0 --nal-hrd --sar 1:1 --aud --no-dct-decimate

in a preset, so far i got :

H0( " --preset Use a preset to select encoding settings [medium]\n" );
H0( " Overridden by user settings\n");
H1( " - ultrafast,veryfast,fast,medium\n"
" - slow,slower,placebo,juggaknot\n" );
else H0( " - ultrafast,veryfast,fast,medium,slow,slower,placebo\n" );

else if( !strcasecmp( optarg, "juggaknot" ) )
{
param->i_frame_reference > 1 ? param->i_frame_reference*2 : 1;
param->i_deblocking_filter_alphac0 = 1;
param->i_deblocking_filter_beta = 1;
param->analyse.f_psy_rd = 1.0;
param->rc.f_aq_strength = 1.0;
param->i_bframe = 4;
param->rc.f_qcompress = 1.0;

How can i add the rest of the cvars ? can i add all of them ?

[J_Darnley]

You can discover the variable names by looking at common/common.c and the function x264_param_parse then add them to your preset. You don't have to add your preset name to the help if it is for your use.

[LoRd_MuldeR]

juGGaKNot, try this:

else if( !strcasecmp( optarg, "juggaknot" ) )
{
param->analyse.i_me_method = X264_ME_TESA;
param->analyse.i_subpel_refine = 10;
param->analyse.i_me_range = 24;
param->i_frame_reference = 16;
param->i_bframe_adaptive = X264_B_ADAPT_TRELLIS;
param->analyse.i_direct_mv_pred = X264_DIRECT_PRED_AUTO;
param->analyse.inter |= X264_ANALYSE_PSUB8x8;
param->analyse.b_fast_pskip = 0; // --no-fast-pskip
param->analyse.i_trellis = 2;
param->i_bframe = 16; // --bframes 4
param->rc.f_qcompress = 1.0f // --qcomp 1.0
param->rc.i_vbv_max_bitrate = 20000; // --vbv-maxrate 20000
param->rc.i_vbv_buffer_size = 20000; // --vbv-bufsize 20000
param->rc.b_aud = 1; // --aud
param->b_dct_decimate = 0; // --no-dct-decimate
param->vui.b_fullrange = 1; // --fullrange on
param->analyse.f_psy_rd = 1.0f; // --psy-rd 1.0:00
param->analyse.f_psy_trellis = 0.0f; // --psy-rd 1.0:00
param->rc.i_aq_mode = X264_AQ_AUTOVARIANCE; // --aq-mode 2
param->rc.f_aq_strength = 1.0f; // --aq-strength 1.0
param->rc.f_ip_factor = 1.1f; // --ipratio 1.1
param->rc.f_pb_factor = 1.1f; // --pbratio 1.1
param->vui.i_sar_height = 1; //--sar 1:1
param->vui.i_sar_width = 1; //--sar 1:1
param->b_nal_hrd = 1; // --nal-hrd
}

Diff: http://pastie.org/568166

Note that some lines are superfluous, as they simply represent the default. But I included them anyway, just for completeness ;)

[juGGaKNot]

You can discover the variable names by looking at common/common.c and the function x264_param_parse then add them to your preset. You don't have to add your preset name to the help if it is for your use.

thnx, it is for use in my exe thingy.

juGGaKNot, try this:

thnx.

LE

error on the diff

***************
*** 593,598 ****
param->analyse.i_trellis = 2;
param->i_bframe = 16;
}
else
{
fprintf( stderr, "x264 [error]: invalid preset: %s\n", optarg );
--- 593,626 ----
param->analyse.i_trellis = 2;
param->i_bframe = 16;
}
+ else if( !strcasecmp( optarg, "juggaknot" ) )
+ {
+ param->analyse.i_me_method = X264_ME_TESA;
+ param->analyse.i_subpel_refine = 10;
+ param->analyse.i_me_range = 24;
+ param->i_frame_reference = 16;
+ param->i_bframe_adaptive = X264_B_ADAPT_TRELLIS;
+ param->analyse.i_direct_mv_pred = X264_DIRECT_PRED_AUTO;
+ param->analyse.inter |= X264_ANALYSE_PSUB8x8;
+ param->analyse.b_fast_pskip = 0; // --no-fast-pskip
+ param->analyse.i_trellis = 2;
+ param->i_bframe = 16; // --bframes 4
+ param->rc.f_qcompress = 1.0f // --qcomp 1.0
+ param->rc.i_vbv_max_bitrate = 20000; // --vbv-maxrate 20000
+ param->rc.i_vbv_buffer_size = 20000; // --vbv-bufsize 20000
+ param->rc.b_aud = 1; // --aud
+ param->b_dct_decimate = 0; // --no-dct-decimate
+ param->vui.b_fullrange = 1; // --fullrange on
+ param->analyse.f_psy_rd = 1.0f; // --psy-rd 1.0:00
+ param->analyse.f_psy_trellis = 0.0f; // --psy-rd 1.0:00
+ param->rc.i_aq_mode = X264_AQ_AUTOVARIANCE; // --aq-mode 2
+ param->rc.f_aq_strength = 1.0f; // --aq-strength 1.0
+ param->rc.f_ip_factor = 1.1f; // --ipratio 1.1
+ param->rc.f_pb_factor = 1.1f; // --pbratio 1.1
+ param->vui.i_sar_height = 1; //--sar 1:1
+ param->vui.i_sar_width = 1; //--sar 1:1
+ param->b_nal_hrd = 1; // --nal-hrd
+ }
else
{
fprintf( stderr, "x264 [error]: invalid preset: %s\n", optarg );

$ patch -p1 < /d/jugg.diff
patching file x264.c
Hunk #1 FAILED at 593.
1 out of 1 hunk FAILED -- saving rejects to file x264.c.rej

LE :

if i copy the code in x264.c ( replace placebo with juggaknot )

i get errors on aud

[jpsdr]

Hello.

I'm totaly new in h264.
I've try to encode videos in h264, and import
them in scenarist. After faillure and research,
it seems that standard x264 built lack some "4-slice"
support in produced stream to be BD compliant, at
least in scenarist (v4.3.0) aspect.
I've found that maybe it exist some patched version
wich add these "slice".
I hope i'm in the right place to ask this.
If these versions exist, where can i find them,
and what specific command line option do i have
to add in MeGUI ?

Thanks.

[nurbs]

You can try to compile x264 with this patch (http://mailman.videolan.org/pipermail/x264-devel/2009-August/006106.html) and then add the appropriate custom command line options in megui.

[juGGaKNot]

param->analyse.i_me_method = X264_ME_TESA;
param->analyse.i_subpel_refine = 10;
param->analyse.i_me_range = 32;
param->i_frame_reference = 16;
param->i_bframe_adaptive = X264_B_ADAPT_TRELLIS;
param->analyse.i_direct_mv_pred = X264_DIRECT_PRED_AUTO;
param->analyse.inter |= X264_ANALYSE_PSUB8x8;
param->analyse.b_fast_pskip = 0;
param->analyse.i_trellis = 2;
param->i_bframe = 4;
param->rc.f_qcompress = 1.0f;
param->rc.i_vbv_max_bitrate = 20000;
param->rc.i_vbv_buffer_size = 20000;
param->vui.b_fullrange = 1;
param->analyse.f_psy_rd = 1.0f;
param->analyse.f_psy_trellis = 0.0f;
param->rc.i_aq_mode = X264_AQ_AUTOVARIANCE;
param->rc.f_aq_strength = 1.0f;
param->rc.f_ip_factor = 1.1f;
param->rc.f_pb_factor = 1.1f;
param->vui.i_sar_height = 1;
param->vui.i_sar_width = 1;
param->i_deblocking_filter_alphac0 = 1;
param->i_deblocking_filter_beta = 1;
param->analyse.b_dct_decimate = 0;
param->rc.b_aud = 1; does not work.

[moviefan]

Referring to jpsdr's post, is slicing actually needed to be BD compliant? And are there disadvantages using the multislice-patch?

[Dark Shikari]

Referring to jpsdr's post, is slicing actually needed to be BD compliant? And are there disadvantages using the multislice-patch?Slightly lower compression (a few %).

Technically, BD does require slicing, but I have yet to receive a report of a player not taking an unsliced stream.

Some authoring software checks it anyways though.

[moviefan]

OK, if the patch is used, is x264 in its current development stage capable of 100% BD compliance (official requirements)? (speaking of encoding 1080p material, using Level 4.1 and the correct settings to be within BD specs)

[Dark Shikari]

OK, if the patch is used, is x264 in its current development stage capable of 100% BD compliance (official requirements)? (speaking of encoding 1080p material, using Level 4.1 and the correct settings to be within BD specs)Maybe. We don't really know; the spec is secret.

[juGGaKNot]

param->rc.b_aud = 1; does not work.

x264.c: In function 'Parse':
x264.c:610: error: 'struct <anonymous>' has no member named 'b_aud'
make[1]: *** [x264.o] Error 1
make[1]: Leaving directory `/d/x264'
make: *** [fprofiled] Error 2

Administrator@LastXP15 /d/x264
$

What is the right param ?

[LoRd_MuldeR]

What is the right param ?

Try this ;)

param->b_aud = 1;

[juGGaKNot]

LOL, i tried it and it did not work, now it does.

thnx

anyway a download link for x264_win_zone_parse_fix_05.diff ?

[LoRd_MuldeR]

Let me google that for you:
http://lmgtfy.com/?q=x264_win_zone_parse_fix_05+filetype%3Adiff

[juGGaKNot]

filetype:xxx, good tip

i get one error

hrd also got errors, 13 modified, 14 and 15 :

$ patch -p1 < /d/x264_win_zone_parse_fix_05.diff
patching file encoder/ratecontrol.c
Hunk #1 FAILED at 638.
Hunk #2 FAILED at 649.
2 out of 2 hunks FAILED -- saving rejects to file encoder/ratecontrol.c.rej

$ patch -p1 < /d/x264_hrd_pulldown.13_interlace.diff
patching file common/bs.h
Hunk #1 FAILED at 169.
1 out of 1 hunk FAILED -- saving rejects to file common/bs.h.rej
patching file common/common.c
Hunk #1 FAILED at 141.
Hunk #2 FAILED at 370.
Hunk #3 FAILED at 585.
3 out of 3 hunks FAILED -- saving rejects to file common/common.c.rej
patching file common/common.h
Hunk #1 FAILED at 279.
1 out of 1 hunk FAILED -- saving rejects to file common/common.h.rej
patching file common/frame.c
Hunk #1 FAILED at 109.
1 out of 1 hunk FAILED -- saving rejects to file common/frame.c.rej
patching file common/frame.h
Hunk #1 FAILED at 34.
1 out of 1 hunk FAILED -- saving rejects to file common/frame.h.rej
patching file common/set.h
Hunk #1 FAILED at 125.
1 out of 1 hunk FAILED -- saving rejects to file common/set.h.rej
patching file encoder/encoder.c
Hunk #1 FAILED at 383.
Hunk #2 FAILED at 702.
Hunk #3 FAILED at 908.
Hunk #4 FAILED at 1309.
Hunk #5 FAILED at 1358.
Hunk #6 FAILED at 1368.
Hunk #7 FAILED at 1390.
Hunk #8 FAILED at 1514.
Hunk #9 FAILED at 1547.
Hunk #10 FAILED at 1608.
Hunk #11 FAILED at 1699.
Hunk #12 FAILED at 1749.
Hunk #13 FAILED at 1763.
13 out of 13 hunks FAILED -- saving rejects to file encoder/encoder.c.rej
patching file encoder/ratecontrol.c
Hunk #1 FAILED at 70.
Hunk #2 FAILED at 91.
Hunk #3 FAILED at 143.
Hunk #4 FAILED at 287.
Hunk #5 FAILED at 1088.
Hunk #6 FAILED at 1170.
Hunk #7 FAILED at 1292.
Hunk #8 FAILED at 1305.
8 out of 8 hunks FAILED -- saving rejects to file encoder/ratecontrol.c.rej
patching file encoder/ratecontrol.h
Hunk #1 FAILED at 34.
1 out of 1 hunk FAILED -- saving rejects to file encoder/ratecontrol.h.rej
patching file encoder/set.c
Hunk #1 FAILED at 208.
Hunk #2 FAILED at 391.
Hunk #3 FAILED at 580.
3 out of 3 hunks FAILED -- saving rejects to file encoder/set.c.rej
patching file encoder/set.h
Hunk #1 FAILED at 29.
1 out of 1 hunk FAILED -- saving rejects to file encoder/set.h.rej
patching file x264.c
Hunk #1 FAILED at 196.
Hunk #2 FAILED at 354.
Hunk #3 FAILED at 399.
Hunk #4 FAILED at 467.
Hunk #5 FAILED at 1107.
5 out of 5 hunks FAILED -- saving rejects to file x264.c.rej
patching file x264.h
Hunk #1 FAILED at 201.
Hunk #2 FAILED at 267.
Hunk #3 FAILED at 293.
3 out of 3 hunks FAILED -- saving rejects to file x264.h.rej

$ patch -p1 < /d/x264_hrd_pulldown.14_interlace.diff
patching file common/bs.h
Hunk #1 FAILED at 169.
1 out of 1 hunk FAILED -- saving rejects to file common/bs.h.rej
patching file common/common.c
Hunk #1 FAILED at 145.
Hunk #2 FAILED at 374.
Hunk #3 FAILED at 589.
3 out of 3 hunks FAILED -- saving rejects to file common/common.c.rej
patching file common/common.h
Hunk #1 FAILED at 288.
1 out of 1 hunk FAILED -- saving rejects to file common/common.h.rej
patching file common/frame.c
Hunk #1 FAILED at 109.
1 out of 1 hunk FAILED -- saving rejects to file common/frame.c.rej
patching file common/frame.h
Hunk #1 FAILED at 34.
1 out of 1 hunk FAILED -- saving rejects to file common/frame.h.rej
patching file common/set.h
Hunk #1 FAILED at 125.
1 out of 1 hunk FAILED -- saving rejects to file common/set.h.rej
patching file encoder/encoder.c
Hunk #1 FAILED at 403.
Hunk #2 FAILED at 725.
Hunk #3 FAILED at 931.
Hunk #4 FAILED at 940.
Hunk #5 FAILED at 1386.
Hunk #6 FAILED at 1396.
Hunk #7 FAILED at 1418.
Hunk #8 FAILED at 1571.
Hunk #9 FAILED at 1633.
Hunk #10 FAILED at 1729.
Hunk #11 FAILED at 1779.
Hunk #12 FAILED at 1793.
12 out of 12 hunks FAILED -- saving rejects to file encoder/encoder.c.rej
patching file encoder/ratecontrol.c
Hunk #1 FAILED at 68.
Hunk #2 FAILED at 89.
Hunk #3 FAILED at 140.
Hunk #4 FAILED at 286.
Hunk #5 FAILED at 1089.
Hunk #6 FAILED at 1171.
Hunk #7 FAILED at 1293.
Hunk #8 FAILED at 1305.
8 out of 8 hunks FAILED -- saving rejects to file encoder/ratecontrol.c.rej
patching file encoder/ratecontrol.h
Hunk #1 FAILED at 34.
1 out of 1 hunk FAILED -- saving rejects to file encoder/ratecontrol.h.rej
patching file encoder/set.c
Hunk #1 FAILED at 208.
Hunk #2 FAILED at 383.
Hunk #3 FAILED at 572.
3 out of 3 hunks FAILED -- saving rejects to file encoder/set.c.rej
patching file encoder/set.h
Hunk #1 FAILED at 29.
1 out of 1 hunk FAILED -- saving rejects to file encoder/set.h.rej
patching file x264.c
Hunk #1 FAILED at 196.
Hunk #2 FAILED at 354.
Hunk #3 FAILED at 399.
Hunk #4 FAILED at 467.
4 out of 4 hunks FAILED -- saving rejects to file x264.c.rej
patching file x264.h
Hunk #1 FAILED at 200.
Hunk #2 FAILED at 266.
Hunk #3 FAILED at 292.
3 out of 3 hunks FAILED -- saving rejects to file x264.h.rej

$ patch -p1 < /d/x264_hrd_pulldown.15_interlace.diff
patching file common/bs.h
Hunk #1 FAILED at 169.
1 out of 1 hunk FAILED -- saving rejects to file common/bs.h.rej
patching file common/common.c
Hunk #1 FAILED at 145.
Hunk #2 FAILED at 374.
Hunk #3 FAILED at 589.
3 out of 3 hunks FAILED -- saving rejects to file common/common.c.rej
patching file common/common.h
Hunk #1 FAILED at 288.
1 out of 1 hunk FAILED -- saving rejects to file common/common.h.rej
patching file common/frame.c
Hunk #1 FAILED at 109.
1 out of 1 hunk FAILED -- saving rejects to file common/frame.c.rej
patching file common/frame.h
Hunk #1 FAILED at 34.
1 out of 1 hunk FAILED -- saving rejects to file common/frame.h.rej
patching file common/set.h
Hunk #1 FAILED at 125.
1 out of 1 hunk FAILED -- saving rejects to file common/set.h.rej
patching file encoder/encoder.c
Hunk #1 FAILED at 403.
Hunk #2 FAILED at 725.
Hunk #3 FAILED at 931.
Hunk #4 FAILED at 940.
Hunk #5 FAILED at 1386.
Hunk #6 FAILED at 1396.
Hunk #7 FAILED at 1418.
Hunk #8 FAILED at 1571.
Hunk #9 FAILED at 1633.
Hunk #10 FAILED at 1729.
Hunk #11 FAILED at 1779.
Hunk #12 FAILED at 1793.
12 out of 12 hunks FAILED -- saving rejects to file encoder/encoder.c.rej
patching file encoder/ratecontrol.c
Hunk #1 FAILED at 68.
Hunk #2 FAILED at 89.
Hunk #3 FAILED at 140.
Hunk #4 FAILED at 286.
Hunk #5 FAILED at 1089.
Hunk #6 FAILED at 1171.
Hunk #7 FAILED at 1293.
Hunk #8 FAILED at 1305.
8 out of 8 hunks FAILED -- saving rejects to file encoder/ratecontrol.c.rej
patching file encoder/ratecontrol.h
Hunk #1 FAILED at 34.
1 out of 1 hunk FAILED -- saving rejects to file encoder/ratecontrol.h.rej
patching file encoder/set.c
Hunk #1 FAILED at 208.
Hunk #2 FAILED at 384.
Hunk #3 FAILED at 573.
3 out of 3 hunks FAILED -- saving rejects to file encoder/set.c.rej
patching file encoder/set.h
Hunk #1 FAILED at 29.
1 out of 1 hunk FAILED -- saving rejects to file encoder/set.h.rej
patching file x264.c
Hunk #1 FAILED at 196.
Hunk #2 FAILED at 354.
Hunk #3 FAILED at 399.
Hunk #4 FAILED at 467.
4 out of 4 hunks FAILED -- saving rejects to file x264.c.rej
patching file x264.h
Hunk #1 FAILED at 200.
Hunk #2 FAILED at 266.
Hunk #3 FAILED at 292.
3 out of 3 hunks FAILED -- saving rejects to file x264.h.rej

[kemuri-_9]

i get one error
hrd also got errors, 13 modified, 14 and 15 :

i've usually gotten a patch to completely reject when the git repo settings have it in windows text mode (CR/LF) instead of linux (LF only)

check the settings for the git program you're using.

[juGGaKNot]

Using windows xp.

$ git config --global core.autocrlf true

$ patch -p1 < /d/win.diff
patching file encoder/ratecontrol.c
Hunk #1 FAILED at 638.
Hunk #2 FAILED at 649.
2 out of 2 hunks FAILED -- saving rejects to file encoder/ratecontrol.c.rej

$ git config --global core.autocrlf input

$ patch -p1 < /d/win.diff
patching file encoder/ratecontrol.c
Hunk #1 FAILED at 638.
Hunk #2 FAILED at 649.
2 out of 2 hunks FAILED -- saving rejects to file encoder/ratecontrol.c.rej

$ git config --global core.autocrlf false

$ patch -p1 < /d/win.diff
patching file encoder/ratecontrol.c
Hunk #1 FAILED at 638.
Hunk #2 FAILED at 649.
2 out of 2 hunks FAILED -- saving rejects to file encoder/ratecontrol.c.rej

[Trahald]

When you installed git it asks what type of line endings you want, IIRC it defaults to windows (CR/LF) when installed on windows. You should select linux(LF) . When it happened to me, I just reinstalled GIT and changed the setting. I assume there is another quicker way to do it, but i didnt bother looking.

My own question... When i diff, the vcproj/sln files always end up in there. A few times Ive googled til i get tired of googling a way (well.. a simple way) to avoid that, but never can find one. i usually do git diff -ignore-space-at-eol > blah.diff . (the ignore arg ive found keeps the diff file from quoting the entire vcproj file but a header still shows up. ) you can see that at the beginning of my diffs