Timeline render warnings: padded or looped short sources explained

When a Timeline 1.0 slot asks for more seconds than its source has, the render still succeeds and warnings[] in the result reports it. The docs list padded or looped short sources as soft warnings, not failures, and say POST /v1/timeline-1.0/plan cannot predict them.

This comes from the Timeline 1.0 docs, read 2026-09-30. The docs do not spell out warning code strings for padding or looping, so match on what you see in your own results.

Where do I see the warning?

A finished job's GET /v1/jobs/:id/result is kind: timeline_render with video_url, duration_seconds, segment_count, billable_minutes and optional warnings[]. The docs group these together as soft warnings: padded or looped short sources, snapped transitions, and ignored still motion.

Why can't the plan catch it?

/plan runs schema checks, Sume-host URL checks and the pure compiler. It returns duration_seconds, segment_count, billable_minutes and a filtergraph_summary, but it does not download media, so it does not know how long your clips are. Probe the sources yourself first.

curl -X POST https://api.sume.com/v1/video-inspect \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: probe-source-001" \
  -d '{
    "video_url": "https://media.sume.com/artifacts/artf_demo/short.mp4",
    "frames": false
  }'

How do I avoid the padding?

Compare each slot's duration (plus source_in) with the probed clip length, and shorten the slot or pick a longer source. Note that stills are static holds, and a motion field on a still is accepted and ignored, which produces motion_ignored.