fix(render-farm): stop padding published exports and holding opening frames

[richiemcilroy]

Two render farm output fixes.

Opening frames held. With decoder readahead on, the readahead window filled the decoder's frame cache before the renderer's first request, the overflow cleared the frames it was about to ask for, and those requests fell back to frame 0. The first chunk of a clip then showed the recording's opening frame for a few seconds while the cursor and zoom kept moving. Workers now leave readahead off by default (CAP_DECODER_READAHEAD=0), which renders the same output on every run.

Zero-padded exports. Every non-final chunk was padded up to S3's 5 MiB minimum part size, so short exports split across many chunks were published mostly as zero bytes (a 9 s take came out at 47 MB for 2 MB of video). Each chunk now stashes its opening bytes in the farm bucket and uploads the rest as full-size parts. The coordinator joins the MP4 header and small stashes into valid parts and copies large stashes server side, so the published file is exactly ftyp + moov + mdat. Journals from the old part layout are aborted on restart rather than resumed.

Verification

• 25 exports of a 1 minute 1080p fixture: identical and correct every time, matching readahead off.
• The 9 s take re-rendered at 1.95 MB (was 47.3 MB). No zero runs of 64 KiB or more in any checked output, and total size equals stream bytes plus the moov.
• Decoded frames, timestamps and audio are bit-identical to the padded build. Output plays to the end in Chromium and WebKit.
• Fault injection matrix passes.
• Ready times unchanged within run-to-run variation, from 1 minute to 2 hour exports at 1080p and 4K.
• 145 render farm tests pass; each commit typechecks and passes on its own.

Confidence Score: 5/5

The PR appears safe to merge based on this re-review.

Summary

The PR removes padding from published MP4 exports by stitching chunk stashes into multipart uploads, and disables decoder readahead by default. Since the previous review, it has added failure tracking so a failed stash upload cannot be reported as a successful chunk, with a regression test for that case.

_{Reviews (9) · Last reviewed commit: "fix(render-farm): fail a chunk whose sta..."}

[richiemcilroy]

hey @greptileai, please re-review the PR

[richiemcilroy]

hey @greptileai, please re-review the PR

[richiemcilroy]

hey @greptileai, please re-review the PR

[richiemcilroy]

hey @greptileai, please re-review the PR

[richiemcilroy]

hey @greptileai, please re-review the PR

[superagent-security]

Superagent found 1 security concern(s).

[richiemcilroy]

hey @greptileai, please re-review the PR

[richiemcilroy]

hey @greptileai, please re-review the PR

[richiemcilroy]

hey @greptileai, please re-review the PR

[richiemcilroy]

hey @greptileai, please re-review the PR