video-filter order of operations: ops first, then filtergraph

In POST /v1/video-filter, the ordered ops[] list (at most 8 entries of dim or crop) runs first, and the filtergraph runs after it on the result. A program needs at least one op or a non-empty filtergraph.

This is from the Video filter docs, read 2026-09-30.

Why does the order matter?

A crop op is a rectangle in fractions of the source frame. Any geometry filter in the filtergraph then acts on the cropped frame, not the original. Put your crop in ops[] and the resize or blur after it in the graph, and think in the cropped frame's coordinates.

curl -X POST https://api.sume.com/v1/video-filter/check \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "video_url": "https://media.sume.com/artifacts/artf_demo/talk.mp4",
    "ops": [
      { "op": "crop", "x": 0, "y": 0.1, "width": 1, "height": 0.8 },
      { "op": "dim", "amount": 0.8 }
    ]
  }'

What are the filtergraph limits?

Up to 2048 characters and 32 named filters. No inputs, outputs or paths: the server wraps the graph as [0:v]...[vout]. Internal labels such as split[a][b] are fine; stream specifiers like [0:v] are not. Names must be on the allowlist; trim, setpts, drawtext, subtitles, movie and lut3d are not.

How do I test a program before paying?

Send it to POST /v1/video-filter/check first. It is unbilled, needs no Idempotency-Key, and answers object: video_filter_check with valid, diagnostics[], the compiled filter names and a next_action. The encode itself costs $0.02 per job.