Sending Screen Recordings to Clients: The MP4 Settings That Just Work

The Demo Reel That Wouldn't Play

You recorded a 15-minute product walkthrough in QuickTime on Mac. Exported it. Sent the .mov to your client. They opened it on a Windows laptop. It played for 3 seconds, then froze. Audio kept going. Video stayed on the third frame.

This happens for predictable reasons. The default QuickTime screen recording uses HEVC video and AAC audio in a .mov container. Windows Media Player doesn't decode HEVC by default. The browser-based workarounds (uploading to Loom, Vimeo, YouTube Unlisted) are a different decision tree, not a fix for the file you already exported.

This post is about producing a single MP4 file that plays correctly on Mac, Windows, Linux, iOS, and Android, stays small enough to email or attach to Slack, and shows your screen text legibly. Our video compressor handles the encoding step. The decisions before encoding are what matter most.

The Universal MP4 Recipe

For client handoff of screen recordings, here are the settings that work everywhere in 2026:

Container: MP4 (NOT .mov)
Video codec: H.264 (NOT HEVC, NOT AV1)
Profile: High
Level: 4.0 or 4.1
Pixel format: yuv420p
Bitrate: 4-8 Mbps for 1080p screen recording
Audio codec: AAC-LC
Audio bitrate: 128 kbps mono (voice) or 192 kbps stereo (music + voice)
Audio sample rate: 48 kHz
movflags: +faststart

The +faststart flag is critical. It moves the file's metadata to the front, which lets browsers and email previews start playing before the entire file downloads. Without it, you get a 30-second wait before playback starts.

In FFmpeg, the recipe:

ffmpeg -i input.mov \
  -c:v libx264 -preset slow -crf 22 \
  -profile:v high -level 4.0 \
  -pix_fmt yuv420p \
  -c:a aac -b:a 128k -ac 1 \
  -movflags +faststart \
  output.mp4

CRF 22 is the production sweet spot for screen recordings. Lower (CRF 18) is overkill for screen content. Higher (CRF 28) starts producing visible compression around text edges.

Why HEVC and AV1 Are Wrong Here

HEVC and AV1 produce smaller files at the same quality. Why not use them?

For a client who might open the file on a 5-year-old Windows machine, in Outlook on a corporate laptop, on an iPad, or in iMessage on iPhone, you need H.264. The file size penalty is acceptable.

The exception: if your client confirms they're on macOS Ventura+ or Windows 11 with HEVC codecs installed, HEVC is fine. Don't assume. Send a 30-second sample first.

Bitrate vs CRF for Screen Content

Screen recordings have different bitrate needs than camera footage. Cameras capture continuous motion and noise. Screens have flat colors, hard edges, and long static moments. The encoder uses bits very differently.

For a 1080p screen recording at 30 fps:

For most product demo screen recordings, CRF 22 produces 3-5 Mbps output. A 15-minute video lands around 280-470 MB. Email-friendly with most providers.

For pure terminal recordings (asciinema-style), CRF 22 produces under 1 Mbps. Same 15 minutes is under 100 MB.

File Size Targets by Delivery Method

For "send via email" delivery: encode at CRF 26 first, check size. If still over the limit, drop to 720p (most screen content is fine at 720p) before encoding.

ffmpeg -i input.mov \
  -c:v libx264 -preset slow -crf 26 \
  -vf "scale=1280:-1" \
  -profile:v high -level 4.0 \
  -pix_fmt yuv420p \
  -c:a aac -b:a 96k -ac 1 \
  -movflags +faststart \
  output.email.mp4

The scale=1280:-1 resizes to 1280px wide, height auto-calculated. For a 1920×1200 source, output is 1280×800.

For background on the WhatsApp-specific path, see Compress Video for WhatsApp.

Recording Settings That Help

The encoding step can only do so much. Bad input produces bad output. Recording settings that pay off:

Resolution: record at the actual display resolution. Don't record a 5K iMac at 1920×1080; the app text downscales twice (display to recording, recording to delivery). Record at native, scale down at export.

Frame rate: 30 fps is fine for most screen content. 60 fps is for cursor-tracking precision (development tooling, gaming). Higher fps doubles encoding time.

Cursor highlighting: tools like ScreenFlow, Camtasia, and CleanShot X let you add a circle around the cursor or click effects. This is more legible than a tiny default cursor and dramatically improves "follow what I'm doing" comprehension.

Microphone: USB mic, not laptop built-in. Laptop mics pick up keyboard noise and produce thin audio that compresses badly. Even a $40 USB mic transforms the result.

Quiet environment: ambient noise becomes more obvious after encoding, not less. The encoder doesn't filter it out.

When QuickTime Output Goes Wrong

Common QuickTime screen recording issues and fixes:

