H3 Max 1080p image-to-video: check the first frames for a crop jump

Yes, a 1080p image-to-video clip from minimax-h3-max can start with a visible jump, and Sume's catalog tells you what to do about it: look at the opening frames before you assemble the clip, and only if the jump is confirmed, start the clip at its first stable frame. The catalog note says some outputs have a baked crop jump after two frames, and that for the observed 24 fps clips the first stable frame is at 2/24 of a second.

This is a catalog caveat, not a guarantee. The catalog line says to check first and act only when confirmed, so the rule below is a check, not a blanket trim.

Where does the jump come from?

H3 Max renders natively at 480p or 768p. The catalog describes 1080p as a latent refinement from native 768p on the same model, with no 2K or 4K tier. The crop jump is a property of that 1080p image-to-video path as observed, and the catalog warns that cover fit does not remove a baked transient, because the frames themselves already contain it.

Text-to-video and lower resolutions are not mentioned in the caveat. If you can accept 768p, you sidestep the question, and 768p costs $0.10 per second against $0.20 at 1080p.

How do I confirm it?

Use video frames to pull stills at times you name. It takes one clip on media.sume.com and an at list of 1 to 24 times, each at least 0 and less than the clip duration, and returns durable image artifacts at source size. Ask for the first frame, the frame at 1/24, and a few frames after the suspect point, then compare the framing. A jump shows up as a sudden change in how tightly the subject is cropped between neighbouring stills.

curl -X POST https://api.sume.com/v1/video-frames \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: h3max-open-frames-001" \
  -d '{
    "video_url": "https://media.sume.com/artifacts/artf_demo/clip.mp4",
    "at": [0, 0.0417, 0.0833, 0.125, 0.25],
    "format": "png"
  }'

How do I remove it without losing timing?

The catalog's own remedy is the Timeline source_in field: start that slot at 2/24 seconds, which is about 0.0833, keep the slot timing you planned, and leave enough source for any transition. The Timeline docs define video[].source_in as the in-point into the file and price a render at $0.10 per output minute, rounded up.

If you want a standalone file instead, video trim cuts a start and duration range into a new MP4 for $0.02 per job. Its default exact precision is a frame-accurate re-encode, which is what you want for a two-frame cut; keyframe precision may start a GOP early and would defeat the purpose.

What does the check cost?

Video frames is billed by its own Modal compute: container seconds times the Modal list rate times 1.25, plus the platform fee. The docs say it reserves its compute ceiling at submit and never bills above the hold. A 10-second H3 Max 1080p clip is $2.00, so a short frame extract is a small addition to the clip it checks. Submit is always asynchronous with a 202, so poll GET /v1/video-frames/:id until resource_status is ready.

Each returned frame has t, url, width and height. An instant whose extract failed comes back with a null url and does not fail the job, so check for nulls before you compare frames. Use png for lossless inspection; the default is jpeg.

If you generate many clips, run the check on a sample rather than all of them, then decide per batch. The point of the catalog note is that the jump is observed on some outputs, not that every clip has it.

When should I skip all this?

Skip it when the opening frames are clean, and always skip the trim for clips you inspected and found stable: the catalog says to act only on a confirmed jump. Also remember that 24 fps is the observed rate in the note. If your clip runs at another rate, two frames is a different number of seconds, so read the rate from the file before you compute the in-point.