[feature request] native frame-at-timestamp export (no external ffmpeg dependency for downstream tools)

まず crates/export にある既存の cap export 実装を読み、ネイティブデコーダーのパスと現在の --format および --resolution の処理を確認します。cap project validate とその JSON 出力を確認し、duration-query オプションを評価します。メンテナーと合意したコマンド形式と、外部の ffmpeg 依存なしでフレーム抽出および/または duration 報告を行う、テスト済みのネイティブパスがあれば完了です。

Problem

cap export already renders a full video natively, but there's no way to pull
a single still frame at a given timestamp (or read a segment's exact duration)
without shelling out to a separately-installed ffmpeg/ffprobe. Any tool
built on top of Cap that needs still frames — thumbnailing, a step-by-step
doc generator, a diffing/QA tool — ends up carrying that whole external
dependency itself, with all its fragility: PATH lookup, version drift,
platform-specific installs, and (what actually happened to us) a Homebrew
library-version mismatch silently breaking frame extraction with no clear
error.

Concrete case

cap-tools (a Python CLI built on Cap) has a capt guide command that
extracts a screenshot per detected click from a .cap recording's
display.mp4. It shelled out to ffmpeg -ss <t> -i display.mp4 -vframes 1
per click and ffprobe for segment duration. On 2026-07-31, a routine
brew upgrade on a dev machine left the installed ffmpeg linked against a
now-missing libSvtAv1Enc.3.dylib, and every call silently produced zero
frames — the tool's own error handling didn't even catch it as an ffmpeg
problem, since subprocess.run still spawns the process, it just exits
non-zero. The realistic fix for us was vendoring
PyAV (FFmpeg statically compiled into the Python
wheel) to remove the external dependency entirely — but that's real
duplicated effort (and duplicated FFmpeg-linking risk) that every Cap-based
tool has to solve independently, when Cap's own CLI already has a native,
often hardware-accelerated decode path (cap export --force-ffmpeg-decoder
exists specifically as an opt-out of the platform decoder, implying the
default path isn't shelling out to system ffmpeg at all).

Proposal

Add a way to pull one or more still frames — and/or just a duration query —
through the same native pipeline cap export already uses, so no consumer
of Cap recordings needs its own vendored or system video toolchain just to
get a thumbnail.

cap export <project.cap> --frames-at 3.5,7.2,12.0 --out-dir frames/ --json
cap project duration <project.cap> --json   # or fold into `project validate`'s existing output

• Frame output could reuse --format's existing container knowledge (jpg/png)
  and --resolution for downscaling — same flags as cap export already has.
• Duration is probably the cheaper win alone: cap project validate already
  reads the project; adding a durationSeconds field to its JSON output would
  let tools drop ffprobe even without full frame-export support.

Why now

Cap's CLI surface is clearly meant to be the foundation other tools build on
(cap agents install, the MCP server, the whole "designed to be driven by
automation and AI agents" framing in cap --help). Every downstream tool
that wants a still frame currently has to solve the exact fragility we just
hit, independently, on their own.

Status

No PR yet — wanted to check appetite and naming/shape preference first.
Happy to prototype against crates/export if this is a direction you'd take
a contribution on.