Crop 1920x1080 to 3:4 with video filter: width 0.421875, x 0.2890625

For a centered 3:4 portrait crop of a 1920x1080 clip, send {op: "crop", x: 0.2890625, y: 0, width: 0.421875, height: 1}. That keeps an 810x1080 region. The job costs $0.02.

The arithmetic

Video filter crops use fractions of the source frame, not pixels. A 3:4 region at full height 1080 is 1080 x 3 / 4 = 810 pixels wide.

Constraints the API enforces

• x and y in [0, 1]; width and height in [0.05, 1]; x + width <= 1 and y + height <= 1.
• The compiler rounds to even values for yuv420p, so 810 stays 810 (it is even).
• Crop accepts only {op, x, y, width, height}; any extra key is unsupported_filter_op_field.
• Source up to 300 s.

Request

Run the unbilled check first if you are unsure; it uses the same validator. Import the clip first with POST /v1/media-imports so it sits on media.sume.com, send an Idempotency-Key header, then poll GET /v1/jobs/:id/status and read GET /v1/jobs/:id/result. The API rejects off-host URLs at admit, so a bad URL fails before any work runs.

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-34-001" \
  -d '{"video_url":"https://media.sume.com/artifacts/artf_demo/wide.mp4","ops":[{"op":"crop","x":0.2890625,"y":0,"width":0.421875,"height":1}]}'

What happens to the rest of the picture

Everything outside the rectangle is discarded. If a subject sits off-center, move x rather than centering: the formula is x = left pixels / 1920. The output keeps the frame rate and audio of the source unless the program changes them.

Other common crops from 1920x1080

The same method gives other ratios. A 1:1 square keeps 1080x1080: width 1080 / 1920 = 0.5625 and x = 420 / 1920 = 0.21875. A 4:5 crop keeps 864x1080: width 0.45 and x = 528 / 1920 = 0.275. A 9:16 crop keeps 607.5 pixels, which rounds to an even value, so expect 606 or 608 wide. Always compute from the left offset and check that x + width does not exceed 1. Every media job follows the same lifecycle: submit with an Idempotency-Key, receive a job, poll GET /v1/jobs/:id/status until it is ready, then read GET /v1/jobs/:id/result. A retry with the same key does not queue a second job, so a network error during submit never doubles a charge.