26.02.2021, 22:15
Two times in a row I try to encode a film, and around 50% hybrid crashes. I don't understand why 
https://dropmefiles.com/MK6GV
https://dropmefiles.com/MK6GV
26.02.2021, 22:29
Doesn't look like the decoder, but like the encoder just crashes,...
To be use run:
inside a Windows Command Prompt. This should show if the decoder has any issues about around frame 115147. (Decoding on it's own should be fairly fast.)
The encoder part:
looks fine to me.
RAM usage should be high either so that should not cause an issue.
My guess is that either:
a. the decoder has an issue with the decoding and sends some really strange output to x264 which make it crash
or
b. the encoder has some problem
or
c. there is some hardware or temperature issue.
or
d. some other tool anti virus or similar is for some reason is interfering with the encoding.
I assume your system isn't overclocked. Also do you know by any change whether it always crashes at the same position?
Cu Selur
To be use run:
Code:
"C:\Program Files\Hybrid\64bit\ffmpeg.exe" -noautorotate -nostdin -threads 8 -i "E:\TheHiddenBlade\source.mkv" -map 0:0 -an -sn -vf crop=1916:1036:2:22 -pix_fmt yuv420p -vsync 0 -f rawvideo NULThe encoder part:
Code:
"C:\Program Files\Hybrid\64bit\x264.exe" --preset slower --crf 18.80 --profile high --level 4.1 --ref 4 --bframes 16 --sync-lookahead 24 --qcomp 0.65 --no-mbtree --ipratio 1.3 --pbratio 1.2 --qpmax 51 --no-fast-pskip --merange 32 --subme 11 --aq-mode 3 --aq-strength 0.65 --vbv-maxrate 62500 --vbv-bufsize 78125 --sar 1:1 --deblock -3:-3 --non-deterministic --range pc --colorprim bt709 --transfer bt709 --colormatrix bt709 --demuxer raw --input-res 1916x1036 --input-csp i420 --input-range tv --input-depth 8 --fps 24000/1001 --output-depth 8 --output "E:\TheHiddenBlade\2021-02-26@17_40_27_2010_01.264" -RAM usage should be high either so that should not cause an issue.
My guess is that either:
a. the decoder has an issue with the decoding and sends some really strange output to x264 which make it crash
or
b. the encoder has some problem
or
c. there is some hardware or temperature issue.
or
d. some other tool anti virus or similar is for some reason is interfering with the encoding.
I assume your system isn't overclocked. Also do you know by any change whether it always crashes at the same position?
Cu Selur
26.02.2021, 22:55
I have ryzen 1700x, it's OCed to 3700 at 1.35V. It's very minor OC with plenty of voltage, tested long time ago. Temps are always the same under full load (far from anything dangerous), so this shouldn't be an issue.
I encode regularly, very rarely such crashes happen. It did happen a couple of times before, I had to encode 3 times, only the 3rd encode went all the way.
The first time I didn't had Debug output switched on, so I can't confirm if the frame is the same.
Anyway, will try this for the 3rd encode - switch off Windows Defender, and new Debug to see if the frame is the same.
I encode regularly, very rarely such crashes happen. It did happen a couple of times before, I had to encode 3 times, only the 3rd encode went all the way.
The first time I didn't had Debug output switched on, so I can't confirm if the frame is the same.
Anyway, will try this for the 3rd encode - switch off Windows Defender, and new Debug to see if the frame is the same.
26.02.2021, 23:03
Like I wrote you can check whether the decoding has an issue by using the command line I provided which should be relatively fast since it's only the decoding.
Random crashes are usually caused by a problem with the decoder, something interfering or some hardware issue.
Crashes that always happen at the same point are usually either a problem with the source or running out of memory.
If you just use Windows Defender that should not cause any problems assuming you told it to exclude the input, temp and output folders.
Cu Selur
Random crashes are usually caused by a problem with the decoder, something interfering or some hardware issue.
Crashes that always happen at the same point are usually either a problem with the source or running out of memory.
If you just use Windows Defender that should not cause any problems assuming you told it to exclude the input, temp and output folders.
Quote:I encode regularly, very rarely such crashes happen. It did happen a couple of times before, I had to encode 3 times, only the 3rd encode went all the way.That sound like an hardware (memory, cpu, temperature) issue.
Cu Selur
27.02.2021, 06:17
So, 3rd encode went fine all the way.
I changed two things:
1) Switched off Defender (but I don't think it was the issue anyway)
2) In x264 options I used Threads=16 instead of 0 (auto mode)
Using 16 instead of auto I noticed the load on cpu is probably lower by 1-2% on average, which is nothing.
I changed two things:
1) Switched off Defender (but I don't think it was the issue anyway)
2) In x264 options I used Threads=16 instead of 0 (auto mode)
Using 16 instead of auto I noticed the load on cpu is probably lower by 1-2% on average, which is nothing.
27.02.2021, 08:48
Okay, that sounds like an hardware/temperature/overclocking issue.
Cu Selur
Cu Selur