Demand Gen video ads: four ratios, a 5 s floor and the 4:5 gap

Demand Gen video takes 1:1, 16:9, 4:5 and 9:16, from 5 s. How to render the four-ratio set with Sume, including the 4:5 case the video API does not list.

5 min readSume
All posts

A Demand Gen video ad can be 1:1, 16:9, 4:5 or 9:16, must run at least 5 seconds, and Google recommends more than 15 seconds. Clips under 10 seconds are not eligible for YouTube in-stream. Plan four exports per concept, and treat 4:5 separately because Sume's video API does not list it as a native ratio.

This post turns the spec page into a render plan. It covers only the video spec; image and copy limits are on separate Google pages.

What Google asks for

The figures below come from the Demand Gen video specification page.

Demand Gen video specs (read 2026-10-03)
ItemSpec
Aspect ratios1:1, 16:9, 4:5, 9:16
Recommended HD sizes1080x1080, 1920x1080, 1080x1350, 1080x1920
Minimum length5 seconds (under 10 seconds is ineligible for YouTube in-stream)
Recommended lengthOver 15 seconds
Videos per ad1 to 5
Maximum file size256 GB
Eligible formatMPG, among others

Three ratios render natively

The Sume video API takes aspect_ratio and resolution on POST /v1/videos. The documented ratio list is 16:9, 9:16, 1:1, 4:3, 3:4, 3:2, 2:3, 21:9 and 9:21, and each model advertises its own subset in supported_aspect_ratios. So 1:1, 16:9 and 9:16 cover three of the four Demand Gen ratios.

Duration is a whole number of seconds from supported_durations. Ask for at least 10 seconds, not the 5-second minimum, so the clip clears the in-stream cutoff. Google recommends more than 15 seconds, which most catalog models cannot reach in one clip because they top out at 15; seedance-2.5 and wan-3.0 accept up to 30. Read the catalog first with GET /v1/videos/models, because limits differ by model.

for ratio in 1:1 16:9 9:16 3:4; do
  curl -X POST https://api.sume.com/v1/videos \
    -H "Authorization: Bearer $SUME_API_KEY" \
    -H "Content-Type: application/json" \
    -H "Idempotency-Key: demand-gen-spring-${ratio/:/x}-001" \
    -d "{\"model\":\"sume/auto\",\"prompt\":\"Product on a desk, slow push-in, natural light\",\"aspect_ratio\":\"$ratio\",\"duration\":15}"
done

The 4:5 case

4:5 is not in the documented video ratio list. The nearest native ratio is 3:4. One route is to render 3:4, then use the video filter crop op, which takes fractions of the frame, to trim the extra height down to 4:5. A 3:4 frame is 0.75 wide-to-tall and 4:5 is 0.8, so the crop keeps the full width and about 94 percent of the height.

Then run the cropped clip through video trim with an output of width 1080 and height 1350 to conform the size. Both steps are flat worker jobs with no model inference, and trim lists $0.02 per job in the docs. Check the result with a probe before upload, since the docs describe the conform step but this post has not verified the exact pixel output for every source.

Checklist before upload

Submit all four renders at once and collect them with a batch wait, described in jobs and results.

  • Four files per concept, one per ratio, each at least 10 seconds.
  • Keep the subject inside the middle of the frame so the 4:5 crop and the 9:16 safe areas do not cut it.
  • Name files by ratio so the ad group maps cleanly.
  • Use an Idempotency-Key per ratio so a retry does not bill a second render.

Naming and handoff

Name each file with the concept, ratio and length, for example spring-mug-4x5-10s.mp4, so the person building the ad group never has to open a file to know what it is. Keep one folder per concept with the four ratios inside it.

Google lets an ad hold one to five videos and the copy page allows three videos per orientation. Start with one video per ratio, then add variants only after the first set is approved. A larger set that mixes concepts is harder to read in results and slower to review.

Before upload, probe each file. The video inspect route returns probe facts and stills for a Sume-hosted clip, which is enough to confirm length and frame size against the table above.

Sources

Related posts

More in Use cases

All Use cases posts

Written by Sume