fix(web): record browser previews as H.264 MP4 so mobile can play them

[jakeleventhal]

What Changed

ScreenRecording_09-02-2026.14-17-18_1.MP4

Reordered preferredMimeTypes in apps/web/src/browser/browserRecording.ts so MediaRecorder tries H.264 MP4 (avc1.640028, then avc1.42e01e) before the WebM codecs. AV1, VP9, VP8, and plain WebM stay in the list as fallbacks in their original order.

Updated the recorder test that asserted AV1 won to assert H.264 MP4 wins when both are supported, and added a test for the WebM fallback when the browser has no MP4 encoder.

Why

Browser preview recordings came out as WebM/AV1. iOS cannot decode that, so the mobile app showed "Video unavailable" for recordings that played fine on web and desktop. Recordings are shared across every client, so the encoder should target the format all of them can play.

The desktop artifact path already maps MP4 MIME types to a .mp4 extension, so nothing downstream needed to change.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (no UI change)
• I included a video for animation/interaction changes (n/a)

Written by Claude Fable 5.1 via Claude Code.

🤖 Generated with Claude Code

---

Note

Low Risk
Narrow change to MediaRecorder MIME preference and tests; no auth, persistence, or API surface changes.

Overview
Browser preview recordings will use H.264 MP4 when the browser supports it, instead of defaulting to WebM/AV1. The preferredMimeTypes order in browserRecording.ts now tries avc1 MP4 profiles first, with WebM codecs kept as fallbacks.

Tests were updated to assert MP4 wins when both MP4 and WebM are available, and a new case covers WebM-only browsers still recording with VP9.

^{Reviewed by Cursor Bugbot for commit 19ad17a. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

[!NOTE]

Prefer H.264 MP4 for browser recordings to support mobile playback

• Updates the preferredMimeTypes list in browserRecording.ts to try H.264 MP4 before AV1 and VP9 WebM, keeping WebM as a fallback
• Adds tests to verify H.264 MP4 selection and WebM fallback behavior
• Behavioral Change: Browsers supporting both formats will now record previews as H.264 MP4 instead of WebM

^{Macroscope summarized 19ad17a.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes the default browser-recording format for browsers supporting both H.264 MP4 and WebM, affecting the artifacts shared across clients. The implementation is narrow and preserves fallbacks, but product-default changes require human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[juliusmarminge]

have you tested the file size implications here at all?

[jakeleventhal]

have you tested the file size implications here at all?

Forgot to publish initially, but yes:

Requested	Actual	Bytes	MiB	vs AV1
video/mp4;codecs=avc1.640028	video/mp4;codecs=avc1.64001f	5,719,073	5.45	2.81×
video/mp4;codecs=avc1.42e01e	video/mp4;codecs=avc1.42001f	6,356,736	6.06	3.13×
video/webm;codecs=av1	video/webm;codecs=av01	2,032,687	1.94	1.00×
video/webm;codecs=vp9	video/webm;codecs=vp9	4,981,808	4.75	2.45×
video/webm;codecs=vp8	video/webm;codecs=vp8	4,878,740	4.65	2.40×
video/webm	video/webm;codecs=vp8	5,011,933	4.78	2.47×

Definitely a hit... but how else to get it working on iPhone app?
results.json

video_mp4_codecs_avc1_42e01e.mp4

video_mp4_codecs_avc1_640028.mp4

video_webm_codecs_av1.webm
video_webm_codecs_vp8.webm
video_webm_codecs_vp9.webm
video_webm.webm

[juliusmarminge]

Superseded by #10403, which landed the H.264-first preferredMimeTypes preference (plus bitrate scaling and releasing capture before save) on main. Closing this PR as superseded — please reopen if anything unique remains.

[juliusmarminge]

Closed as superseded by #10403.