03:00:0050% OFFClaim
MiniMax H3

Hands-on recipe

Preflight first and last frame files before binding a pair

Prove that the files assigned to first and last are the intended readable images with matching geometry. This does not prove semantic continuity or a provider’s first/last-frame capability.

Includes executed local fixtures, scripts and receipts. These checks do not represent a video-generation service run.

Get the practice files ↓
Original task-specific local-fixture diagram
Original first/last PNG practice illustrations, a portrait negative fixture and a binding diagram. These are local inputs, not model results.

01Prepare environment and inputs

  1. Use Node.js and an installed FFmpeg. Set FFMPEG_BIN to its absolute path if it is not on PATH; the recorded fixture used FFmpeg 6.0.
  2. Inspect binding.json and the original 320×180 first.png/last.png practice images in executed/inputs. A separate 180×320 PNG deliberately violates the pair geometry.
  3. Keep the role name, basename and expected SHA-256 together. Run into a new output directory so an earlier manifest cannot silently refer to replaced input files.

02Run the recipe

Run command

node run-recipe.mjs --out ./my-run

  1. Freeze each role-to-file assignment

    The script creates a pair of small original RGB illustrations and writes a binding manifest. First and last have distinct bytes and edge markers. Hashes are captured from these exact files, not inferred from an upload order or a filename containing “first”.

  2. Validate geometry and decode the image

    For each bound file, read the PNG signature and IHDR width/height, then fully decode it through FFmpeg to one RGB frame. Both must be 320×180 and share the explicitly selected 16:9 canvas. Header dimensions alone would not establish that compressed pixels decode.

  3. Replay the four unsafe assignments

    Run the portrait-last, swapped filename, missing last and parent-path cases. Each is expected to fail for its own reason: dimension mismatch, hash binding, missing input or unsafe basename. failure-receipt.json retains the actual exception messages.

  4. Retain the pair manifest with the files

    Check seven passing assertions and the pre/post script hashes in execution-receipt.json. Keep both PNGs and binding.json together when adapting your own upload flow. Review camera, object and endpoint semantics separately; these file checks do not inspect them.

03Check the result

  • The correct first/last pair produces one completely decoded RGB frame per PNG.
  • Both roles report exactly 320×180 pixels and the cross-multiplication confirms 16:9.
  • First and last have different SHA-256 values, matching their bound original files.
  • The 180×320 replacement is rejected for dimension mismatch.
  • Swapping the last filename into the first role without changing its expected hash is rejected.
  • A missing file and a parent-path basename are rejected, with all seven checks recorded.

04Troubleshoot and deliver

The tail image has the right subject but fails geometry.

Change only its actual pixel canvas to the pair’s selected dimensions, re-export, and capture a new hash. Renaming a portrait file cannot change its geometry.

Two files have been uploaded in the wrong order.

Correct the role-to-basename mapping, then regenerate both expected hashes from the selected files and recheck the manifest.

A header looks valid but decoding stops.

Replace only the damaged file with a complete local copy and rerun full decode. Do not accept IHDR dimensions as proof of readable pixels.

This pair manifest is a file-readiness record. It does not demonstrate a generated transition, endpoint compatibility or visual preservation between the two states.

05Download scripts and fixtures

Reference documentation