The Best Video Settings for a Virtual Camera

A video file that looks perfect in your media player can look wrong the moment it becomes a camera feed: letterboxed, stuttering, soft, or rejected outright. Conferencing apps are far pickier about camera input than players are about files, and most of the fixes are decided at encode time.

If you want one answer and no reading: 1280×720, 30 fps constant frame rate, H.264 High profile in an MP4, yuv420p, keyframe every second, no audio track. That combination is accepted everywhere. The rest of this explains when to deviate.

Resolution

720p is the safe default, and not because 1080p is unsupported. Most conferencing apps downscale your camera to 720p or lower before sending it anyway — Zoom sends 360p in a gallery-view meeting unless conditions are good, and gallery tiles are a few hundred pixels wide. Encoding at 1080p often means your machine decodes more pixels than anyone will ever see.

Resolution	Use when
1280×720	Default. Universally accepted, cheap to decode, matches what most calls transmit.
1920×1080	A demo where fine detail matters and you know the call is in speaker view on a good connection.
640×480	An old or restrictive app that refuses anything larger, or a very weak machine.
Above 1080p	Never. Nothing transmits it, and some apps drop the device rather than negotiate it.

What aspect ratio should a virtual camera video be?

Camera tiles are 16:9. A clip shot in portrait on a phone (9:16) gets pillarboxed into a narrow strip with wide black bars either side, and the subject ends up tiny. This is the single most common reason a fake cam looks obviously wrong, and no playback setting repairs it.

Shoot landscape. If you already have portrait footage, crop the middle of it and accept the loss, rather than letting the app pad it:

ffmpeg -i portrait.mp4 -vf "crop=ih*16/9:ih,scale=1280:720" -an -c:v libx264 out.mp4

Non-standard ratios cause the same problem in miniature. 4:3 footage in a 16:9 tile gets thin bars; usually tolerable, occasionally not.

What frame rate should a webcam video be?

30 fps is right for essentially everything. 60 fps doubles decode cost and is discarded by the conferencing app in almost every case. Below 24 fps motion starts to read as a stutter rather than as video.

What matters more than the number is that the frame rate is constant. Phones record variable frame rate: the gap between frames changes with lighting, so a “30 fps” clip may really run anywhere from 24 to 30. A camera feed has a fixed cadence, so a VFR source produces irregular delivery — usually seen as micro-stutter, and as an unpredictable gap at the loop point.

Check what you have:

ffprobe -v error -select_streams v:0 -show_entries stream=r_frame_rate,avg_frame_rate -of csv file.mp4

If the two values differ, the file is VFR. Force it constant:

ffmpeg -i in.mp4 -vsync cfr -r 30 -an -c:v libx264 -preset slow -crf 20 -g 30 -pix_fmt yuv420p out.mp4

Which video format works best as a webcam?

MP4 with H.264 is the combination every decoder on every platform handles with hardware acceleration. MKV and WebM are fine in many apps but buy you nothing here. Prefer H.264 over H.265/HEVC: the licensing situation means HEVC decoding is missing or paywalled on some Windows installs, and the quality gain is irrelevant at 720p.

Two encoding details are worth setting explicitly:

• -pix_fmt yuv420p. Anything else — yuv422p from a capture card, yuv420p10le from a modern phone — may decode to a green or magenta picture, or fail to decode at all. This one flag fixes a surprising share of “my camera shows garbled colours” reports.
• -g 30. A keyframe every second. Long keyframe intervals make seeking expensive, which shows up as a slow start and a heavier loop join.

Bitrate and quality

Use CRF rather than a target bitrate: -crf 20 at 720p is visually clean and lands around 2–4 Mbps for typical talking-head footage. There is little point going below -crf 18, because the conferencing app is going to re-encode your frames at a fraction of that bitrate before anyone sees them. Your file only needs to be good enough that it is not the weakest link.

Avoid the opposite mistake too. Heavily compressed source footage with visible blocking gets re-encoded and looks worse, and compression artefacts that sit still while nothing moves are a giveaway that the feed is a file.

Strip the audio

A virtual camera is video only — your microphone is entirely separate, and the audio track in your file is never transmitted. It is dead weight in memory and an occasional source of odd behaviour in players that try to keep a nonexistent clock in sync. Add -an.

Length

Longer clips loop less often and are therefore harder to spot, which the looping guide goes into properly. The practical ceiling is memory and open time: a few minutes at 720p is nothing, half an hour of 1080p is a large file to hold open for a call. Two to five minutes is the sweet spot for a talking-head loop.

Rotation metadata

Phone footage often carries a rotation flag rather than actually-rotated pixels. Players honour it; some capture pipelines ignore it, and your video arrives on its side. Bake the rotation in when you re-encode:

ffmpeg -i in.mp4 -vf "transpose=1" -metadata:s:v rotate=0 -an -c:v libx264 out.mp4

One command that covers all of it

ffmpeg -i source.mp4 -vf "scale=1280:720:force_original_aspect_ratio=increase,crop=1280:720" -r 30 -vsync cfr -an -c:v libx264 -preset slow -crf 20 -g 30 -pix_fmt yuv420p -movflags +faststart webcam-loop.mp4

The filters above are documented in the ffmpeg filter reference; ffmpeg's webcam guide covers the other direction, reading from a real device.

That scales and centre-crops to exactly 1280×720, forces 30 fps constant, drops audio, and writes a broadly compatible H.264 MP4.

Then check it as a camera, not as a file

Load it in your virtual camera app, start the camera, and look at it in a conferencing app's preview — that is the only place resolution negotiation, aspect handling and loop behaviour all show up together. With CamLooper this is the whole test: point it at the file, start the camera, and check the preview before the call.

If the picture is black in the preview but the device is listed, the resolution is usually the culprit — the troubleshooting guide covers the rest. Drop to 1280×720 and try again — it is the one size every app accepts.