X264 Cli keep crashing

[Sergejack]

I made some HW test, and adjustements (because my comp was overheating) so that any encoding process should be fine.

Still, the second pass of X264cli keep stopping.

bat file :

@echo off
copy output.mp4 output.mp4.bck
echo --- Première passe ---
x264 --no-psnr --qpstep 4 --pass 1 --qpmin 1 --qcomp 0.60 --bitrate 162 --keyint 1000 --min-keyint 250 --bframe 7 --b-pyramid --pbratio 1.30 --ref 31 --analyse all --8x8dct --weightb --progress --me "umh" --merange 16 -o NUL CPR03.avs
copy x264_2pass.log x264_2pass.log.bck
echo --- Seconde passe ---
x264 --no-psnr --qpstep 4 --pass 2 --qpmin 1 --qcomp 0.60 --bitrate 162 --keyint 1000 --min-keyint 250 --bframe 7 --b-pyramid --pbratio 1.30 --ref 31 --analyse all --8x8dct --weightb --progress --me "umh" --merange 16 -o output.mp4 CPR03.avs


result :

--- PremiÞre passe ---
avis [info]: 384x288 @ 23.98 fps (42753 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
x264 [info]: slice I:375 Avg QP:24.06 Avg size: 13542
x264 [info]: slice P:16300 Avg QP:26.96 Avg size: 1648
x264 [info]: slice B:26078 Avg QP:26.33 Avg size: 146
x264 [info]: slice I Avg I4x4:51.8% I8x8:24.6% I16x16:23.6%
x264 [info]: slice P Avg I4x4:2.0% I8x8:2.5% I16x16:3.3% P:32.2% P8x8:4.8%
PSKIP:55.2%
x264 [info]: slice B Avg I4x4:0.0% I8x8:0.1% I16x16:0.1% P:7.8% B:0.7% B8
x8:0.3% DIRECT:2.3% BSKIP:88.7%
x264 [info]: kb/s:160.4

encoded 42753 frames, 9.38 fps, 7660261.89 kb/s
1 fichier(s) copié(s).
--- Seconde passe ---
avis [info]: 384x288 @ 23.98 fps (42753 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
mp4 [info]: initial delay 2000000 (scale 23976023)
encoded frames: 12869/42753 (30.1%), 9.54 fps
G:\X264>


it keeps stopping at 30.1% (10MB)

[bill_baroud]

disk full ? :D

[bond]

things like overclocking are not good for video encoding, i assume some hardware problem is the reason for your problem

i assume that this for example f*ed up this initial delay 2000000 (scale 23976023)which should only be a delay of 2 with b-pyramid

in my tests with sharktooth's latest build (255a) it worked correctly

[Manao]

If it always happens at the same place, it's not overheating.

If you change your settings, i guess it doesn't crash anymore, am i wrong ? If so, i'm afraid it's a bug in x264.

On a sidenote :

> "--keyint 1000 --min-keyint 250"

Why the hell are you crippling the encoder in such a way ??? lower --min-keyint to 25 or less, and --keyint to 300 ( it will ease the seeking )

> --ref 31

Useless, the norm doesn't allow more than 16 ( and the encoder perhaps not more than 15, i don't remember exactly ), and anyway, over 5 it slows down the encoder uselessly.

> --merange 16

Do you have any good reason to do that ? 16 is pretty small, and it hurts quality.

[Sharktooth]

--merange 16 is default. This is not regarding motion vectors, but the number of iterations for motion extimation.

[Manao]

Then, my bad ( but damn this name is ill-chosen, though i can't think of anything as concise )

[Sergejack]

If it always happens at the same place, it's not overheating.

If you change your settings, i guess it doesn't crash anymore, am i wrong ? If so, i'm afraid it's a bug in x264.

On a sidenote :

> "--keyint 1000 --min-keyint 250"

Why the hell are you crippling the encoder in such a way ??? lower --min-keyint to 25 or less, and --keyint to 300 ( it will ease the seeking )


It's because of the very low bitrate; fast seeking would impact on file size (since redudancy detection would be made on a shorter range)


> --ref 31

Useless, the norm doesn't allow more than 16 ( and the encoder perhaps not more than 15, i don't remember exactly ), and anyway, over 5 it slows down the encoder uselessly.


I tough so, but I read that some people used more than 15, so I was just thinking about trying.


> --merange 16

Do you have any good reason to do that ? 16 is pretty small, and it hurts quality.

It has been answered, I tried with 32, then put it back to 16 cause deleting the line wasn't a good way to prepare further testing. :p

[Sergejack]

things like overclocking are not good for video encoding, i assume some hardware problem is the reason for your problem

i assume that this for example fucked up this initial delay 2000000 (scale 23976023)which should only be a delay of 2 with b-pyramid

in my tests with sharktooth's latest build (255a) it worked correctly

I underclocked my CPU and my GPU to keep my computer really cool (max 60C° when using those 'torture test'; avg : 53C°)

I otherwise made some working MP4 files from the same AVS, with a limited number of frames (1440~60sec;2880~120sec)

But for the full video, I tried different config, it was always the same result (30,1%).
What kind of HW prob could that be anyway ? I never got any problem with VFW or any other VFW encoder.

[Sergejack]

things like overclocking are not good for video encoding, i assume some hardware problem is the reason for your problem

i assume that this for example fucked up this initial delay 2000000 (scale 23976023)which should only be a delay of 2 with b-pyramid

in my tests with sharktooth's latest build (255a) it worked correctly

Is 7 b-frame allowed, or it's max 4 ?

[peteag]

I've always got this error:

avis [error]: unsupported input form
could not open input file 'D:\9.avs'

What does that mean?
Video is huffy-compressed avi -> avs
720x432

Please help!

[Manao]

Your avi needs to output YV12, so add at the end of the script : COnvertToYV12()

[Sergejack]

I made another test with --no-asm, the result was the same (it took longer tough :p)

[Manao]

Sergejack : when i said to try other settings, i was refering to quality impacting settings. Try for example to raise the bitrate, change the number of bframe ( or remove them ), change gop settings and so on...

For your min / max gop settings : x264 inserts keyframe where they help most, so min-keyint = 250 will hurt quality ( whatever the bitrate is ). Lower it to 25 or less ( ideally, it should be 1, but if 25 is default, it's for a reason, and i trust akupenguin there ).

[bob0r]

@Sergejack
1: did you try another source?
2: did you know 60 degrees is VERY hot (id say AMD 50 degrees MAX)
3: You should try remove 1 option each time, untill it stops crashing, if you find an option, try to encode only with that option.
4: if all fails try x264.exe from my website and see if that makes any difference. (or try that first :P)

Maybe you can pack up all your stuff you use to encode this video and put it online somewhere, so we can test it also.

[Manao]

60°C isn't that hot. Unstability usually begins around 70-75°C.

[bond]

ideally, it should be 1, but if 25 is default, it's for a reason, and i trust akupenguin there ).
i think that specifies the IDR interval, so i-frames can be used in a smaller interval too

[Sergejack]

I use up too 15 I-frame in min 250 frames; that makes a I-frame every 17 frames; sounds enough to me.

anyway, nobody answered : Is 7 b-frame allowed, or it's max 4 ?

[bond]

I use up too 15 I-frame in min 250 frames; that makes a I-frame every 17 frames; sounds enough to me.
every 17 frames an i-frame? thats far too much

anyway, nobody answered :
16 is the max b-frame number

[Sergejack]

every 17 frames an i-frame? thats far too much

No, every 17 frames could be a I-frame. (if I'm not mistaking)


16 is the max b-frame number

cool.
BTW : if a recerence B-frame counting as an I-frame ? (wich can be max to 15 perd IDR segment)

[bond]

No, every 17 frames could be a I-frame. (if I'm not mistaking)
ah you mean the min-interval? this means, if set to 17, every 17th frame can be an IDR-frame
but even every frame could be an i-frame (will hardly happen tough of course)

BTW : if a recerence B-frame counting as an I-frame ? (wich can be max to 15 perd IDR segment)
no, b-frames and i-frames are totally different things

[Sergejack]

Qucick note to mention I discovered X264CLI crashed when the output was an mp4 file.
It could have been fixed since then, tough.

[Ajaja2005]

I have the same problem: second pass stops at 61.3% without any errors, x264cli rev.270 (all builds - x264.nl, sharktooth's, my gcc 3.4.4 and msvc++ builds).
Source: anime, 592x320@23.98 fps (Coincidence? Maybe, the problem is 23.98 fps?).

start /b /wait /low x264.exe --no-psnr --progress --pass 1 --stats "x264_2.log" --bitrate 840 --bframe 2 --ref 5 --weightb --b-pyramid --analyse "all" --8x8dct --me "umh" --subme 6 -o NUL an2.avs
start /b /wait /low x264.exe --no-psnr --progress --pass 2 --stats "x264_2.log" --bitrate 840 --bframe 2 --ref 5 --weightb --b-pyramid --analyse "all" --8x8dct --me "umh" --subme 6 -o an2.mp4 an2.avs

[Ajaja2005]

Qucick note to mention I discovered X264CLI crashed when the output was an mp4 file.
It could have been fixed since then, tough.
Thanks, .264 output is OK :)

[bond]

what "initial delay" value do you get when you get the crash?

[Ajaja2005]

what "initial delay" value do you get when you get the crash?

mp4 [info]: initial delay 834166 (scale 10000000)

more accurate value of fps in the source= 23.97603
2/23.97603 = 0.0834166
So, initial delay was OK?

[bond]

hm i am not sure, but it might be that this initial delay value is what causes the problem
does this crash also happen when b-pyramid is disabled by b-frames are still enabled?

i am pretty sure its no coincidence that two ntsc framerate streams showed this problem, cause with pal you dont get these wierd delay numbers

i will point jeanlf to this

[Sergejack]

hm i am not sure, but it might be that this initial delay value is what causes the problem
does this crash also happen when b-pyramid is disabled by b-frames are still enabled?

i am pretty sure its no coincidence that two ntsc framerate streams showed this problem, cause with pal you dont get these wierd delay numbers

i will point jeanlf to this

I've always got those kind of delay.
But shouldn't those "2000000 (scale 23976023)" be read with a decimal separator ?
02.000000
23.976023

BTW : the same numbers shows up when I encode in a raw stream (wich don't break while encoding processing)

[bond]

I've always got those kind of delay.
But shouldn't those "2000000 (scale 23976023)" be read with a decimal separator ?
02.000000
23.976023no decimal isnt allowed for this

BTW : the same numbers shows up when I encode in a raw stream (wich don't break while encoding processing)
check it again, i am sure this is not the case

[Sergejack]

check it again, i am sure this is not the case

It was the case when I made the bug repport.
If you'r sure it wouldn't be the case any more, I'll tell you the next time I'm encoding a non trivial video.

BTW : 2000000 (scale 23976023) means 2 frames when the fps is 23.976023 so it's a normal value with b-pyramid. (If I was told right)

[bond]

the delay is only displayed when encoding to .mp4, its not displayed when encoding to raw

[bond]

All clear!
I found the reason of 6s-delay bug: DirectShowSource()+ffdshow+Xvid source. The bug appears even in *.avs. ah, good to know, i now splitted the discussion and moved it to the avs forum

But, crash problem with mp4 output did not dissapear :( i already made a bug report at gpac, lets wait for an answer

[bond]

Sergejack and Ajaja2005,
do you still have the avisynth scripts you fed x264 with, which shows that crashes?

[Ajaja2005]

Avs script was very simple (clip=DirectShowSource("...") & return clip).

[bond]

Avs script was very simple (clip=DirectShowSource("...") & return clip).thx!
what was the source?

[Ajaja2005]

Source was xvid in avi with ac3 sound on 2CD (I reencoded it to 1CD).

[bond]

Source was xvid in avi with ac3 sound on 2CD (I reencoded it to 1CD).dunno if you want to try again, but it seems that directshowsource is prolematic

you can also try avisource()

[Ajaja2005]

But, h264-output with DirectShowSource works fine. I can't test, source was deleted :(

[bond]

sharktooth posted a potential fix to this problem, would be great if the people who reported this problem could try it and see if it fixed the issue

more info here (http://forum.doom9.org/showthread.php?t=98680)