Morte66
6th October 2006, 09:16
I want to run some huge crf encodes from MPEG2, that will each take about three days. I also want to run some deeply unreliable networked software, that makes me reboot every day or so. So I was wondering about splitting the encode into chunks lasting a few hours, which means that whenever I want to reboot I can wait for the current chunk to end then reboot and restart my encoder queue. If I were doing two pass encoding with a target size, this would mess up my bitrate distribution. But I'm doing crf, the bitrate is adjusted to suit the material on the fly. So far as I can see, this ought to be OK.
I figure I'll prepare the D2V, sound and AVS as normal. Then I'll open up the AVS in VirtualDubMod to get the frame count and pick scene changes to split on. I'll make a series of AVS scripts with trim() statements covering the file, and encode them all. Finally I'll concatenate the video segments in mkvmerge and mux in the sound.
Does anybody see a problem with this that I've missed?
{edit p.s.} Do I especially need to split on scene changes? If I split every 20,000 frames or whatever, that'll put about 10 extra I-Frames into the x264 encode. I can't see that really being a problem, my crf encode just be will be a very tiny bit bigger.
I figure I'll prepare the D2V, sound and AVS as normal. Then I'll open up the AVS in VirtualDubMod to get the frame count and pick scene changes to split on. I'll make a series of AVS scripts with trim() statements covering the file, and encode them all. Finally I'll concatenate the video segments in mkvmerge and mux in the sound.
Does anybody see a problem with this that I've missed?
{edit p.s.} Do I especially need to split on scene changes? If I split every 20,000 frames or whatever, that'll put about 10 extra I-Frames into the x264 encode. I can't see that really being a problem, my crf encode just be will be a very tiny bit bigger.