Mux thumbnail time and fit_mode vs Sume video frames at and max_edge

To pull a still from a video, Mux builds it from a URL query string (time, width, height, fit_mode), while Sume's video frames takes a JSON program: at[] seconds (1 to 24 values) or an fps, plus format and max_edge, and returns durable image artifacts. Mux answers with an image at a URL; Sume answers with a job you poll.

Mux facts come from its Get images from a video guide, read 2026-10-02. Sume facts come from the video frames docs.

What can the Mux thumbnail URL do?

Per the guide, a request to image.mux.com/{PLAYBACK_ID}/thumbnail.png accepts time (seconds; default is the asset's thumbnail time or the middle of the video), width and height, rotate (90, 180 or 270), fit_mode (preserve, stretch, crop, smartcrop, pad), and flip_v / flip_h. The guide also states a default limit of one thumbnail and one GIF per 10 seconds of duration per asset, and ten of each for assets under 100 seconds.

What does Sume video frames take?

POST /v1/video-frames needs video_url on media.sume.com and exactly one of at[] or fps (0 < fps <= 2, mid-bin samples, capped at 24 frames). format is jpeg (default) or png; max_edge is 16 to 2160 and, when omitted, keeps the source size. Submit is always 202, and extraction is unbilled. An at value outside [0, duration) fails as frame_time_out_of_range.

There are no rotate, flip or fit options on this route. A crop or pad belongs in video filter on the clip or in an image step on the still.

curl -X POST https://api.sume.com/v1/video-frames \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: thumb-35s-001" \
  -d '{
    "video_url": "https://media.sume.com/artifacts/artf_demo/talk.mp4",
    "at": [35],
    "format": "png",
    "max_edge": 1280
  }'

How do the two line up?

Poll GET /v1/video-frames/:id until resource_status is ready, then read frames[{t,url,width,height}].