FFmpeg Settings to Encode Video for X (Twitter)

X's media documentation lists six encoding rules it states with the word "must" — and not one of them is about file size. Pixel format, pixel aspect ratio, scan type, GOP structure, audio profile, channel count. A file can sit comfortably under every published cap and still be refused on any one of them.

This page maps each of those six lines to the flag that satisfies it, with X's own wording next to it. Where X is silent, it says so rather than filling the gap.

The command

ffmpeg -i input.mov \
  -c:v libx264 -profile:v high \
  -pix_fmt yuv420p -vf setsar=1 \
  -flags +cgop -r 30 \
  -b:v 5000k \
  -c:a aac -ac 2 -b:a 128k \
  x-video.mp4

One thing has to be said plainly: X does not publish FFmpeg commands. It describes the file it wants. The flags above express that description, and FFmpeg's own documentation is where to confirm what each one does on your build.

The six "must" rules, mapped to flags

These are from the "Advanced" block of X's media best-practices page in the developer docs. Verbatim, each with the flag that expresses it:

Four of them deserve more than a table row.

-pix_fmt yuv420p is the one that bites silently. X's wording is exclusive — "Only YUV 4:2:0 is supported", not "4:2:0 is recommended". Footage graded or captured in 4:2:2 or 4:4:4 fails that sentence while playing perfectly on your own machine, and FFmpeg will preserve the source's chroma subsampling unless you ask it not to.

Pixel aspect ratio is not the same thing as aspect ratio. X requires the sample aspect ratio itself to be 1:1 — square pixels. Anamorphic sources carry a non-square SAR in metadata: the picture is stored at one width and flagged to be displayed at another. setsar=1 rewrites that flag. It is a separate rule from the frame's shape, which X covers under "Aspect ratio".

High-Efficiency AAC is named and excluded. X does not merely ask for AAC — the parenthesis rules out HE-AAC by name. -c:a aac selects FFmpeg's built-in AAC encoder; since the requirement is about the profile rather than the codec name, confirm what your build emits with ffmpeg -h encoder=aac instead of assuming.

"Must not have open GOP" is a rule about GOP structure, not GOP length. -flags +cgop asks for a closed GOP; whether your build already produces one by default is a build question, so check ffmpeg -h encoder=libx264.

For progressive scan, FFmpeg ships several deinterlacing filters — pick one from the official filter documentation. That line only matters for genuinely interlaced sources.

The recommended block, and the number that argues with itself

Separately from the "must" list, the same page carries a "Recommended" block: "Video Codec: H264 High Profile", "Audio Codec: AAC LC", "Frame Rates: 30 FPS, 60 FPS", "Minimum Video Bitrate: 5,000 kbps", "Minimum Audio Bitrate: 128 kbps", and "Aspect Ratio: 16:9 (landscape or portrait), 1:1 (square)". That block is where -profile:v high, -r 30, -b:v 5000k and -b:a 128k come from.

The same page also prints an upload table recommending 2048K video and 128K audio for 1280x720, introduced by this sentence: "In the table below each row represents an upload recommendation, but is not a requirement. All uploads are processed for optimization across multiple platforms."

So a single official page states a 5,000 kbps minimum and, further down, recommends 2048K at the resolution it also recommends. Both numbers are X's, with no note reconciling them. If bandwidth is not your constraint, -b:v 5000k is the stricter line to follow.

On picture size X recommends "1280x720 (landscape), 720x1280 (portrait), 720x720 (square)", then adds: "Subscribed users can upload a 1080p video and get 1080p playback. Unsubscribed users can upload a 720p video and get a 720p playback." Notice what that sentence does not cover — it never states what happens to a 1080p upload from an account without a subscription.

Which page applies depends on how you upload

Three ceilings around this command come from pages with different scopes, and they disagree:

The left column comes from a help-centre FAQ headed "What are the limitations on video resolutions and aspect ratios that can be uploaded on the web?" — so it describes web uploads. The right column is the API's. Three of the five rows conflict in inconsistent directions: the help centre allows a larger picture, the developer docs allow a higher frame rate and a more extreme aspect ratio. Neither set is "the X video spec". Encoding at 1280x720 and 30 fps stays inside both, which is why the command above does that. Duration and size ceilings vary by account tier — see X video length limits by account tier.

If you would rather not install FFmpeg

When the real problem is simply that the file is too heavy for the upload you are attempting, the same re-encode runs in a browser tab:

The file is read from disk, re-encoded locally and handed back — nothing is uploaded on the way to fixing an upload, which matters for unpublished footage. Be clear about the trade: the compressor outputs a sane H.264 MP4, not a checkbox for pixel aspect ratio or GOP structure. For the six lines above, the command line is the right tool. The rest of the browser tools are at all Clapr tools.

Troubleshooting

The upload finishes, then posting fails. On the API side this is documented behaviour, not a glitch: upload limits and post-creation limits are "separately enforced", and "A media_id that finalized successfully can still be rejected by POST /2/tweets."

The file is under the size cap and still will not ingest. X's ads help page says so outright — "Even if your file is under our maximum size, we may still have issues ingesting the file" — and its suggested fix is to re-export smaller by reducing the bitrate. More on the size ceilings in X video file size limits.

A .mov crawls or hangs during processing. X's Media Studio page states: "This happens most often with .mov files. If possible, re-export files as .mp4, which should allow for overall faster upload and processing time." Re-encoding with the command above already produces MP4; for a container-only swap, MOV to MP4 does it in the browser. Keep the scope in mind — that page says its instructions "are only valid for Media Studio, and should not be followed for usage of the X developer API, Pro Media API, desktop upload, or mobile upload."

FAQ

What FFmpeg settings does X officially require? Six lines from the developer docs: YUV 4:2:0 only, pixel aspect ratio 1:1, progressive scan, no open GOP, AAC Low Complexity audio (HE-AAC excluded), and mono or stereo audio. Everything else on that page — codec, profile, frame rate, bitrate — is filed under "Recommended".

What bitrate should I encode at for X? The developer docs give a "Minimum Video Bitrate" of 5,000 kbps and a minimum audio bitrate of 128 kbps. The same page's upload table suggests 2048K video at 1280x720 while stating that the table "is not a requirement". The help centre separately caps web uploads at 25 Mbps.

Does X accept HEVC / H.265 or AV1? X's official pages do not state this either way. The developer docs recommend H264 High Profile and the ads specs allow "H264, Baseline, Main, or High Profile with a 4:2:0 color space", but no official page addresses other codecs — check the official documentation rather than trusting a third-party claim.

Do I have to convert MOV to MP4 before uploading? Not as a stated rule for normal posting, but X's Media Studio page recommends re-exporting as .mp4 because processing stalls happen most often with .mov files. The API's accepted media types at initialization include video/mp4, video/quicktime and video/webm.

Why does my video look softer after posting? X writes that it "may modify or adapt your original video for distribution", including "modifying the resolution and bitrate of the original video while streaming based on the speed and stability of the viewer's internet connection". It also states that 1080p playback follows a subscription: subscribed users get 1080p playback, unsubscribed users 720p.

All X requirements above are quoted from X's official developer media documentation, help centre and ads specifications, checked 16 September 2026. These pages contradict each other on several numbers and X revises them — verify against the official documentation before relying on any single figure. More command-line write-ups are in our ffmpeg guides.