View Full Version : Resume x264 encode after power loss?
chipzoller
19th May 2009, 21:47
I was doing an x264 encode with MeGUI on an older laptop that I don't use and recently exclusively as an encoder. I had a CRF encode going for about a day and a half (with 5 hours left) when I decided to unplug the laptop to read an article on the go, and unexpectedly 10 minutes later it shutdown. Is there any way that I can resume an encoding session like this?
LoRd_MuldeR
19th May 2009, 21:51
Since you were using CRF, you should be able to start a new encode on the missing part, later you can join the parts together.
chipzoller
19th May 2009, 21:53
How would I go about doing that? Check the so far completed file to see what the last frame it encoded, then limit the AVS script to include whatever's left? I was thinking something along the lines of auto-resume, but I didn't think this existed. It would be a really nice feature if it did, however.
LoRd_MuldeR
19th May 2009, 21:55
How would I go about doing that? Check the so far completed file to see what the last frame it encoded, then limit the AVS script to include whatever's left?
That's how I'd do it, yes.
I was thinking something along the lines of auto-resume, but I didn't think this existed. It would be a really nice feature if it did, however.
This feature doesn't exist.
chipzoller
19th May 2009, 22:00
Thanks, I'll give this a shot.
chipzoller
20th May 2009, 00:58
From the incomplete MKV I got, a few frames at the very end are unusable, so I needed to resume encoding those few frames back. Now I need to cut off those bad frames and append with the new file. What tool do I need to accomplish this?
I was thinking something along the lines of auto-resume, but I didn't think this existed. It would be a really nice feature if it did, however.I'll say... that would be a killer feature for one of the MPEG-4 GUIs. It would make über-long duration jobs feasible for more people.
LoRd_MuldeR
20th May 2009, 01:22
I'll say... that would be a killer feature for one of the MPEG-4 GUIs. It would make über-long duration jobs feasible for more people.
A GUI cannot support something that x264 doesn't offer. And resuming an aborted encode is not supported.
What a GUI can do is: Cut the video into several chunks, encode each one separately and then join all the chunks together. But this only works with CRF/CQ mode!
And for running "über-long" jobs, you can simply send your machine to hibernation and continue some other day. Any modern OS offers that feature...
ajp_anton
20th May 2009, 01:41
Split the incomplete video from the last keyframe and start a new encode from there.
chipzoller
20th May 2009, 01:54
Thanks for all the suggestions. I had a 2 or 3 frame back-track, but it's imperceptible where it occurs.
I would still love to see x264 support an auto-resume aborted encode for cases like this, but it's probably not that important to most.
As for über-long jobs and hibernation. This works mid-encode?
LoRd_MuldeR
20th May 2009, 02:14
I would still love to see x264 support an auto-resume aborted encode for cases like this, but it's probably not that important to most.
This isn't trivial to implement, I think.
x264 would need to save all its state to the HDD in regular intervals. And it would need to be able to restore its state from the last checkpoint.
Far too much work, if you get all that for free with hibernation...
As for über-long jobs and hibernation. This works mid-encode?
Sure.
chipzoller
20th May 2009, 02:20
This isn't trivial to implement, I think.
x264 would need to save all its state to the HDD in regular intervals. And it would need to be able to restore a saved state.
I won't start speculating since I know not of what I'd speak, but I will say that it would be a valuable feature.
As for über-long jobs and hibernation. This works mid-encode?
Sure.
I did not know this. Thanks.
And for running "über-long" jobs, you can simply send your machine to hibernation and continue some other day. Any modern OS offers that feature...You can hibernate, but you can't use the computer. The idea behind resumable encodes is to free up CPU and memory temporarily for other things. I'm sure a lot of us have been in that boat at one time or another.
Chengbin
20th May 2009, 04:03
Do a sig stop on x264, problem solved.
Dust Signs
20th May 2009, 06:10
When using Windows, you can also suspend x264.exe. Process Explorer p.e. can do that.
Dust Signs
True, but that doesn't release memory and you must keep the computer on or hibernated.
You can run x264 encode in a virtual machine with an os installed and turn on automatic 'snapshots' every 10 minutes. There's plenty of virtualization softwere out there.
Fr4nz
20th May 2009, 09:15
And for running "über-long" jobs, you can simply send your machine to hibernation and continue some other day. Any modern OS offers that feature...
IIRC I tried that some time ago: in the encoded video there was a "very little jump" in frames encoded just prior and after the hibernation.
Trahald
20th May 2009, 18:28
IIRC I tried that some time ago: in the encoded video there was a "very little jump" in frames encoded just prior and after the hibernation.
Ive done it a few times, I haven't noticed that phenomenon.
LoRd_MuldeR
20th May 2009, 20:21
You can hibernate, but you can't use the computer. The idea behind resumable encodes is to free up CPU and memory temporarily for other things. I'm sure a lot of us have been in that boat at one time or another.
You can run x264 at "low" or even "idle" priority and it won't take a way any CPU cyles from other apps. Also with ProcessExplorer you can pause/resume processes at any time.
Last but not least the memory occupied by x264 will be moved to the swap file, as soon as other applications require more memory and the RAM is full...
chipzoller
20th May 2009, 20:27
These suggestions and points are all well and good themselves, but they do nothing to address the problem of an UNEXPECTED termination of an encoding session, which was my initial query and then feature suggestion.
LoRd_MuldeR
20th May 2009, 20:30
These suggestions and points are all well and good themselves, but they do nothing to address the problem of an UNEXPECTED termination of an encoding session, which was my initial query and then feature suggestion.
Read this post:
http://forum.doom9.org/showpost.php?p=1287580&postcount=11
Also if you encounter random crashes, you'd better get your serious hardware problem fixed instead of thinking about software workarounds...
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.