Hi Folks- The Precise 2.5 render looks very good on my editing monitor, and outstanding on the 83" S95 in the living room - so this recovery attempt is a must-do. I was able to put Windows Update on hold until July 10th.
I’m sharing how I’m recovering a long Precise 2.5 render that died partway through — posting the approach for scrutiny before I commit another multi-day render, because my first plan had a flaw I only caught after looking at the actual keyframe data.
The situation: ~33 minutes of finished Precise 2.5 output before the forced Windows reboot killed the render. The recovery option didn’t resume (Topaz support just confirmed diffusion models can’t reliably resume mid-render). Rather than redo everything, I’m salvaging the partial and splitting the job into two.
Step 1 — find where the good content ends. Mapped the partial render’s keyframes:
ffprobe -v error -select_streams v:0 -skip_frame nokey -show_entries frame=pts_time -of csv=print_section=0 “partial.mp4” > keyframes.txt
The decode threw an “Invalid NAL unit size” error right after the last keyframe (1982.32s) — that’s the interrupted write. So the render’s last clean keyframe is 1982.32.
Step 2 — Here’s where my first plan broke down. I’d intended to splice at a scene-change keyframe present in both the render and the source. Then I mapped the source’s keyframes and found the problem: the source (an Aion/Rhea 60fps export) has a rigid, fixed GOP — a keyframe every 2.0167s, dead regular, with zero scene-change keyframes anywhere in the whole 116-minute file. So I don’t have a scene-cut keyframe to align to. The two files also don’t share a keyframe grid at all — render is ~0.5s GOP with scene cuts, source is ~2.0167s GOP with no scene cuts.
Step 3 — what actually works given those limitations. Stream-copy trimming can only cut at each file’s own keyframes, so:
Segment 2’s source can only start cleanly at a source keyframe. Nearest one past the corruption is 1982.40s.
For the join to have no gap or overlap, segment 1 (the render) must end at the exact same timestamp: 1982.40.
But the render’s keyframes are at 1982.32 and ~1982.82 — neither is at 1982.40. A stream-copy -t 1982.40 on the render would actually stop at 1982.32, leaving an 83ms gap.
So segment 1 needs a frame-accurate re-encode to land exactly on 1982.40, while segment 2’s source gets a clean stream copy:
Segment 1 — re-encode to hit the exact frame (negligible quality loss at qp16, minutes on my 5070ti)
ffmpeg -i “partial.mp4” -t 1982.400000 -c:v hevc_nvenc -preset p7 -rc constqp -qp 16 “segment1.mkv”
Segment 2 source — stream copy, lands exactly on a source keyframe
ffmpeg -ss 1982.400000 -i “source.mkv” -c copy “source_segment2.mkv”
source_segment2.mkv then goes back through Precise 2.5 as its own job. When it’s done, I concatenate segment 1 + segment 2.
What I’m still uncertain about:
The splice point (1982.40) is not a verified scene change — the source simply doesn’t have any. So the join’s seamlessness depends entirely on Precise 2.5’s ‘temporal’ consistency at that frame between two separate render sessions. I’ll eyeball it frame-by-frame in mpv after.
Diffusion “warm-up” at the very start of segment 2 is a possible artifact I haven’t tested. If the first few frames of segment 2 look off, I may need to start its render a bit earlier and trim the rendered output back.
If anyone’s spliced diffusion-model output across separate render sessions and hit (or avoided) consistency drift / warm-up artifacts at the join, I’d genuinely like to hear it before I burn the render.
Lessons for me are already locked in (from experience and advice here): pre-split the source into ~30-min chunks up front — and split on a real scene cut if your source encoder produced any.
Lose a chunk, not the whole thing.
Thanks,
TheFNGee
