[patrickballard]

Closes #3415.

The MP4 exporter now sets the .mp4 extension on its output path before exporting, the same way the GIF exporter sets .gif, so the path it returns is the file it wrote. A path that already ends in .mp4, which every desktop export does, is unchanged.

cap export rec.cap ...	before	after
-o out.gif	reports out.gif, writes out.mp4	reports and writes out.mp4
-o out.webm	reports out.webm, writes out.mp4	reports and writes out.mp4
-o out	reports out, writes out.mp4	reports and writes out.mp4
-o out.mp4	out.mp4	out.mp4

Tests

• New crates/export/tests/mp4_output_path.rs, ignored like the other export integration tests (it needs ffmpeg and a wgpu adapter): it exports to export.gif, export.webm and export and checks the returned path is the .mp4 file written. Run locally (with a stand-in for the ffmpeg CLI that writes a 1-second test video), it passes, and fails without the change: it gets back export.gif.
• cargo test -p cap-export --lib: 47 passed. Clippy: nothing in the changed files. rustfmt clean.
• Checked end to end with a release build of the CLI: the cases above, plus --format gif and --format mov, which are unchanged.

Confidence Score: 5/5

The PR appears safe to merge; it makes the returned MP4 path match the file already being written.

Summary

MP4 exports now return the .mp4 path they actually write.

• MP4 exports return the path of the .mp4 file they write.

_{Reviews (1) · Last reviewed commit: "fix(export): return the .mp4 path an MP4..." · Reviewed by Greptile}

[vercel]

@patrickballard is attempting to deploy a commit to the Cap Software Inc Team on Vercel.

A member of the Team first needs to authorize it.