- Guardrail install points to ifm-ai/pan2-guardrail, as in the vLLM-Omni and Diffusers ports.
- The basic example runs the release's own text-to-video structured caption (10 s, 241 frames) instead of a plain prompt.
- Docs and the flow-shift comment name the release checkpoint IFM/PAN2; the docs and cookbook no longer describe its release status or the parity tests' checkpoint.
- FASTVIDEO_FA4 is set only while the PAN2 pipeline loads, instead of for the rest of the process.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An empty negative prompt now selects the release's structured negative caption with its time ranges set to the
clip's duration, as the reference sampler does; a single space still gives the empty unconditional prompt.
The serving config and cookbook now say guidance 2.5, matching the presets.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PAN 2's vLLM-Omni and Diffusers integrations check every prompt and every
generated video with the `pan2-guardrail` package's PAN2SafetyChecker, on by
default. FastVideo now does the same:
- `PAN2PromptGuardrailStage` checks the prompt right after input validation,
before any compute. It also refuses `output_type="latent"`, which the video
check cannot see.
- `PAN2VideoGuardrailStage` checks each decoded video after the decoding stage,
as the uint8 `[T, H, W, 3]` frames the generator delivers.
- A blocked prompt or video raises `PAN2GuardrailViolationError`.
- `PAN2PipelineConfig.enable_guardrails` (default True) turns both checks off;
`offload_guardrail_models` keeps the guard models on CPU between checks.
Loading fails with install instructions when the package is missing and the
guardrails are on.
- With sequence parallelism, only the first rank of the SP group loads the
checker and runs the checks; it broadcasts the verdict, so every rank raises
together and the guard models take memory on one GPU.
The parity test turns the guardrails off (random-weight checkpoint). Docs and
PORT_STATUS updated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Accept the causal-VAE-aligned 362-frame bucket (15.083 s) for 15-second H3 requests.
- Hoist MINIMAX_H3_MIN/MAX_ALIGNED_FRAMES next to align_num_frames and reuse them in the CUDA stage, the MLX runtime, and the LoRA example so the bound is consistent across entry points.
- State the accepted frame range in the error messages.
- Cover seconds="15" -> 362 at OpenAI admission and the MLX resolve_geometry bound.
- Update the Spark/openai cookbook frame caps from 345 to 362.
Known gaps: no GPU-lane coverage for the 362 bucket (SSIM runs 124 frames; the golden gate is a fixed-geometry fingerprint), and explicit num_frames=360 still hits the pre-existing grid gate.
