V2 keeps the boring center that made V1 reliable. Hosted AI video may generate selected candidate shots. Humans still choose the assets, and Python plus FFmpeg still make the episode.

Status: proposed, not implemented. We have not run a paid MiniMax H3 generation for this pipeline. The first provider call remains budget- and scope-gated.

V1 proved that we could build Milo's Hardware Reviews from real evidence, an approved script, generated artwork, synthetic narration, programmatic graphics, and ordinary video engineering. One Python script produced the final timeline, audio mix, captions, and MP4.[1]

V2 is narrower than “move video production to AI.” We will use hosted AI video to make a few candidate shots, then pass accepted local files into the same deterministic build.

The model does not become the editor. It does not decide what happened in the lab. It does not create measurements, ratings, UI demonstrations, or caveats.

Architecture at a glance

MHR Video Production Pipeline V2: evidence and script feed a shot manifest; real, deterministic, and hosted AI candidate sources pass through human selection into a local archive, Python and FFmpeg build, and review/QC package. Generated shots always have fallbacks.
Proposed August 5, 2026. AI is a replaceable shot source. Download the editable SVG.

The boundary

AI may generateMust remain real or deterministic
Short product beauty motionProduct behavior used as evidence
Abstract section bumpersMeasurements and telemetry
Lab atmosphere and visual textureRatings, prices, certifications, and caveats
Controlled transitionsApple Home and Home Assistant operation
Shot variations for human selectionJames's voice and appearance
Optional reviewed ambience stemsNarration, captions, timeline, mix, and final master

If a visual supports a factual review claim, it must be a real capture or a deterministic graphic made from measured data. Generated video can illustrate tone and motion. It cannot prove anything.

shots.yaml becomes the editorial contract

V1 keeps its shot list inside the Python builder. That worked, but it mixed editorial decisions with rendering code.[1] V2 moves those decisions into a small manifest:

shots:
  - id: 03-product-push-in
    kind: generated_video
    purpose: product beauty beat
    claim_role: illustrative
    duration_s: 4
    selected_asset: assets/generated/03-product/take-02.mp4
    fallback_asset: assets/real/product-card.png
    generation_record: generations/03-product/take-02/receipt.json
    audio: silent
    approval: accepted

The claim_role is a hard gate:

A provider outage, rejected shot, expired download URL, or future model change cannot block the episode build. The timeline still resolves to a local asset.

Why hosted H3 comes first

MiniMax's hosted H3 API supports text-to-video, first/last-frame image-to-video, and reference generation. Current documented outputs are 4–15 seconds at 768P or 2K. Generation is asynchronous: submit a task, poll its task ID, download the result, and save it locally.[2][3]

That fits our immediate problem. We need fast experiments on a few short shots, not another model-serving project.

The API currently allows two concurrent H3 tasks on the free tier and fifteen on paid accounts.[4] MiniMax's existing video resource packs explicitly exclude H3, so we will not publish or hard-code a guessed price.[5] The first canary will record the actual account charge, queue time, generation time, download time, and acceptance rate.

Hosted privacy and retention remain unresolved. MiniMax documents task lifecycle and recent-task listing, but we did not find an extractable H3-specific retention policy. Private lab footage and unreleased likeness references stay out of the hosted path unless James approves them.

The first canary

The first experiment is deliberately boring: a four-second, 768P, first-frame image-to-video push-in based on a real THIRDREALITY product photo.

Maximum four candidatesFour separate tasks, submitted only after budget approval.
No people or generated textProduct geometry, labels, ports, and device count must remain intact.
768P firstNo 2K regeneration until a 768P candidate wins.
Audio discardedThe existing narration, captions, and mix remain authoritative.

The canary passes if at least one candidate looks acceptable, normalizes cleanly to 1920×1080 at 24 fps, and survives the existing deterministic build. If all four fail, we stop and improve the prompt or reference. We do not respond by building a bigger platform.

If the product shot works, the next tests are an abstract four-second bumper with no text and a wide lab-atmosphere shot with no faces or identifiable product details. Generated presenter motion comes later, if at all. Our controlled two-state James-and-Milo animation is visually stable and already has an approved fallback.[1]

Receipts before abstractions

Every candidate gets an append-only local record:

generations/<shot-id>/<take-id>/
  prompt.md
  request.json
  response.json
  raw.mp4
  ffprobe.json
  receipt.json
  review.md
  sha256sums.txt

