Log in

View Full Version : Resume megui encode after crash?


DarkNeutron
29th January 2007, 20:19
I was on the second pass of a h264 encode when my computer crashed (WinXP BSOD).:(

Is there any way to hove megui (or x264) to pick up where it left off? I had 1 day 18 hours left from a 4 day encode and I would rather not start over if I can avoid it.

Let me know what other information you might need, as I am not sure what to include...:confused:

MrCommunistGen
31st January 2007, 01:06
Oh my... as far as I know you can't pick up right where you left off. If it cleared the queue and you had finished the first pass, you could pick up at the second pass. To do this just enqueue another 2-pass (keeping everything the same), then postpone the 1st pass, and tell it to start. It SHOULD use the .stats file generated the first time around to complete the second pass.
Though it isn't necessary, I'm curious what you could possibly be encoding that would take 4 days... maybe a quick update on the length of the file being encoded, your settings, and your computer's specs? This is just for my curiosity.

Good Luck
-mcg

DarkNeutron
31st January 2007, 12:54
I think the stats file did not take that long to generate, so I might just make a new one anyway.

lets see....

It is a HDTV rip at 1280x1080i resolution (16:9), 1:44:55 in length. I believe I was trying to encode it with the h264 HQ-Slowest profile @ 6500 kb/s.

It has nothing to do with my problem, but the audio was a 1.12 GB 5.1 DTS file. I have no idea why it was used. Even with ND-AAC maxed out at 320 kb/s, the encoded file was less than 250MB.

My computer has a Athlon64 3000+ and 2Gb of memory. Oh, and 820GB worth of hard drives. :D

spanky123
31st January 2007, 13:44
Why are you bothering encoding to x264 (at 6500kbps) ?

What's wrong with keeping the original as is ?

Although I've never done a 6500kbps x264 encode, that still sounds way too long.

What script you using ?
And you probably don't need to use HQ-Slowest. The quality difference between that and HQ-Slow is hardly noticable. Definetly not worth the hours (or days in your case) extra encoding time imo.

DarkNeutron
1st February 2007, 00:14
Why are you bothering encoding to x264 (at 6500kbps) ?

The original was 10GB. Re-encoding with that bit rate would cut the file size in half.

What script you using?
Do you mean AVIsynth script? Just what the AVS script creator put out:
# Set DAR in encoder to 37 : 20. The following line is for automatic signalling
global MeGUI_darx = 37
global MeGUI_dary = 20
DGDecode_mpeg2source("D:\DVDs\Sky_Captain\Sky_Captain_tctest.d2v")
tfm(order=0).tdecimate()
#crop
#resize
#denoise
And you probably don't need to use HQ-Slowest.
I was not sure if I needed to or not. Reading back over the profile descriptions, it was probably overkill. I used it to encode other videos, but the time was not a problem until now...

DarkNeutron
5th February 2007, 03:34
Okay, something is going on here.

I was re-encoding again and got the same crash screen:
IRQL_NOT_LESS_OR_EQUAL

Does x264 have a bug in it relating to large files?

I forgot to write down the 0x0... error code. I will have to do that next time.

SpAwN_gUy
5th February 2007, 11:02
maybe this is the problem: http://forum.doom9.org/showthread.php?t=114229

i had overheating problem when used HQ-Slowest ... (there are some pics in the end ;) )...

BTW... i think 1080i is more like 1600, not 1280(this one is 720p).. but maybe i'm wrong and 1080i <> 1080p ...

yeah,.. and.. i'm currently testing x264farm(it IS very buggy... i can not encode one source of mine.. but still... i had some good examples)...
the speed is like.. 4-5 times faster :) (depending on the complexity of AVS and speed of PCs)... with 3-5 PCs on the RUN ...

Sharktooth
5th February 2007, 14:42
IRQL_NOT_LESS_OR_EQUAL is indicating a kernel exception (hardware error), hence system instability coz software like x264 or megui cant make the kernel crash (they dont run at the appropriate level)...

DarkNeutron
6th February 2007, 22:35
Well, I finally got the file encoded.

Now get this: my computer is too slow to play it. Talk about irony..

Ah, well, I was looking for an excuse to get a new CPU anyway. NewEgg has a nice 3400+ for $56 or a 4000+ for $80...

Now I remember why I love computers. :p

rack04
6th February 2007, 23:37
Well, I finally got the file encoded.

Now get this: my computer is too slow to play it. Talk about irony..

Ah, well, I was looking for an excuse to get a new CPU anyway. NewEgg has a nice 3400+ for $56 or a 4000+ for $80...

Now I remember why I love computers. :p

What are you using to decode?

DarkNeutron
7th February 2007, 00:28
mplayer and Media Player Classic both display jerky video, and VideoLAN crashes at 9 seconds.

Zoom Player seems to work the best, as it only hesitates every so often.

check
7th February 2007, 01:12
look into coreavc, which is a lot cheaper than a new CPU :)

Ð.Sp!dér
7th February 2007, 01:26
"Resume megui encode after crash" ? HELL YEAAAH ??! I mean, duh ! If this could be possible, and fully working, bug-free, I could even kiss you !

Sharktooth
7th February 2007, 03:27
it's theoretically possible if the encoder finished to encode the whole frame. practically is a PITA...

spanky123
7th February 2007, 14:19
Yeah try CoreAVC

Plays h264 files a lot easier than ffdshow and most other h264 decoders. . . although I think ffdshow has a slightly better picture quality imo.

Some HD 1080p files playback jerky sometimes with ffdshow for me. Using CoreAVC, they play perfectly fine.

Ð.Sp!dér
7th February 2007, 23:20
This topic is about encoding not decoding.
It even says "Resume megui encode after crash?"...

You're waaay offtopic.