[rwagwani]

Summary

VideoSaveQuality accepted 0-10, but imageio-ffmpeg asserts 1 <= quality <= 10 when it writes vision.mp4. A request with video_save_quality: 0 loaded the model, generated the whole video, and only then failed with quality must be between 1 and 10 inclusive. 11 and -1 were already rejected at startup.

Change

• VideoSaveQuality becomes ge=1, le=10, so 0 is rejected at startup like the other out-of-range values. The field description now says 1-10.
• Reasoner mode filled an inert video_save_quality = 0 placeholder (its output is text, so the value is never read). It is now 10, so reasoner samples still validate. The existing test_edge_num_frames_default caught this.

Behaviour change: video_save_quality: 0 is now rejected for every mode, including image modes (text2image, image2image) that never read it. No shipped spec, default or notebook uses 0 (the values in use are 4, 8 and 10).

Verification

• New L0 tests: 1, 5 and 10 accepted; -1, 0 and 11 rejected.
• args_test.py: 67 passed.
• The CI unit-test job (-m L0, same command as gpu-tests.yml), replicated on a single GB300: 790 passed on this branch vs 784 on main 1a2f03a. The 6 extra are the new tests. The one failure (activation_marks_test.py::test_marking_costs_less_memory_than_saving_every_eligible_op) fails the same way on main on this machine.
• GPU, Cosmos3-Nano-Sim-Transfer depth (one AV clip, one Robotics clip), every value from -1 to 11: -1, 0 and 11 are rejected at startup before the model loads; 1-10 all generate, file size rises with quality, and quality 10 gives the same video as before the change.

🤖 Generated with Claude Code