The MediaRecorder export fallback introduced in #797 always emits a
WebM container (most browsers don't expose an MP4 muxer through
MediaRecorder). WebM plays in Chrome / Firefox / VLC but not
natively in QuickTime or Safari, so users on browsers without
WebCodecs who picked the MP4 format end up with a file they can't
open in those players.
This adds an opt-in escape hatch in the export popover:
- When `isWebCodecsExportSupported()` is false AND the user picked
MP4, the popover surfaces a "Browser compatibility" section that
explains the situation and offers a "Transcode to H.264 MP4 on
the server" checkbox (defaulted to on, since the user did ask
for MP4).
- When the checkbox is on, the post-export flow wraps the produced
WebM buffer in a `File` and runs it through `convertVideoToH264`,
which already routes to the existing `/api/convert-video` ffmpeg
endpoint. The downloaded file is a real H.264 MP4.
- If the user opts out, the popover keeps the WebM extension and
mime type so the saved file matches its real container.
- If the server transcode fails, the export is preserved as WebM
and the user is notified via a toast.
A small "Transcoding to MP4 on server…" section is shown in the
popover between the export finishing and the download starting,
since that step can take a noticeable amount of time on large
clips.
The WebCodecs-capable code path is unchanged: the warning section
is only rendered when `!isWebCodecsExportSupported() && format ===
"mp4"`.
6f7dacb4d4