The receipt records the provider and model, task ID, submitted parameters, input hashes, status transitions, wall time, usage, actual billed cost when observable, output hash, media metadata, and accept/reject reason. Secrets are removed before anything enters the episode tree.

We are not building a provider framework yet. V2 gets one direct generate_minimax_h3.py path. It validates the request, submits, polls, downloads, hashes, probes, and records. A common backend interface should be extracted only after a second backend actually works.

This part of the plan changed after an Opus 5 review. The architecture boundary was sound, but we were at risk of designing adapters before proving that three AI shots were worth keeping. The revised order is: do the shots first, extract the adapter second.

Cost per accepted shot

Raw generation speed is not the useful production metric. A model that returns a clip quickly but needs eight retries is slow and expensive in practice.

We will track every task, including failures and rejected candidates:

The useful numbers are cost per accepted second, latency per accepted second, candidates per accepted shot, and rejected-generation waste. Until the first hosted run produces billing evidence, H3 price stays null in the records.

The deterministic center stays

After selection, the provider is out of the loop. The build uses downloaded local assets only.

  1. Resolve selected assets or fallbacks.
  2. Normalize geometry, frame rate, pixel format, and GOP structure.
  3. Trim and assemble the visual timeline.
  4. Build the narration and music timeline separately.
  5. Loudness-normalize the final mix.
  6. Mux optional English captions.
  7. Produce the review MP4, contact sheet, and QC report.

Generated audio is muted by default. If a clip contains useful ambience, we may extract it as a separate stem, review it, and mix it conventionally. Native model audio never replaces James's recording, Milo's approved voice, captions, or the final mix.

Local H3 is a later backend, not a prerequisite

MiniMax's official model card describes H3-Base as the local 768P generation module, with 24 fps video and 32 kHz stereo audio output.[6]

We already proved that H3 can run on the 512 GB M3 Ultra. A community 69.3 GB MLX 8-bit FL2VA pack worked with mlx-serve PR #122, while stock v26.8.1 failed to load it. A representative 960×768, 124-frame, 30-step run took about 19.3 minutes for sampling plus about 64 seconds for VAE decode. Large non-stream delivery also failed once after successful generation, so streaming is required for serious local runs.[7]

That is a useful capability proof, not a fast editing loop.

There is also a licensing gate. The current MiniMax H3 Community License excludes the United States, European Union, United Kingdom, and Republic of Korea from its defined applicable territory unless separate authorization is obtained.[8] MiniMax says its hosted API is globally available because it retains platform safeguards, while organizations in restricted regions can apply for authorization to deploy the open weights.[9]

Local H3 therefore waits for:

  1. explicit US authorization;
  2. a stable released runtime rather than an open PR dependency;
  3. measured latency and reliability that justify an operational role.

If those gates clear, the local path should emit the same generation records and local MP4 assets. That is when we extract the common interface.

What we are not building

Not in V2Reason
AI director or model-controlled timelineEditorial decisions remain explicit and reviewable.
Provider plugin registryOne provider is not a framework.
Queue service, dashboard, or automated VLM judgePremature before three useful shots exist.
Generated narrationVoice, timing, and captions already have an approved path.
Default 2K generationCheap 768P selection comes first.
Local-H3 release dependencyHosted output and deterministic fallbacks must be enough to ship.

The human approval gates remain explicit: script and facts, shot manifest, candidate selection, timeline review, technical QC, and publication.

Definition of done

V2 earns the name when one command can validate the manifest, resolve selected assets and fallbacks, build the episode, create captions and a contact sheet, run media and loudness checks, and write qc.json.

The generated-shot experiment earns expansion only after three useful shot classes pass with complete receipts and measured economics.

Next action: approve one four-task hosted canary, then publish an honest accept/reject table. The next action is not a platform build.

Sources

  1. How We Built MHR 001: Video Production Pipeline V1
  2. MiniMax Video Generation guide
  3. MiniMax Video Generation V2 create API
  4. MiniMax API rate limits
  5. MiniMax video packages
  6. MiniMax H3 official model card
  7. MiniMax H3 on MLX: Local Video+Audio on M3 Ultra
  8. MiniMax H3 Community License Agreement
  9. MiniMax H3 license Q&A

Previous: Video Production Pipeline V1. Local capability proof: MiniMax H3 on MLX. Review companion: MHR 001: THIRDREALITY Smart Plug Gen3.