Instagram Reels API codec rules: HEVC or H.264, 4:2:0, closed GOP

Instagram's Reels API accepts a MOV or MP4 file with HEVC or H.264 video, progressive scan, a closed GOP, 4:2:0 chroma subsampling, no edit lists and the moov atom at the front. Sume's exact video trim documents a libx264 / yuv420p re-encode, which fits the codec and chroma rules; the Sume docs do not state closed GOP, edit lists or moov placement, so check those on the file you plan to upload.

The container and codec rules are quoted from Meta's IG User Media reference, read on 2026-10-02. The Sume side is video trim, video inspect and Timeline 1.0.

What exactly does Meta require for a Reel file?

Meta lists the video and audio requirements as one block. This table repeats the ones that depend on how a file was encoded, which is what an editor or an API pipeline controls.

What does Sume's exact trim output?

The video trim docs describe two precisions. exact, the default, is a frame-accurate re-encode with libx264 and yuv420p, and kept audio is remuxed as AAC. That matches Meta's H.264 and 4:2:0 wording on its face. keyframe is a stream copy, so the codec of the output is whatever the source had; the docs add that the cut may start a GOP early.

The docs say nothing about whether the output is a closed GOP, whether it carries an edit list, or where the moov atom sits. The related YouTube moov post reaches the same conclusion for another platform, and the faststart explainer covers what the atom is.

How do I check a file before I send it?

Use the free probe first. POST /v1/video-inspect with frames: false returns the probe, and the worker's inspect result includes container, video_codec, pix_fmt, fps, audio_codec, audio_channels and audio_sample_rate. Compare those with the table above. Then, on your own machine, ffprobe shows the rest, including whether the index comes before the media data.

# 1) Sume probe, no stills, no charge
curl -X POST https://api.sume.com/v1/video-inspect \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: reel-codec-check-001" \
  -d '{"video_url":"https://media.sume.com/artifacts/artf_demo/reel.mp4","frames":false}'

# 2) Local: codec, chroma, scan type, frame rate
ffprobe -v error -select_streams v:0 \
  -show_entries stream=codec_name,pix_fmt,field_order,r_frame_rate \
  -of default=nw=1 reel.mp4

# 3) Local: which box comes first, moov or mdat
ffprobe -v trace reel.mp4 2>&1 | grep -m2 -E "type:'(moov|mdat)'"

What if the file fails anyway?

A file that is HEVC or H.264 but fails on GOP structure, an edit list or a late moov atom needs a re-mux or re-encode outside Sume, in your own ffmpeg or editor. Sume refuses ffmpeg fields such as codec and crf, so it is not the place to tune encoder flags.

Keep the preflight cheap: probe, compare, publish, then poll the container until it reaches FINISHED. The Sume probe does not replace Meta's own validation, which happens when you create the container.

Which Sume tools keep the source codec?

Only the keyframe trim says so. precision: "keyframe" is a stream copy, so an HEVC source stays HEVC and an H.264 source stays H.264. That is fine for Meta's rule, but a source in another codec, for example VP9 inside an MP4, stays that way and fails. The exact trim re-encodes to libx264 and yuv420p, so it normalises a source that is not in Meta's list, at the price of a re-encode.

The same split matters for chroma. A 4:2:2 or 4:4:4 camera file in a stream copy keeps its chroma subsampling, while the exact re-encode writes 4:2:0. If your camera shoots 10-bit 4:2:2, trim with exact and read pix_fmt from a second probe to confirm it before publishing.

For clips assembled on Timeline 1.0, the docs describe the compiled ffmpeg and the 1080x1920 default but do not name the output codec. Probe the render's result rather than assuming it.