Issue: File is .mov, refuses to play in Outlook preview pane.
Fix: Re-encode to .mp4 with FFmpeg or a converter. Outlook's preview is H.264-MP4-only.

Issue: Audio out of sync after long recordings.
Fix: QuickTime's audio sync drift is a known issue. Re-mux with -vsync cfr flag in FFmpeg.

Issue: HEVC encoded video shows as black on Windows.
Fix: Re-encode to H.264. Windows decoders for HEVC are inconsistent.

Issue: Mouse cursor missing in recording.
Fix: Hold Option (or Alt on Windows) while clicking the screen recording icon. macOS-side fix.

Issue: Text looks blurry after recording.
Fix: Display scaling > 100%. Set the display to native resolution before recording. The blur is from rescaling, not encoding.

For the underlying conversion mechanics, see Best Screen Recording Format.

Audio for Screen Recordings

For client demos with voice-over, audio quality matters more than people expect. The video can be average if the audio is clear. The reverse is rarely true.

Voice-only recording: 128 kbps AAC mono is sufficient. Mono saves bandwidth, voice doesn't need stereo.

Music + voice: 192 kbps AAC stereo. Mono kills music dimensionality.

Tutorial music ducking: don't add background music to client demos. It distracts. If you must, set music to -30 dB while voice is present, -18 dB when silent.

Loudness target: -16 LUFS integrated for screen recording. Quieter than music tracks (-14 LUFS) because the typical playback environment for screen recordings is a quiet office. Loud audio in that context is jarring.

Our extract audio tool handles audio extraction if you need to process the audio separately.

Captions for Accessibility

If the client distributes the recording further, captions help. Two paths:

Automatic generation: tools like Otter, Descript, or Apple's built-in Voice Memos transcription produce starting text. Always review for technical terms.

Manual SRT or VTT: write captions in a text editor. Use our SRT to VTT converter for format choice.

For internal demos, captions are optional. For external (sales pitches, public marketing), they're now an expectation.

Compression Comparison

For a 10-minute 1080p screen recording with voice-over:

The CRF 22 line is the production default. CRF 26 saves 40% file size for email delivery. 720p saves another 50%.

When the Recording Is Too Long

A 90-minute training session is too big for any single attachment workflow. Three solutions:

1. Split into chapters: 9 ten-minute clips. Easier for the client to review specific sections.
2. Upload to a video host: Loom, Vimeo, YouTube Unlisted. Send a link. Avoid sending raw video.
3. Compress aggressively to a single file: 720p CRF 28 audio at 96 kbps. A 90-minute video lands around 600 MB. Manageable on Slack or Drive.

For long training videos with discrete sections, splitting is almost always the right call. The client can pause and resume, and your file size problem disappears.

For batch processing across multiple recording files, see Batch Processing Files Guide.

Frequently Asked Questions

Why does my screen recording file play in QuickTime but not Windows Media Player?

QuickTime defaults to HEVC + .mov container. Windows Media Player has spotty HEVC support. Convert to H.264 + .mp4 with our video compressor and the file plays everywhere.

Should I record at 60 fps or 30 fps?

30 fps for most content. 60 fps for content where cursor speed matters (gaming, IDE auto-complete demos). 60 fps doubles encoding time and increases file size by 60%.

Can I edit a screen recording without re-encoding?

Limited. You can trim the start and end without re-encoding using FFmpeg's -c copy flag, but only at keyframe boundaries (typically every 2 seconds). Non-keyframe edits force re-encoding. Most editing apps re-encode regardless.

What's the best format for archiving screen recordings?

H.264 MP4 at CRF 18. The files are large but visually transparent. For long-term archival of important demos, this is the right balance. Save the source .mov if you're paranoid; otherwise CRF 18 H.264 MP4 is sufficient.

How do I add captions or annotations after recording?

Use a video editor (DaVinci Resolve, Premiere, ScreenFlow, or Camtasia). Re-encode after editing. For simple annotations like text callouts, ScreenFlow and Camtasia have the lowest learning curve. For SRT subtitle workflow, see SRT vs VTT vs ASS.

Does cropping the recording help with file size?

Yes, dramatically. A 1920×1080 recording cropped to 1280×720 saves about 50% file size after re-encoding. If your demo only needs the center 80% of the screen, crop. Our video crop tool handles aspect ratio changes.

Related Reading

• Best Screen Recording Format
• Compress Video for WhatsApp
• Best Audio Format for Podcasts

Bottom Line

For client handoff: H.264 MP4 at CRF 22, AAC 128k mono, +faststart flag, 1080p or 720p depending on content. Avoid HEVC unless you've confirmed the client's playback environment. Split long recordings into chapters or upload to a video host. Our video compressor and video crop tool cover the encoding and aspect-ratio steps for clean delivery.