Nodes/comfyui-minimax-h3-audio-T8/FastH3 V2 · Verify, Review & Explicitly Accept (T8 EXP)
ComfyUI Node

FastH3 V2 · Verify, Review & Explicitly Accept (T8 EXP)

The explicit accept step for FastH3 V2 segments

By T8mars·Created 2 months ago·Updated about 7 hours ago· 1,158
FastH3 V2 · Verify, Review & Explicitly Accept (T8 EXP)
    • video
    • accepted
    • manifest_path
    • chain_id
    • parent_candidate_id
    • parent_revision
    • current_job_sha256
    • report_json
    ◄candidate_json_path►
    ◄accept_candidatefalse►

    What it is

    The gate. Everything upstream of this node produces a candidate; nothing becomes part of a finished clip until a human says so here. And by default, it says no.

    MiniMaxH3FastH3V2CurrentCandidateReviewAcceptEXPT8 takes the path to a saved candidate, verifies its MP4, its context and current-job/media sidecars, and checks the exact 124/68-frame boundary - then, only if you've explicitly flipped accept_candidate to true, calls the pack's reject-existing manifest transaction to record the acceptance. It defaults to preview only. It never composes a movie.

    If that sounds like friction, it is, and it's deliberate. Long-video stitching is where a bad segment becomes a bad final clip, and once a segment is accepted, later nodes will happily build on it. A default of "no" means a queue you walked away from can't quietly commit anything.

    How it works

    Two phases in one node, selected by candidate_json_path plus the accept_candidate boolean:

    1. Verify and preview. It loads the candidate JSON, re-checks that the media on disk matches the hashes recorded when it was written, confirms the frame boundary is the expected 124-render/68-delivery split, and returns a VIDEO you can actually watch in the ComfyUI preview.
    2. Accept. With accept_candidate=true, it runs the existing manifest transaction in reject-existing mode - the behaviour the pack uses everywhere, so a changed candidate can't silently swap itself in for an already-accepted one. You get back the manifest path, the chain ID, the parent candidate ID and revision, and the current job SHA.

    That job SHA is the thing you'll want to copy. It's what binds the acceptance to the exact render, and it's what the next segment's job-binding step compares against.

    Ports

    Inputs are just candidate_json_path (a string path, blank by default) and accept_candidate (false by default). Outputs: video, accepted, manifest_path, chain_id, parent_candidate_id, parent_revision, current_job_sha256, report_json.

    The workflow shape the pack recommends: run first with the default false, watch the preview end to end, check the audio, then set it true and re-queue - and don't re-render in between, because the candidate you previewed on disk is the one that gets accepted.

    Where it fits

    Segment one: render → decode → save candidate → review, accept → save the returned chain/candidate/revision/job SHA. Segment two: render using those parent receipts → save candidate → review, accept again. Composition happens only once every segment in the chain is accepted. Two segments, two human decisions, and the second one is doing most of the work - it's your last chance to notice the seam before it's baked into a 192-frame file.

    Install

    ComfyUI Manager → MiniMax H3 Audio T8, or:

    cd ComfyUI/custom_nodes
    git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8
    

    Quit ComfyUI fully, restart, refresh the browser. There's no pip step - the pack's requirements.txt is intentionally empty so it can't replace ComfyUI's Torch/CUDA stack - and optional EXP features resolve their own dependencies when used. Prerequisites: a recent ComfyUI with native H3 support, H3 weights in models/diffusion_models, Qwen in models/text_encoders, both VAEs in models/vae, plus the FastH3 V2 ConvRT INT8 checkpoint for this chain.

    Where it goes wrong

    A blank candidate_json_path is the boring one: it needs a real file. Then there's the stale-candidate case - you accepted a segment, changed something, and the verification fails on media or hash comparison. That's the transaction refusing to replace a live acceptance, and the fix is a new candidate (and generally a new chain), not a retry.

    Watch for the ordering mistake too: it's easy to wire this node before the candidates exist. It's not a sampling node, so it will happily run first and then tell you the path it was handed doesn't resolve.

    Last, a matter of temperament: if you're used to save-and-done workflows, a node whose default answer to "keep this?" is "no" feels like an obstacle for about ten minutes. The pack's argument is that the alternative - implicit acceptance - is how you end up with a twelve-second clip containing one segment you didn't actually approve. That seems like the right trade for anything you intend to keep.

    CategoryT8/MiniMax H3/Modular Sampling/Continuation Experimental

    Inputs (2)

    NameTypeDefaultDescription
    candidate_json_pathSTRING—
    accept_candidateBOOLEANfalse—

    Outputs (8)

    NameTypeDescription
    videoVIDEO—
    acceptedBOOLEAN—
    manifest_pathSTRING—
    chain_idSTRING—
    parent_candidate_idSTRING—
    parent_revisionINT—
    current_job_sha256STRING—
    report_jsonSTRING—