DiffusionGemma Advertisement Master Assembler
The Exact-Frame Editor That Refuses to Ship H3's Padding Frames
- master_audio
- lane_1_images
- lane_2_images
- lane_3_images
- lane_4_images
- assembled_master
- locked_master_audio
- assembly_report_json
- status
- ready
DiffusionGemmaAdvertisementMasterAssembler is the node that turns four separately generated H3 lanes into one exact, audio-locked 30-second master - and it's stubborn about the word exact. H3 clips don't always come back with precisely the frame count you asked for; there can be padding or rounding at the tail. This assembler trims every lane to its contracted retained-frame count and concatenates the results so the delivery master is frame-exact, and it will fail rather than let a single extra H3 padding frame into the final video. If your ad is supposed to be exactly 720 frames at 24 fps, that's what you get - not "about 720."
Mechanically it's lazy and contract-driven. Required inputs are the advertisement_contract_json (the master contract), advertisement_plan_json (the lane plan from the Multi-Shot Planner, which defines how many frames each lane owns and where each starts), and master_audio (the locked final mix). Then up to four optional lane_N_images inputs, which are lazy - the assembler only requests the lanes the plan actually needs, so an unused lane 3 or 4 never gets pulled from upstream. Each connected lane gets trimmed at its retained cut, the frames are concatenated in plan order, and the master clock plus soundtrack duration are verified before anything is emitted.
Outputs: assembled_master (the concatenated IMAGE batch), locked_master_audio (passed through from your final mix - and note the pack discards H3's own generated audio entirely; only the selected, hash-locked soundtrack is ever muxed), assembly_report_json with the per-lane evidence, and the status/ready pair.
The reason a beginner should care about this node rather than just stitching video in a helper-suite node is the frame accounting. When you plan a two-lane 30-second campaign, lane 1 might be 14.9 seconds and lane 2 the remainder - the plan records exact retained-frame allocations, and this assembler enforces them. If a lane came back short or over, you don't get a subtly shortened master that drifts from the audio clock; you get a fail-closed error telling you the contract wasn't met. That's the property an ad deliverable actually needs, because a 29.7-second "30-second spot" is a rejected deliverable.
Where people trip: wiring lane images out of order or expecting the assembler to auto-detect which frames belong to which lane. It trusts the plan, not your wire labels, so keep lane index wiring and plan order aligned. And don't feed it the output of a sampler that still has its own tail frames baked in - that's the exact padding the assembler is designed to reject.
Install is the pack install: ComfyUI Manager search "DiffusionGemma Prompt Builder", or git clone https://github.com/exportAnything/ComfyUI-DiffusionGemmaPromptBuilder into custom_nodes and restart. The ad workflow needs ComfyUI 0.33.1+ and H3 model files; the assembler itself is frame math and concatenation, cheap to run. Its real cost is upstream, in the H3 lanes - which is why exact retained-frame planning and this assembler are the two halves of making that GPU spend come out as a deliverable.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| advertisement_contract_json | STRING | — | |
| advertisement_plan_json | STRING | — | |
| master_audio | AUDIO | — | |
| lane_1_imagesopt | IMAGE | — | |
| lane_2_imagesopt | IMAGE | — | |
| lane_3_imagesopt | IMAGE | — | |
| lane_4_imagesopt | IMAGE | — |
Outputs (5)
| Name | Type | Description |
|---|---|---|
| assembled_master | IMAGE | — |
| locked_master_audio | AUDIO | — |
| assembly_report_json | STRING | — |
| status | STRING | — |
| ready | BOOLEAN | — |