How to crop a video without losing quality

A normal crop decodes a video's frames, cuts them, and encodes them again, and that re-encode in most cases costs some quality. So the goal is to lose as little as possible: crop once, from the original, in the same pass as any other pixel change, and keep the cropped size instead of scaling it back up. With Sume, a crop is one POST /v1/video-filter job, which today re-encodes the clip once with libx264.

The facts come from the Video filter, Video trim, and Timeline compose docs, the Sume API reference, and FFmpeg's ffmpeg, codecs, and bitstream filters documentation, read on 2026-09-27. Anything described as current behavior is read from Sume's code.

Why does cropping re-encode the video?

FFmpeg's documentation draws the line. A stream copy moves packets without decoding, filtering, or encoding them, so there is no quality loss, but it can't apply filters, because filters work on decoded frames. A crop is a filter, so it needs a transcode, which in most cases degrades quality. Burning in subtitles changes pixels too, for the same reason.

Two narrow exceptions exist in FFmpeg. libx264 has a lossless mode. And the h264_metadata and hevc_metadata bitstream filters, which work on the encoded stream without decoding it, can set the cropping offsets in the stream's SPS header: the stored frames stay as encoded, and the header marks which part of them to show. Sume's tools take neither route: they refuse encoder fields such as codec and crf.

How much quality does each Sume edit cost?

Each step below is one pass. Chaining steps adds passes, and each lossy pass compounds the last.

How do I crop a video with Sume in one pass?

Send the crop as an ops[] entry of POST /v1/video-filter. The rectangle is in fractions of the source frame: x and y from 0 to 1, width and height from 0.05 to 1, with x + width and y + height at most 1, and the compiler even-rounds it for yuv420p. ops[] holds up to 8 ops and runs before any filtergraph. This keeps the middle half of a wide clip:

• The clip must be your workspace's media.sume.com file of up to 300 seconds; which URLs each endpoint accepts explains the rule. PQ and HLG (HDR) sources are refused with hdr_source_unsupported.
• Check the program for free first with POST /v1/video-filter/check, which creates no job and reserves no credits.
• The output keeps the cropped size, since a filter output inherits the source's geometry only where the program doesn't change it. The source is untouched.

curl -X POST https://api.sume.com/v1/video-filter \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: crop-center-001" \
  -d '{
    "video_url": "https://media.sume.com/artifacts/artf_demo/wide.mp4",
    "ops": [{ "op": "crop", "x": 0.25, "y": 0, "width": 0.5, "height": 1 }]
  }'

How do I keep the loss small across several edits?

• Put every pixel change in one filter job: crop and dim as ops[], other allowlisted filters in filtergraph. The filter allowlist lists the names.
• Scale once, to the final size. The compose docs say to set output to the timeline you assemble into so a shot is not rescaled twice.
• Cut with precision: "keyframe" when the start doesn't have to be exact. Of the Sume edits in the table above, it is the only one that copies the stream; it can't take output, and the result's actual_start_seconds says where the cut really starts.
• Start every new version from the original. Trim and filter never change their source, so there is no reason to re-encode a re-encode.

Can I rotate or trim without re-encoding?

Trimming, yes: a keyframe trim copies the stream. Rotating can be a metadata change instead of a pixel change: FFmpeg's -display_rotation sets rotation metadata, and when the video is copied rather than transcoded, that metadata is written into the output file if the muxer supports it. Sume's filter rotates the pixels, as in rotate a video 90 degrees, so that is one more encode.